A colleague recently stumbled upon this beautiful error when trying to import an OVA to an ESX and ESXi host:

Unsupported element 'VirtualSystemCollection'

The cause is that the packaged OVA is actually a vApp extract from vCenter, and standalone hosts (not under management of a vCenter) are not able to accomodate vApp.

From VMware

vApps: Ensuring seamless application movement and choice between clouds

It seems a single host isn’t “cloud”-enough.

An OVA that is extracted from vCenter which contains only a single VM is extremely close in its structure to the OVF apart from a tuple called … *drum roll* … <VirtualSystem ovf:id="cake"> in the single, and <VirtualSystemCollection ovf:id="cake"> in one that encompasses multiple machines. So a hosts ability is limited to not being able to parse this collection of machines and discriminate between their properties, that’s why you need to spend $ on vCenter!

–

This is all great, but my colleague is now stuck half-way around the world with a set of machines that need to be deployed on a single host, and all of them are saved within this OVA.

An OVA is just a wrapper for an OVF (think VMX) and some VMDK’s {anyone VM/OVconfused yet?}.


$ tar tf cake.ova
cake.ovf
cake-disk1.vmdk
cake-disk2.vmdk
cake-disk3.vmdk
cake-disk4.vmdk
cake-disk5.vmdk
cake.mf


We can see there’s a collection of VMDK’s, the manifest which inside looks like this:


SHA1(cake.ovf)= 03AD765EC45B90E13BC22D0115088F08021F2AE5
SHA1(cake-disk1.vmdk)= 92BB519FD1926D4F3C170C727C037E2D5D79775B
...


… and more importantly the OVF, which describes the OVA motherload.

My thoughts were at first to just create a VMX for each of the VMDKs and then I can go to bed. Unfortunately one of the machines has two disks, so the first issue is with figuring out how the OVF nests the rasd – Resource Allocation Setting Data (as per the DMTF OVF Specification V1.1).

Thanks to Mr. Pekka for writing xmlindent or you could just use the online version

I was quickly able to see to which VM disks 3+4 belonged to, and create the appropriate VMX skeleton. Now if only there was a parser…

ESX doesn’t have NAT inbuilt, so here’s how to configure it with the help of a VMware appliance called pfSense (an Open Source [free!] firewall/router).

There are three components in this setup:

1. Host
2. router/pfSense
3. NAT Client

Host

A great read for beginners and those refreshing is the VMware Virtual Networking Concepts whitepaper

Now lets create a network that our NAT’ed VMs will be using.

When prompted under Connection Type, select a ‘VM Network’, as this is for the typical traffic within the Virtual Machine (not IO or management of your machines).

Lets create a vSwitch that doesn’t connect to anything, a dud, a blankie. This will be our NAT’ed environment. It’s quite important that you DON’T connect a network card to this vSwitch to prevent any inadvertent DHCP leakage. Make sure you have nothing selected.

Give it a name to differentiate.

Once you’re done, click finish and you will have something two network available to your VMs:

• VM Network
• NAT Network

Time to setup pfSense. Once you’ve downloaded and extracted it. You have the option of either copying it directly to your datastore and then adding directly to inventory, or importing via the Standalone Converter. I find the latter is always faster.

router/pfSense

Incase you’re converting pfSense first (like I did whilst re-doing it for this post), I recommend you disable the network interfaces until you’ve finished setting up the host networks. We’ll enable these in a later step.

Disabled interfaces

Once the conversion is complete, time to configure our virtual router. pfSense is provided with two NICs out of the box. One for the WAN interface (which is your internal LAN), and one for ‘its’ LAN – the one on which it will be servicing DHCP requests.

Mark down the last 4 digits of the MAC address, these will help to validate the following step.

Configuring pfSense NICs

Start the pfSense VM. You will be guided through the mapping of the interfaces, and just to make sure – check to see the MAC addresses matching to the VM Network (in my case 67:3c) and NAT Network (67:46).

Upon following the wizard, and if you’ve followed everything accordingly (or rather I documented the steps properly) you will be shown the interfaces within pfSense, their mapping (WAN vs LAN) and IP addresses.

NAT Client[s]

You are now ready to assign clients on this host to the NAT Network and have them pick up addresses dished out by your shiny new appliance.

The whole setup takes just under 5 minutes from start to finish to complete.

Exception when adding a network - click to enlarge

Adding a new port (i.e. a vMotion interface) to a vSwitch on vSphere/ESX leads to this lovely error message. If you check your vpxd.log you’ll see something the image verbalised.

[2010-06-04 15:30:52.411 03152 info 'App'] [VpxLRO] — ERROR task-54417 — host-36589 — vim.host.NetworkSystem.updateNetworkConfig: vim.fault.PlatformConfigFault:
(vim.fault.PlatformConfigFault) {
dynamicType = ,
faultCause = (vmodl.MethodFault) null,
text = “SysinfoException: Node (VSI_NODE_net_tcpip_plumb) ; Status(bad0017)= Out of resources; Message= Instance(0): Input(4) if=0 portset=VMkernel macaddr=00:50:56:76:16:67 tsomss=65535 “,
msg = “Error during the configuration of the host: SysinfoException: Node (VSI_NODE_net_tcpip_plumb) ; Status(bad0017)= Out of resources; Message= Instance(0): Input(4) if=0 portset=VMkernel macaddr=00:50:56:76:16:67 tsomss=65535 “,
}

