VCB

There’s a lot of good information being shared out there! With all due credit to the original authors, here’s a few links that I found particularly interesting or useful. I hope you agree!

• The VI Team Blog posted a list of interesting things in Update 2. They identify things like Enhanced VMotion Compatibility (EVC) and monitoring and availability enhancements. For example, did you know that VM failure monitoring is now fully supported and not experimental? One thing that caught my eye when I first announced Update 2 was VSS support. What I hadn’t really noted about this was the fact that this extends into the application layer, meaning that VSS-aware applications will be quiesced for VCB-based backups. This brings application data consistency to VCB-based backups, and this is a big deal.
• And while we’re discussing the VI Team Blog, have a quick look at part 1 and part 2 of their tips for deploying VI. The discussion of Fibre Channel path selection policy with active/passive storage arrays is particularly helpful.
• Rich over at VM /ETC brought some interesting facts to my attention regarding the free version of ESXi in this post. I was not aware, for example, that the Remote CLI was read-only with free ESXi. Very interesting, and quite useful.
• Duncan at Yellow Bricks has also been pumping out some very helpful information, with an update on HA advanced options and a pointer to a document describing what happens if VirtualCenter crashes. One of the HA options that caught my eye was an option that allows VMotion interfaces to be used for HA. This means that we can easily provide additional HA redundancy simply by configuring VMotion interfaces. Handy!
• Chris Wolf brings to light information on PXE booting ESXi, and in so doing discusses the idea of the “stateless hypervisor.” This is an idea that is gaining a lot of ground, also being the subject of the release of a utility designed specifically around that very idea (but for ESX, not ESXi). When I design a VI environment, I’m already treating the hypervisor as mostly stateless; all the data and “important” information is stored on the SAN. To fully embrace the idea of a stateless hypervisor, we also need to incorporate auto-configuration.

That’s it for now. If any readers have any interesting links they’d like to share, please do so in the comments below. Thanks!

VMware has released Update 2 for VMware Infrastructure 3 version 3.5, which includes updates to VMware ESX, VMware ESXi, VirtualCenter, and VMware Consolidated Backup (VCB). Check the Release Notes for the full details; I won’t reproduce them here, but instead I’ll just point out the particularly interesting details.

Also reporting this information (at the time of this writing) are David from VMblog.com, Rich from VM /ETC, and Duncan at Yellow Bricks. Rich’s post also highlights in red the features that he finds most significant.

Some of the features and/or functionality added in Update 2 that I find most notable include:

• The biggest, in my mind, is VSS quiescing support. This allows VMware snapshots to leverage VSS for more consistent snapshots. Microsoft had been using the lack of VSS support as a key argument against VMware; this tackles that issue head-on. Also surf over to Duncan’s site and see his post about enabling VSS snapshot support in VMware Tools.
• Users can now hot extend a virtual disk (extend a virtual disk while the VM is running).
• Users can clone a virtual machine while it is up and running (live cloning). There is now no need to shut down a VM in order to clone it. I suspect this functionality will have some very interesting repercussions from an operational perspective, and may serve as the basis for future functionality as well.
• VMware now officially introduces Enhanced VMotion Compatibility (EVC), which leverages Intel FlexMigration and AMD-V Extended Migration support. This functionality automatically configures CPUs within a cluster to be VMotion-compatible and won’t allow you to add hosts to a cluster that can’t be configured via EVC to be compatible.

This doesn’t even touch on any of the other numerous features that are supported. Again, go check the Release Notes or one of the linked blogs above for complete details.

The introduction of new features that reduce service interruption—namely, hot extending virtual disks and live VM cloning—is exactly the move that VMware needs to take to further differentiate their virtualization solution from competitors’ solutions. I’ve stated time and time again that innovation in the virtualization space will continue to set VMware apart from the competition.

Before I begin the second installation of Virtualization Short Takes, I thought it was interesting to note that Thomas Bishop over at ScaleTheMind.com has adopted a similar strategy. There’s just so much happening that it’s truly impossible to discuss everything in depth. Even so, it’s often helpful to at least provide the readers with the links and some additional thoughts. It seems like this approach may be the best one to use. I’m certainly open to everyone’s thoughts.

So, on to today’s list of virtualization-related links:

