Yellow Bricks

by Duncan Epping

VCB

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!

 

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.

VCB errors

· ·

I’ve been doing VMware Consolidated Backup troubleshooting for the last couple of days. A customer ran into problems that I can’t comment on at this moment. But after an upgrade of VCB 1.1 to VCB 1.5 the customer ran into a new limitation of VCB. After 30 VM’s the script stopped working, the following error was thrown at us:

‘vcbMounter’ 5648 error] Error: Cannot mount volume 1, service not accepting new devices.

After a few search actions I noticed the following in the documentation which is clearly a new limit in VCB 1.5:

NOTE Consolidated Backup supports a maximum of 60 concurrently mounted virtual machines. For example, you can concurrently mount 60 virtual machines that have a C: drive, or 30 virtual machines that have a C: and a D: each.

In other words, no more than 60 vmdk’s maybe mounted concurrently. This limit wasn’t in 1.1, well not hard coded anyway… but 1.1 still has it’s limitations!

Clearly, on the part of having more than 5 concurrent VCB dumps, I know that this isn’t a best practice but for this customer it’s what they want and need. I stronly advise against it for any environment though! Follow the best practice of a maximum of 5, and set it up in a way that it involves 5 different datastores!

We are currently investigating other options and trying to find out what the max concurrent connections should be within the environment of this specific customer. Taking all kinds of different factors in consideration like “vmfs locking”, “scsi reservations”, stress on the vmkernel and or service console, diskspace occupation combined with fast growing snapshots etc.

I’ve been looking into VMFS locking associated to snapshots. VMFS locking occurs when metadata changes, in other words it happens with one of the following actions: snapshot file growing, vm starting(cause the file is being locked for read/write), file creation etc.

VMFS Locking means that there is only 1 host able to access the VMFS until the lock is released. So you can imagine what happens when there are 5 vm’s on the same VMFS on five different ESX hosts with snapshots that are growing! It will be like a monday morning traffic jam! So please don’t over do it.

I’ve also got the feeling that VCB is probably the most underrated and misunderstood product out there. I’ll be the first to admit that “file level” backups with VCB isn’t always as convenient as it should be but this is also due to the fact that not every Backup vendor has developed a decent integration module. But for instance CommVault Galaxy has got a special agent for VCB file level backups. This agent makes it possible to do a file level backup via VCB and restore direct to the VM via the agent! Check this PDF for more info on their solution. Full Image backups on the other hand are very useful for DR purposes but can also be used to restore single files again. You can mount the VMDK and browse the folders for the file. You can also use Vizioncore’s vRanger or Veeam’s “Veeam Backup” for a third party add-on to VCB. Both products are definitely worth checking out, and are a great extension to an often overlooked product!

Talking about Full Image Level backup’s besure to read this article, it will save you disk space on your “holding tank” and Tape Library!

New VCB feature

· ·

One of the best new VCB features is SSPI Authentication. Consolidated Backup can now authenticate using SSPI when it is configured to connect to VirtualCenter. With SSPI, passwords do not need to be stored as plain text in config.js. SSPI is also used for the passthrough authentication that VirtualCenter supports as of 2.5 U2.