VMware just changed their VCB multipathing support. Before the KB article stated “Powerpath and other multipathing software.” The KB article has been changed and contains specific version of Powerpath which are officially supported and the “other multipathing” has been removed. Still I’m no fan of multipathing software on the VCB host, I would prefer using 1 HBA for uploading to a holding tank and 1 HBA for downloading the images from the SAN.
BC-DR
VCB and identical LUN id’s
I get this question a lot:”Does the VMware Consolidated Backup proxy host need to have the same LUNs with the same ID’s presented?”.
VMware Consolidated Backup needed to have identical LUN ID’s to be able to match LUN’s but that has changed. It doesn’t matter anymore which LUN ID your host and proxy server see cause VCB just compares VMFS signatures. So I can hear you guys thinks, what about my RDM’s? (Raw Device Mappings) Well obvious VCB can’t compare the VMFS signatures, but it can compare the NAA ID’s and that’s what it does as of VCB 1.1. So in other words, as long as you just publish all LUNs you want VCB to backup it doesn’t matter which LUN ID they have.
And if for some reason your SAN doesn’t support NAA ID’s, well then you will be stuck with the “matching LUN ID’s” method you have been using for a while.
By the way NAA stands for “Network Address Authority” and is a unique identifier for you LUNs.
VCB and independent disks
Most of you probably knew that it is impossible to snapshot an independent/persistent disk. And if you didn’t, in short: a disk that is in “independent/persistent” mode can’t be snapshot because it needs to write it’s changes immediately to the virtual harddisk. When using a snapshot(nonpersistent) writes go to a delta file.
So as I said in this article, using this mode on a specific disk is a nice way to get the full image VM without for instance that gigantic data disk. But some of you might need the snapshot functionality, and it’s not possible to change the disk state from the VirtualCenter client when the VM is up and running.
But it is possible to change the state via the command-line when the VM is running. So if you want to change the state in a VCB script for a specific disk, or want to change the state for a VM without shutting it down here you go:
Find out what the current mode is from the command line:
vmware-cmd <path to vmx file.vmx> getconfig scsi0:0.mode
Set the new mode from the command line:
vmware-cmd <path to vmx file.vmx> setconfig scsi0:0.mode “persistent”
Keep in mind that this is, as far as I know, not supported and should be tested thoroughly before using. I would prefer doing it manually and keeping it that way. Or you could always use the script that I blogged about a while back, it makes it possible to dump specific disks without having to resort to unsupported methods.
By the way, with the setconfig option you can set most vmx options!
VCB best practices
The VCB best practices document has been revised. So be sure to download it and use the latest best practices.
Future version of VCB not an installable anymore
VMware just dropped the news that the future version of VCB will not be an installable anymore. VCB will be an API. This will save you that additional (proxy) host that it will normally cost you. This probably also means that software vendors can take the full advantage of their own unique abilities like deduplication, direct restore into a VM… Agentless backups in a decent way. I’ve always thought that VCB was underestimated by a lot of people, but I guess I did know why. This should solve most of the problems people were facing with the integration modules and scripting.