Key here is the Out of resources; message. The reason for this is none other than the default number of ports for the vSwitch on ESX is 24, and if you have VM’s or other interfaces using up ports (such as AppSpeed probes), you will quickly run out. Switch this easily by going to Configuration -> Networking -> Properties [for the vSwitch in question] and up the value up to and including your growth requirements for the future.

NOTE: After you setup a new host, set it to more ports than you require, as you’ll need to restart the host for the ports to be provisioned; best to do this immediately after installation.

I think a better message would be to explicitly say “Out of available ports on vSwitch – [blah]“; instead of the semi-cryptic one presented.

Am currently working on automating WebSphere Portal install on Windows. I do not want Windows restarting the first time it comes up, whether its for installing VMware Tools, or any of its drivers.

What I require is to add the VMware Video drivers to the base Windows installation. This will work for XP/Windows 2003. You can easily integrate the drivers once you’ve found them with the use of nLite. The trick is in finding them.

First thing you’ll need is the VMware Tools ISO that we discovered a couple posts back.

Exploded VMware Tools ISO

NOTE: I rename ‘VMware Tools[64].msi to vtools[64].msi’

The next step is to extract the vtools64.msi which you can accomplish with:
msiexec /a vtools64.msi /qb TARGETDIR=c:\driver\

Extracting VMware Tools

After a few seconds, you’re done. By navigating to the Common64\VMware\Drivers\Video folder, you will find the vmx_svga.inf that you need for nLite as well as the vmx_svga.sys which is the driver. When it comes to nLite – just point it to the directory.

VMware video directory listing
vmwogl32.dll
vmwogl64.dll
vmx_fb.dll
vmx_mode.dll
vmx_svga.cat
vmx_svga.inf
vmx_svga.sys

Kickstarts are wonderful. Simple and effective. The ability to automate the mundane installations for *nix all about. In my case, I need to automate the installation of hosts that will be booting from SAN.

We have an admin that once installed a couple of ESX hosts atop other host’s boot LUNs. It’s pointless blaming the admin, as there’s a basic rule that must be followed at all times that will prevent this from happening.

NOTE: Don’t let the host see boot LUNs for any other host than itself.

ESX Dedicated Boot LUNs

This can be accomplished with:

• LUN Masking (on the host HBA)
• SAN Zoning (on your fabric)
• Port Grouping (on your storage)

Horror story aside, lets have a look at a basic kickstart for the ESX. When you install ESX by hand, it creates a ks.cfg file in root’s home. Inside you will find the host configuration at the time of install.

ASSUMPTION: You have already provisioned the necessary space on your SAN for your host, and have mapped the host access to that LUN.

After a few modifications and some cleanup, I ended up with the following

accepteula

EOF


I set out to install onto the FIRST available drive. In my case, thats always LUN 0, and if by some accident there's already a VMFS on it - installation will cease (you can accomplish a force through by adding --overwritevmf to the clearpart line.

ESX Kickstart Installation

Once the setup completes you will be greeted with a "Press to reboot" - in a normal RedHat install you can get around this by adding reboot --eject just before the %post statement. Unfortunately this doesn't seem to work for ESX. I'll update the post once I find a way.

You may notice that I keep referring to HOSTNAME - that's because the ks.cfg is part of another script which puts together a custom ISO for each of our blades.

Whenever you update your host, there’s a chance that VMware tools have been updated.

To get them, head over to “/vmimages/tools-isoimages” on the host and you’ll be greeted with:

If you’re just after the rpm then rip open the ISO and you’re done.

The caveats of running vCenter within a VM has been written about to death. So I will mention only what I never found in those posts that is relevant to the environment within which I work:

greater virtual performance over physical

Not every environment is large enough to dedicate a whole 8/12/40/96 GB of RAM Blade to a vCenter. Its simply a waste; the premise on which people dive into virtualisation is that green feeling, saving the environment or the saving the USD.
So businesses tend to ‘donate’ a physical box that will be the nucleus of their virtual offering. Yet this tends to be an underpowered, not-far from decommission door stopper.
As a Virtual Machine, you’re able to utilize the benefit of prompt resizing of the hardware, and at the ability to easily place it on higher-powered machines.

That’s the benefit, although what REALLY happens when you decide to move your vCenter around?

vMotion Mission Statement:

… Storage VMotion lets you relocate virtual machine disk files between and across shared storage locations while maintaining continuous service availability and complete transaction integrity.

To me, that reads – “stuff will happen while we move your data”.

Unfortunately that isn’t always the case. Here’s the scenario.

Host
- DS1
- DS2
- DS3

vCenter was living on DS1 (slow-LUN), and I wanted to put it across to DS2. Since vCenter is very important, it’s continuous service availability is crucial. Read: {perfect candidate for svMotion}.

The message that never went away

What happened next is counterintuitive to the credo. The vSphere client freezes, and no new connections can be made to vCenter. If you start monitoring the datastores (kudos to VMware) the VM is actually being transferred.

Once the migration completed, the first time I had to reconnect the vSphere Client; I wasn’t happy with this outcome. So I attempted a DS2->DS3 (both fast-LUNs). Not only did my connection to vCenter not drop this time, but the whole process was seamless and worked as advertised.

vCenter Migration

I ended up moving the VM in which I house SQL Server (vCenterDB) in the same fashion to the faster LUNS, and everything proceeded to operate as designed.

Lesson learnt: get decent storage.