the birdhouse in my soul

VMware's solution to a lost or forgotten root password for ESXi is simple: go to  https://kb.vmware.com/s/article/1317898?lang=en_US  and you'll find that "Reinstalling the ESXi host is the only supported way to reset a password on ESXi". If your host is still connected to vCenter, you may be able to use Host Profiles to reset the root password, or alternatively you can join ESXi in Active Directory via vCenter, and log in with a user in the "ESX Admins" AD group. If your host is no longer connected to vCenter, those options are closed. Can you avoid reinstallation? Fortunately, you can. You will need to reset and reboot your ESXi though. If you're ready for an unsupported deep dive into the bowels of ESXi, follow these steps: Create a bootable Linux USB-drive (or something else you can boot your server with). I used a CentOS 7 installation USB-drive that I could use to boot into rescue mode. Reset your ESXi and boot from the Linux medium. Ident...

Updating the VCSA is easy when it has internet access or if you can mount the update iso. On a private network, VMware assumes you have a webserver that can serve up the updaterepo files. In this article, we'll look at how to proceed when VCSA is on a private network where internet access is blocked, and there's no webserver available. The VCSA and PSC contain their own webserver that can be used for an HTTP based update. This procedure was tested on PSC/VCSA 6.0. Follow these steps: First, download the update repo zip (e.g. for 6.0 U3A, the filename is VMware-vCenter-Server-Appliance-6.0.0.30100-5202501-updaterepo.zip )  Transfer the updaterepo zip to a PSC or VCSA that will be used as the server. You can use Putty's pscp.exe on Windows or scp on Mac/Linux, but you'd have to run "chsh -s /bin/bash root" in the CLI shell before using pscp.exe/scp if your PSC/VCSA is set up with the appliancesh.  chsh -s /bin/bash root "c:\program files (x86)\put...

I did not yet update my older post when vSphere 6.7 was released. The list now complete up to vSphere 6.7. Your Linux runs on a VMware VM, but which on which ESXi version? You can see for yourself: run "dmidecode" and look at lines 10, 11 and 12. ESX 2.5 - BIOS Release Date: 04/21/2004 - Address 0xE8480 - Size 97152 bytes ESX 3.0 - BIOS Release Date: 04/17/2006 - Address 0xE7C70 - Size 99216 bytes ESX 3.5 - BIOS Release Date: 01/30/2008 - Address 0xE7910 - Size 100080 bytes ESX 4 - BIOS Release Date: 08/15/2008 - Address 0xEA6C0 - Size 88384 bytes ESX 4U1 - BIOS Release Date: 09/22/2009 - Address 0xEA550 - Size 88752 bytes ESX 4.1 - BIOS Release Date: 10/13/2009 - Address 0xEA2E0 - Size 89376 bytes ESXi 5 - BIOS Release Date: 01/07/2011 - Address 0xE72C0 - Size 101696 bytes ESXi 5.1 - BIOS Release Date: 06/22/2012 - Address: 0xEA0C0 - Size: 89920 bytes ESXi 5.5 - BIOS Release Date: 07/30/2013 - Address: 0xEA050 - Size: 90032 bytes ESXi 6 - BIOS Release Dat...

Most VMware appliances (vCenter Appliance, VMware Support Appliance, vRealize Orchestrator) have the so called VAMI: the VMware Appliance Management Interface, generally served via https on port 5480. VAMI offers a variety of functions, including "check updates" and "install updates". Some appliances offer to check/install updates from a connected CD iso, but the default is always to check online. How does that work? VMware uses a dedicated website to serve the updates: vapp-updates.vmware.com. Each appliance is configured with a repository URL: https://vapp-updates.vmware.com/vai-catalog/valm/vmw/PRODUCT-ID/VERSION-ID . The PRODUCT-ID is a hexadecimal code specific for the product. vRealize Orchestrator uses 00642c69-abe2-4b0c-a9e3-77a6e54bffd9, VMware Support Appliance uses 92f44311-2508-49c0-b41d-e5383282b153, vCenter Server Appliance uses 647ee3fc-e6c6-4b06-9dc2-f295d12d135c. The VERSION-ID contains the current appliance version and appends ".latest":...

In a recent VMware project, an existing environment of vSphere ESXi hosts had to be split off to a new instance of vCenter. These hosts were member of a distributed virtual switch, an object that saves its configuration in the vCenter database. This information would be lost after the move to the new vCenter, and the hosts would be left with "orphaned" distributed vswitch configurations. Thanks to the export/import function now available in vSphere 5.5 and 6.x, we can now move the full distributed vswitch configuration to the new vCenter: In the old vCenter, right-click the switch object, click "Export configuration" and choose the default "Distributed switch and all port groups" Add the hosts to the new vCenter In the new vCenter, right-click the datacenter object, click "Import distributed switch" in the "Distributed switch" sub-menu. Select your saved configuration file, and tick the "Preserve original distributed switch...

