<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>VMware on Kemal Bıyıklı</title><link>https://kemalbiyikli.com/tags/vmware/</link><description>Recent content in VMware on Kemal Bıyıklı</description><generator>Hugo</generator><language>tr-TR</language><lastBuildDate>Wed, 30 Jul 2025 09:47:14 +0300</lastBuildDate><atom:link href="https://kemalbiyikli.com/tags/vmware/index.xml" rel="self" type="application/rss+xml"/><item><title>vCenter: Archive is full</title><link>https://kemalbiyikli.com/vcenter-archive-is-full/</link><pubDate>Mon, 28 Jul 2025 17:48:27 +0300</pubDate><guid>https://kemalbiyikli.com/vcenter-archive-is-full/</guid><description>&lt;hr>
&lt;h3 id="problem">Problem?&lt;/h3>
&lt;p>Zaman zaman hepimizin karşılaştığı türden bir alarmla karşılaştım: vCenter sunucusunun &lt;code>/storage/archive&lt;/code> diski %90 seviyelerindeydi. Normalde bu disk ara sıra dolar ve kendini temizlerdi, bu nedenle biraz kendi haline bırakıp gözlemlemek istedim ancak bu sefer hiç temizlemeye niyeti yoktu ve dolmaya devam ediyordu. Ben de bir yandan bu durumla ilgili Broadcom KB makalelerini incelemeye koyuldum.&lt;/p>
&lt;p>Broadcom’un KB’lerini incelediğimde aşağıdaki önemli noktalar dikkat çekiyordu:&lt;/p>
&lt;ul>
&lt;li>vCenter’daki birçok dizin yüksek doluluk oranlarına çıkabilecek şekilde tasarlanmıştır. Çoğu durumda, bir bölüm %78-79 seviyesine ulaştığında, uyarıları tetiklemek için gereken %80’i aşabilir ve ardından daha düşük bir yüzdeye geri dönebilir.&lt;/li>
&lt;li>Benzer şekilde, %93’e ulaştığında, &lt;code>vmware-vpxd&lt;/code> hizmetinin kapanmasını tetiklemek için gereken %95’i aşabilir ve ardından daha düşük bir yüzdeye geri dönebilir. Bu durumlar genellikle otomatik temizleme veya sistem davranışının bir parçasıdır.&lt;/li>
&lt;/ul>
&lt;p>&lt;strong>Archive Bölümünün Özelliği&lt;/strong>&lt;/p></description></item><item><title>VMware ESXi – Cannot Mount Existing iSCSI Datastore</title><link>https://kemalbiyikli.com/vmware-esxi-cannot-mount-existing-iscsi-datastore/</link><pubDate>Wed, 25 Jun 2025 00:43:49 +0300</pubDate><guid>https://kemalbiyikli.com/vmware-esxi-cannot-mount-existing-iscsi-datastore/</guid><description>&lt;p>Geçtiğimiz hafta sanallaştırma altyapımıza yeni bir sunucu ekledim. Her şey yolunda gidiyor derken MSA2060 üzerindeki bir Volume’ü sunucuya mount edemedim. Neden oldu, nasıl çözeriz derken aşağıdaki gibi bir süreç gelişti.&lt;/p>
&lt;hr>
&lt;h2 id="iş-senaryosu">İş Senaryosu&lt;/h2>
&lt;ul>
&lt;li>Hali hazırda MSA2060 storage’ımızda aktif olarak kullanılan 2 adet LUN var.&lt;/li>
&lt;li>Yeni bir ESXi host vCenter ortamına eklendi.&lt;/li>
&lt;li>Bu hosta storage iSCSI ile bağlandı.&lt;/li>
&lt;li>LUN’lardan biri datastore olarak başarıyla mount edildi.&lt;/li>
&lt;li>Ancak bir LUN datastore listesinde yok ve mount edilemiyor.&lt;/li>
&lt;li>“Storage Devices” altında LUN görünüyor, ama &lt;strong>“Not Consumed”&lt;/strong> durumu var.&lt;/li>
&lt;/ul>
&lt;hr>
&lt;h2 id="tanılama-aşaması">Tanılama Aşaması&lt;/h2>
&lt;p>ÖProblemi tespit etmek için aşağıdaki kontroller yapıldı.&lt;/p></description></item><item><title>Hyper-V to vSphere Migration</title><link>https://kemalbiyikli.com/hyper-v-to-vsphere-migration/</link><pubDate>Tue, 23 Jan 2024 22:56:59 +0300</pubDate><guid>https://kemalbiyikli.com/hyper-v-to-vsphere-migration/</guid><description>&lt;p>Geçtiğimiz aylarda bir firmayı oldukça eski bir Hyper-V ortamından güncel bir VMware ortamına geçirmemiz gerekti. Bu işlemi en pürüzsüz şekilde nasıl yaparım diye araştırırken en başta aklıma vCenter Converter geldi. Kurulumunu yaptım ve çeşitli testler yaptım, adım adım hataları giderdim ancak ne olursa olsun bu işlem hayallerinizdeki gibi gerçekleşmiyor. Her zaman ufak tefek de olsa bir yerlerde sorun çıkıyor. Sunucunun UUID değiştiği için bazı servisler bozulabiliyor, güvenlikle ilgili Group Policy’lere takılabiliyor, network kartını tanımıyor, taşıyacağınız her sunucuda güvenlik yazılımlarını disable etmeniz gerekiyor, bu da sürecin uzamasına neden oluyor. Bu ve benzeri sorunlarla uğraştığınızda da bu sürecin istediğiniz gibi gerçekleşmeyeceğini anlıyorsunuz. Bu noktada alternatif çözümleri araştırdıktan sonra bu geçiş sürecinde veeam kullanmaya karar verdim.&lt;/p></description></item><item><title>“Cannot increase disk size due to old replication participation” hatası ve çözümü</title><link>https://kemalbiyikli.com/cannot-increase-disk-size-due-to-old-replication-participation-hatasi-ve-cozumu/</link><pubDate>Sat, 13 Jan 2024 00:37:32 +0300</pubDate><guid>https://kemalbiyikli.com/cannot-increase-disk-size-due-to-old-replication-participation-hatasi-ve-cozumu/</guid><description>&lt;p>VMware vSphere site to site replication’dan bir sunucuyu kaldırdığınızda ya da VSRM sunucusunu kaybettiğinizde ve replikasyonlarınız dağıldığında VM’leriniz olduğu gibi çalışacaktır. Ancak sunucularınızda disk artırmak istediğinizde &lt;strong>&lt;code>Cannot increase disk size due to old replication participation &lt;/code>&lt;/strong> hatası ile karşılaşmanız muhtemel.&lt;/p>
&lt;p>Sunucuda power on veya power off fark etmeksizin disk kapasitesini artırmak istediğinizde fail olacaktır. Bu problemin çözümünü araştırdığımda ise VMware’in KB’lerini incelediğimde de bir çözüme ulaşamadım. Forumlarda çeşitli çözümler okudum, sizlerle de başarılı olduğum bir çözümü çözümü paylaşmak istiyorum.&lt;/p></description></item><item><title>vCenter Upgrade: Source vCenter has Duplicate Names in a Network Folder Hatası</title><link>https://kemalbiyikli.com/vcenter-upgrade-source-vcenter-has-duplicate-names-in-a-network-folder-hatasi/</link><pubDate>Sat, 23 Dec 2023 00:38:09 +0300</pubDate><guid>https://kemalbiyikli.com/vcenter-upgrade-source-vcenter-has-duplicate-names-in-a-network-folder-hatasi/</guid><description>&lt;p>&lt;img loading="lazy" src="https://kemalbiyikli.com/images/vcenter-duplicate-names/vcenter-duplicate-names-1.jpg">&lt;/p>
&lt;p>vCenter’ınızı upgrade etmek istediğinizde yukarıdaki gibi bir hatayla karşılaşıyorsanız büyük ihtimalle 6.5 öncesi bir sürümü upgrade etmeye çalışıyorsunuzdur. Bu hata vCenter üzerinde aynı isme sahip olan birden fazla Port Group’a sahip olmanızdan kaynaklanıyor.&lt;/p>
&lt;p>Bu problem vCenter 6.5 ile giderildi, &lt;a href="https://docs.vmware.com/en/VMware-vSphere/6.5/rn/vsphere-vcenter-server-650b-release-notes.html">Patch Note&lt;/a>‘larını inceleyebilirsiniz.&lt;/p>
&lt;p>Bu problemi mevcut sürümünüzde gidermek ve upgrade yapabilmeniz için VMware’in bir &lt;a href="https://kb.vmware.com/s/article/2147547">KB&lt;/a>‘si bulunuyor. Ancak KB’yi incelerseniz eğer vCenter Database’ine bağlanmanız, ilgili satır ve sütunları tespit ederek birtakım işlemler uygulamanız gerektiğini göreceksiniz. Ancak daha basit bir şekilde çözmek de mümkün.&lt;/p></description></item><item><title>VMware ESXi CLI Upgrade 7.0>8.0</title><link>https://kemalbiyikli.com/esxi-cli-upgrade/</link><pubDate>Fri, 01 Dec 2023 22:29:14 +0300</pubDate><guid>https://kemalbiyikli.com/esxi-cli-upgrade/</guid><description>&lt;p>ESXi upgrade işlemi birden fazla yöntemle yapılabilmektedir, bu yazımda cli üzerinden esxi upgrade işleminin nasıl yapılacağını aktaracağım.&lt;/p>
&lt;p>Bunun için aşağıdaki adımları takip etmemiz gerekmektedir. Öncelikle offline bundle paketini &lt;a href="http://customerconnect.vmware.com">customerconnect.vmware.com&lt;/a> adresinden download ediyoruz. Download ederken custom bir esxi sürümü mü standart bir esxi sürümü mü kullandığımıza dikkat etmemiz gerekiyor. Ben standart sürüm kullandığım için standart sürümü tercih ediyorum.&lt;/p>
&lt;p>&lt;img loading="lazy" src="https://kemalbiyikli.com/images/esxi-cli-upgrade/esxi-cli-upgrade-1.png">&lt;/p>
&lt;p>Uygun sürümü download ettikten sonra upgrade işlemini yapacağız esxi hosta bağlı olan bir datastore’a upload ediyoruz.&lt;/p></description></item></channel></rss>