Home Lab

I have a small Home Lab for vSphere, based on two Intel NUC hosts running ESXi and an HP Microserver running FreeNAS, presenting datastores as iSCSI LUNs to the hosts.

The vCenter is a vCenter Server Appliance (VCSA) running on one of the ESXi hosts.

The initial setup was fairly straightforward and you can find plenty of other people who have done similar things.

The Problem

One of the difficulties/limitations of using the Intel NUC is that each machine has a singe NIC. That makes creating a Distributed Virtual Switch (DvS) quite difficult as when migrating the host running vCenter to the DvS, the vCenter loses contact with the host and rolls back the migration.

I figured I could live with standard switches, and if I really needed to use DvS I could use nested ESXi with multiple virtual NICs.

A Workaround

Recently I discovered an excellent blog article by Larus Hjartarson titled “vCenter & Distributed vSwitch on two ESXi hosts with a single NIC“. This suggests a workaround for the migration issue mentioned above.

The outline of the workaround is:

1. Create the DvS on the host that doesn’t run vCenter.
2. Move that ESXi host  to the Distributed vSwitch. Create VM traffic portgroups.
3. Clone the vCenter VM and place it on the ESXi host that doesn’t run the vCenter VM.
4. Connect the newly cloned vCenter VM to a Distributed Portgroup on the ESXi host (that was connected to the DVS previously)
5. Turn off the original vCenter.
6. Turn on the cloned vCenter and configure the network settings
7. Move the other host to the Distributed switch.

Some things I encountered which might help others attempting this:

VCSA changes MAC address when cloned

If you’re using the VCSA for your vCenter, when you clone it the MAC address changes so it won’t come up properly. There’s a VMware KB article on how to work around that:
http://kb.vmware.com/kb/2012451 – basically you edit the /etc/udev/rules.d/70-persistent-net.rules file so that the new MAC address is associated with eth0.

iSCSI vmknics cannot be migrated

If you’re using iSCSI-based storage, you cannot migrate a host to the DvS until you remove the vmknic from the software iSCSI adapter, which means having no iSCSI-stored VMs running on the host at the time.

You can’t vMotion the VMs to the other host as they’re on a standard vSwitch and the other host is on a DvS. Even if you leave the old standard vSwitch in place on the other host, vMotion will still abort as it sees the old portgroup as a “virtual intranet” (i.e. no uplinks). So you have to shut down the VMs to move them. That’s when it becomes important to either have two DNS servers, DNS served outside your VMware setup or your host names in the vCenter hosts file.

VMware do have an KnowledgeBase article on the “virtual intranet” problem which has a workaround based on editing the vCenter config file but I have not tried that.

I hope that information proves useful to anyone else using single-NIC hosts for a Home Lab.  Obviously I wouldn’t recommend doing any of this on a production environment, but then I’d hope that a production environment wouldn’t be using single-NIC hosts anyway!

Recently came across a problem when trying to access a parallel port dongle from a Workstation machine.

The VM was configured with a virtual parallel port, and the host machine had a PCI parallel port card installed which was recognised by the host OS (Windows 7 in this case).

Every time the VM was started, Workstation threw an error along the lines of:

Cannot open VMparport driver for LPT3:
Failed to connect virtual device parallel0

After looking round the VMware Communities for a while, I found the solution.

The PCI Parallel Port card was installed after VMware Workstation. During the Workstation installation process, the installer looks to see whether the host has a parallel port, and if it does it installs a driver allowing VMs to access the port. If there’s no parallel port, the driver doesn’t get installed.

The problem here is that if you add a parallel port afterwards, there’s no virtualisation driver for it, resulting in the error above.

The solution is to uninstall and reinstall VMware Workstation after the hardware change. Reinstalling doesn’t affect any settings or VMs as long as you tell the uninstall process not to delete anything.

This probably applies for VMware Server and Player too.

I’ve recently reported a couple of annoying bugs to VMware. Both have been around for a long time, almost certainly since the days of Virtual Center 2.0, maybe even earlier.

• If a VM has nothing in the “Notes” annotation, vCenter displays the “Notes” from the previously selected VM instead.
  So if you have a machine with a note saying “Delete after 1st Jan 2011”, and you then view the summary of a machine with no note set, it’ll display the “Delete after 1st Jan 2011”. That could be bad…
  The problem only occurs if the VM has never had any Notes annotation. If you set one and then remove it, it shows the blank note correctly.
  **UPDATE** – This appears to be fixed in 4.1 U1 – it only seems to affect VMs which were deployed without notes under VirtualCenter 2.x.
• When deploying a VM from a template, the Tasks & Events history doesn’t correctly name the template from which the VM was deployed.
  As you can see in the example image, vCenter lists the deployed VM name instead of the template. 

  

Click for full size

** UPDATE ** VMware have acknowledged this as a bug but it will not be fixed until vSphere 5, later this year.

And there’s a cosmetic thing which winds me up. I haven’t reported it as a bug but if anyone from VMware reads this, maybe they can have a word. It’s really trivial….

“Send Ctrl-Alt-del“. What has “del” done to deprive it of a capital “D”?

VMware Fusion also has a “Send Ctrl-Alt-Del” menu option but it gets the capitalisation right. I can only offer this as proof that Macs are better than PCs… or something.