In vSphere 6, if the vi-admin account get locked because of too many failed logins, and you don't have the root password of the appliance, you can reset the account(s) using these steps: reboot the vMA from GRUB, "e"dit the entry "a"ppend init=/bin/bash "b"oot # pam_tally2 --user=vi-admin --reset # passwd vi-admin # Optional. Only if you want to change the password for vi-admin. # exit reset the vMA log in with vi-admin These steps can be repeated for root or any other account that gets locked out. If you do have root or vi-admin access, "sudo pam_tally2 --user=mylockeduser --reset" would do it, no reboot required.

While playing around with the bios.bootDeviceClasses parameter (as shown in this example ), we found out that a device not specified in allow: would still be used if all "allow:"ed devices are unusable (no CD connected, no PXE server found, etc.) a device specified in deny: would still be used if all other devices are unusable. So contrary to what the documentation suggests, "allow:" will just move certain devices to the front of the boot device list, and "deny:" moves those devices to the end of the list. Hope this can help other people trying to make sense of setting boot order in a VM to achieve a specific behavior. In our case: get a VM to reliably boot from CD for automated deployment using the SDK.

(An update of an older post: now with vSphere 4.1 info. Further updated in 2011 with vSphere 5 info.) Your Linux runs on a VMware VM, but which ESX version is it ? You can see for yourself (as already explained in an earlier post on this blog). Run "dmidecode" and look at lines 10, 11 and 12. The list has been updated with current info: ESX 2.5 - BIOS Release Date: 04/21/2004 - Address 0xE8480 - Size 97152 bytes ESX 3.0 - BIOS Release Date: 04/17/2006 - Address 0xE7C70 - Size 99216 bytes ESX 3.5 - BIOS Release Date: 01/30/2008 - Address 0xE7910 - Size 100080 bytes ESX 4 - BIOS Release Date: 08/15/2008 - Address 0xEA6C0 - Size 88384 bytes ESX 4U1 - BIOS Release Date: 09/22/2009 - Address 0xEA550 - Size 88752 bytes ESX 4.1 - BIOS Release Date: 10/13/2009 - Address 0xEA2E0 - Size 89376 bytes ESX 5 - BIOS Release Date: 01/07/2011 - Address 0xE72C0 - Size 101696 bytes

I've been into virtualization for a long, long time, so I was familiar with the USB-over-IP concept. It has always been the preferred way to bring USB into a virtual machine, because it doesn't limit the flexibility of virtualization: live migration (vMotion), failover (HA), fault tolerance, ... can all handle USB-over-IP. But I was still surprised to find a cheap USB-over-IP device in a local computer store: the Belkin Network USB Hub , NUH for short. 100 USD list price, became EUR 90 retail price here in Belgium. Not the greatest deal around, but no reason to feel grumpy. Now let's see what this baby can do: the test setup consists of the Belkin NUH and two clients: a Windows Vista 32-bit laptop connected over WiFI and a Windows 2008 R2 64-bit VM on VMware vSphere connected over wired GigE. Then I gathered a diverse set of USB devices: USB memory sticks, USB hard drives, a USB smartcard reader, and a USB CD/DVD writer. The NUH gets a DHCP address by default (can be change...

That's an easy question, and the answer isn't too difficult either: Query the MAC address of the local network card. If it starts with "00:50:56", that indicates that it's a VMware VM. List devices on the PCI bus. If there's devices with vendor ID 15ad, you can be sure that this is a VMware VM. Look at the BIOS information (DMI). If you see Manufacturer "VMware, Inc", and the serial number starts with "VMware", and the Product Name is "VMware Virtual Platform", that's again very clear. In a typical VMware VM, you should find the VMware Tools running: the vmmemctl driver, maybe the vmxnet network card driver maybe, the vmware-guestd or VMwareUser or VMwareTray processes, ... And here's a practical list of tools you'd use to run these checks: use "/sbin/ifconfig eth0" on Linux, "ipconfig /all" on Windows. You can do this as a normal user. use "/sbin/lspci" on Linux. Also possible as a norma...