• Frane Borozan has launched p2vbackup.com, a site that describes the process for incorporating virtualization into your backup and recovery process. I haven’t had the time to review the site fully yet, but what I’ve seen looks pretty good.
• Either Duncan Epping at Yellow Bricks just has really bad luck, or he has some sort of link into the VMware Knowledge Base so that he knows when new articles are published. If it’s the former, then his misfortune is our good fortune, as he’s pointed out a potential problem with Storage VMotion that can cause the storage migration to fail and the VM will then not power on. The associated VMware KB article is also available.
• Lou Springer has written a paper on estimating workload consolidation and placement without the use of VMware Capacity Planner. Truth be told, there are organizations that cannot, for whatever reason, leverage Capacity Planner. Lou’s document describes some alternative approaches and some ways of mitigating the risks of those alternative approaches.
• Again via Duncan, here’s some good information on recovering VMFS partitions when you’ve forgotten to set “automount disable” on the Windows-based VCB proxy server. It seems like I recall seeing somewhere that automount was disabled by default on the Standard edition of Windows Server 2003, but enabled on Enterprise. Can anyone confirm that? By the way, it looks like Windows Server 2008 will default to automount enabled.
• And while we’re talking about storage, check out this information from Duncan on Dell’s DRAC Virtual Media functionality and its interaction with VMware ESX Server. Anyone seen similar behavior from HP iLO?
• Via VMblog.com, I saw that Catbird had announced their HypervisorShield, which “is the first virtualized security technology that can monitor and control access to the hypervisor network”. OK, sounds nifty, but I have to side with Christofer Hoff on this one. What exactly is Catbird saying here? Are they protecting the Service Console network interface(s), the VMkernel interface(s), the vSwitches, or something else entirely? Personally, I’m going to wait until I can see more information to make a judgment call on this one.

That’s it for this edition. Feel free to submit any thoughts, suggestions, or rants in the comments below. Thanks for reading!

UPDATE: My recollection on the status of automount in Windows Server 2003 was incorrect. It is enabled by default in Standard, and disabled by default in Enterprise. Thanks to the readers to helped set me straight!

VMware Consolidated Backup (VCB) is a new component of Virtual Infrastructure 3, and is designed to facilitate both full-VM and file-level backups of ESX-hosted virtual machines on a SAN. In its current release, it only supports Fibre Channel SANs, but support for iSCSI is supposedly coming in the next release. When used in conjunction with a third-party backup application (such as Backup Exec) and the appropriate integration software, VCB can provide the ability to backup VMs across the SAN (instead of across the network) without the need to install backup agents on every VM. The speed of backups is pretty good, too.

We performed a number of backups with VCB during our tests:

• File-level backup of Windows-based guest with the guest OS running
• File-level backup of Windows-based guest with the VM powered off
• Full VM backup of Windows-based guest with the guest OS running

All of the preliminary VCB tests listed above were performed using vcbMounter, a command-line tool installed on the VCB proxy server. The command we used looked something like this:

vcbmounter -h vcenter.example.com -u vcbservice
-p <password> -a ipaddr:10.1.1.100 -r E:\VMmount\VM1
-t file -m san

In the specific environment in which this testing was conducted, the hostname (of the VirtualCenter server, in this example) had to be changed from the default of 902, as the customer was using a non-default port number. This threw us for a minute, until we could determine exactly what port on which the server was listening.

This mounted the contents of this VM’s virtual hard disks on the path E:\VMmount\VM1\letters\C, E:\VMmount\VM1\letters\D, etc. We could then, of course, manually launch a backup of the files, but instead we continued with our preliminary testing and chose to wait on the Backup Exec testing until we were comfortable with vcbMounter.

This command worked, but in order to back up the virtual machine while it was shut down, we had to change the command slightly:

vcbmounter -h vcenter.example.com -u vcbservice
-p <password> -a name:VM1 -r E:\VMmount\VM1
-t file -m san

Here, the “name:VM1″ parameter was the name of the VM that we wanted to back up exactly as it appears in VirtualCenter, including case. (We did try this command using the same name with in different case, but it failed.) We could also have used the BIOS UUID for the VM, which can be retrieved using this command:

vcbvmname -h vcenter.example.com -u vcbservice
-p <password> -s name:VM1

Again, the name has to match exactly what is listed in VirtualCenter. One of the parameters returned by this command is the BIOS UUID, which you can then use in a vcbMounter command like this:

vcbmounter -h vcenter.example.com -u vcbservice
-p <password> -a uuid:<BIOS UUID> -r E:\VMmount\VM1
-t file -m san

By using the VM name or the VM BIOS UUID, we were able to make vcbMounter work both when the VM was running as well as when the VM was shutdown. Using the VM’s IP address or DNS name, on the other hand, only worked when the VM was up and running.

Once we felt comfortable with vcbMounter and vcbVmName, we begain testing of the Backup Exec Integration Module (BEIM), a set of freely downloadable scripts designed to provide some automation between VCB and Backup Exec. Although the syntax of Backup Exec’s integration scripts was a bit odd (and I think the documentation was incorrect in spots), the scripts worked well. Using the supplied scripts, we were able to perform both file-level and full-VM backups of selected virtual machines without any manual intervention required (the scripts handled all the mounting/dismounting/etc.). Watch out for spaces in the VCB path or in the VM names, though; they’ll cause the supplied scripts to fail. This article offers some extensions to the Backup Exec scripts that help address some of the shortcomings, including correcting the problem with spaces in the path or the VM name.

While VCB does have its shortcomings, it’s still a very useful tool to have in your backup arsenal. Between VCB full-VM and file-level backups and agent-assisted backups with an agent in the guest OS, there are plenty of ways to protect your virtualized servers.