VMware I&C day 3

Today, we employed some wizard power tools to manage our machine park. Most notably, we learned how to connect two VMware ESX servers underneath one management umbrella and then how to throw virtual machines — even running ones! — from one server to another.

For a live migration to be possible, some rather obvious (and, while you’re doing it, rather irritating) things that need to be satisfied. In short, a VM needs to be able to access the same resources at the source and target server. Thus, file shares that aren’t accessible on the other side, including server-specific ones. No connected CD drives. And most irritatingly, the target server needs to have a virtual switch port group with the exact same name on both sides. The name is Case Significant. But once you have all these things sorted out, you can really move a live VM and you’re not going get practically any downtime. We pinged a host once a second while it was being moved, and after a couple of attempts, we actually managed to get one lost package. From moving a four gig image. Not bad.

But this is skipping ahead of stuff. We actually started the day by creating a template from a configured VM and firing up new VM instances based on the template. You can, and usually should, set some customization to a box you’re “cloning” so that you don’t end up with several Windows boxen with the same SID. But this can all be provisioned for so that you run a sysprep on the new box when it gets deployed. Not bad.

On the topic of cloning installations into templates: You can clone virtual machines into other virtual machines, and you can convert a physical machine into a virtual one. The target image becomes a close approximation of the source box. You’re not really cloning the hardware platform you’re running on, but transferring your physical machine onto a VMware software platform. Still, it’s a pretty impressive feat, and usually what you want to do. It just isn’t cloning in the forensic sense of the word. And it doesn’t get less impressive by the fact that you can clone a running machine and the only thing that is affected on the source installation is that the CPU meter goes up a notch and your network connection is saturated. It’s like stealing your soul. Pretty nice

A remarkable feature or by-product of the converting, as well as creating a new server from a template, is that your network interface’s MAC address changes. Stamping out new servers from a common template will not make your network cry. Again, nice.

Cloning and converting works well on Windows boxen that you install the VMware tools on, and reasonably well on Linux boxen with those same tools. You will need to install SCSI drivers on the source box yourself (as i lamented yesterday about the otherwise nifty Ubuntu JeOS distribution).

Not all VMs need to be created equal. There are two ways you can manage your VM (and host) resources: per server and per resource pool. The easiest way is just to edit the resource properties of a VM and say that it’s not going to get more than this or that amount of memory, disk i/o or CPU cycles. The more realistic way is that you create a resource pool to which you allocate so and so much resources and throw your production servers in a more-privileged production pool while keeping the testing (or accounting servers in a pool which gets whatever is left after the machines in the hungrier pool(s) get their shares. Which incidentially is the term for how much resources a VM is going to get within a pool — shares, that is. The more shares (karma), the higher part of the cake can be allocated a VM if the resources are scarce.

Misc bits:

• We got to install a small Linux-based router running on Freesco. Freesco must have been graph-designed by somebody on acid, but otherwise it’s a rather nifty thing.
• We poked around with rights management for the VM environment, which happily is based on Role Based Access Control (RBAC) and allows a single user to have many roles (yay!). 
• A VM can access a raw LUN over the net. This can be a good thing if you want to cluster VMs… they say.
• You can increase the size of a disc a VM sees. This will not increase the size of the underlying file system (which makes sense if you think about it). To remedy, boot up the VM with a GParted LiveCD mounted and resize. Works wonders.
• We accessed the ESX using http, which can be nice because you can send a link to a colleague or consultant who also can access a given interface machine over http.
• We touched importing and exporting VMs using the Open Virtual machine Format (OVF) which may or may not be natively supported by any other manufacturer, but at least they’re free to support it at will.

And that’s about the size of it for today.