Anyone following VMware's enterprise offerings will know that VMware has been "in bed" with Red Hat for a long time. The "service console" of the ESX product has been Red Hat Linux and Red Hat Enterprise Linux based since the beginning, and many of the virtual appliance-based products (VMware Data Recovery e.g.) are RHEL or CentOS based. But now VMware comes with a partnership announcement with Novell/SuSE, not Red Hat ! Anyone buying vSphere will get SLES for free, including patches ! Note, the offer isn't fully up just yet, they forecast a GA launch in 3Q2010. But anyone buying vSphere starting today (june 9th) will be in on the offer when it launches. Beware, "free" doesn't include support, from what I read in the press release. But SLES support will be available through VMware. A lot of questions are waiting for an answer: Will this deal impact the place RHEL and CentOS held in the VMware solution stack ? What will be the response from Red...

Your Linux runs on a VMware VM, but which ESX version is it ? You can see for yourself (as already explained in an earlier post on this blog). Run "dmidecode" and look at lines 10, 11 and 12. The list has been updated with current info: ESX 2.5 - BIOS Release Date: 04/21/2004 - Address 0xE8480 - Size 97152 bytes ESX 3.0 - BIOS Release Date: 04/17/2006 - Address 0xE7C70 - Size 99216 bytes ESX 3.5 - BIOS Release Date: 01/30/2008 - Address 0xE7910 - Size 100080 bytes ESX 4 - BIOS Release Date: 08/15/2008 - Address 0xEA6C0 - Size 88384 bytes ESX 4U1 - BIOS Release Date: 09/22/2009 - Address 0xEA550 - Size 88752 bytes

Open source email and calendar solution provider Zimbra got acquired by VMware recently. While there's lots of angles to this story, it also confirms an important part of VMware's strategy: bigger and bigger hardware, running a powerful hypervisor, running thin and optimized OSes, running applications that perform business functions. To enable perfect mobility and ease-of-use, the OS and application will be packaged into so-called Virtual Appliances or vApps. Making the OS thinner is essential for this strategy, and goes against the core beliefs of competitor Microsoft. The succes of the vApp concept will be a deciding factor in the battle between these two giants.

VMware has announced a 6-month promotion, where students who participated in an official VMware training can get 10% off the regular price of the VCP4 exam, until the end of june 2010. If you plan on doing the VCP4 certification, contact your instructor as soon as possible. He'll give you a personal promotion code that you can use when registering for the VCP4 exam at Pearson Vue. (Yes, that instructor might be me ! ;-))

One of the first steps in a virtualization project is building a list of workloads that will get virtualized, with a measurement or estimate of the resources that they will need. X MHz and Y MB, sum everything up, and let's say you get 30 GHz of CPU power and 20 GB of RAM. The hardware you'd like to run all those virtual machines on can handle two CPUs (dual-socket), four cores each (quad-core). That means that every physical server will give you between 20 and 25 GHz of CPU power. For memory, you'll buy 12 GB of RAM in each server. So the plan is to buy two of those servers, right ? Well, as long as your infrastructure is 100% healthy and running OK, two servers will do the job just fine. You've got enough resources, with a bit of headroom for overhead and future growth. But what happens when one of the physical servers is down ? Think of hardware problems, think of virtualization software upgrades, think of patching the hypervisor. Then the available resources are dow...

When you're shopping for ESX servers to build your next production cluster, you know where to look. The hardware compatibility lists at vmware.com are frequently updated, and contain everything you need to know. But what about test labs ? When you don't care too much about "is it supported" but rather ask yourself "does it work" and "can I buy something cheaper" ? I asked myself the same questions when I built my own testlab. And this was my choice: 2 identical PCs, equipped with MSI MS7345 motherboard Q6600 intel CPU 8 GB of RAM (four times 2 GB) PCI Promise SATA 300 TX2plus 80 GB sata harddrive (smallest I could get) a dual port Intel gigabit card Add a third PC, similar but with more diskspace, running CentOS 5 with IET as an iSCSI server, and you get a 19 GHz, 16 GB VI3 cluster with several hundred GB storage space. Perfect for testing, and without losing an arm and a leg paying for them.

So you're running the new ESX 3.5 update 2. And you want to try the new EVC feature on your cluster. And you've found it under "edit settings" on your cluster object... And then VirtualCenter refuses to enable it for you, because there is still at least one VM powered on in the cluster. Of course there is, because your VirtualCenter runs in a VM, in that same cluster. Catch-22 ? Well, getting round this is a bit weird, but nevertheless possible. Here's what I did on my two-node test cluster: Step one: you evacuate one ESX host in your cluster. You put it in maintenance mode, and move it out of the cluster, right under your datacenter object. Two: manually migrate (VMotion via drag-and-drop for example) your VirtualCenter VM (running on a host in the cluster) to the host that is now outside the cluster. Do this with all other VMs that were still running in the cluster. Three: enable EVC on your cluster. This now works, because the cluster doesn't contain any ru...