VCB in SCSI hot-add mode

[alex0]

Using this mode allows VCB to run as a VM.

However the documentation (vi3_35_25_u2_vm_backup.pdf) states:

"Creating a VCB Helper Virtual Machine

If you use Consolidated Backup in the Hot‐Add mode, you need to create a shadow

virtual machine for Consolidated Backup to use internally. The shadow virtual machine

has the same name as your virtual VCB proxy with the VCB-HELPER suffix added. For

example, if the name of your VCB proxy virtual machine is BackupProxy, the shadow

virtual machine, should be named BackupProxy(VCB-HELPER)."

Whiskey Tango Foxtrot.

What's a VCB Helper VM? How do I create it? What software goes on it? What resource specs for the helper?

The documentation is woeful.

Furthermore the doco goes on to say:

"When using Consolidated Backup in the Hot‐Add mode, the VCB user must have an

ability to perform additional tasks, such as adding and removing virtual disks, on the

VCB proxy and VCB helper virtual machines."

Ie it says "VCB helper virtual machines" PLURAL... so now we need MORE THAN ONE VCB helper VM?

How many do I need? What rules of thumb?

Also, what specs is the main VCB proxy (either VM or physical). ?? The doco makes absolutely no mention of minimum specs.

WOEFUL. How did this doc ever make it through QA? I guess the same way ESX 3.5U2 got released with a timebomb.

Any light would be appreciated.

[TechRoh]

Does "shadow copy" means dummy VM --- something existing in perception.

[rahul_bck]

Yes, that was i meant -> I'm refereing to the shadow copy VM as the dummy VM only.

[Ken_Cline]

Duncan,

Can you please get some details about exactly how this "hot-add" mode works? Since it requires a helper VM, I'm assuming the VCB Proxy is using the helper as a stub for hot-adding the .vmdk of the VM to be backed up. Since you have hot add capability, but not hot remove capability, the helper provides the stub that can be power cycled to release the reservation on the source .vmdk. This all makes some sense to me, but it raises an important question: If the VCB Proxy is able to use another VM (albeit an empty one) to proxy disk drives, what protections are available to prevent someone from using whatever technology enables this "trespassing" between VMs for a nefarious purpose?

Ken Cline

Technical Director, Virtualization

Wells Landers

TVAR Solutions, A Wells Landers Group Company

VMware Communities User Moderator

[dconvery]

I do know that you need to create a second role with the following permissions:

Datastore > Browse Datastore

Virtual Machine > Configuration > Add Existing Disk

Virtual Machine > Configuration > Remove Disk

Virtual Machine > Configuration > Change Resource

Dave

[marcelo_pineyro]

I had decided to install VCB in a physical server, until today I run into this "SCSI hot-add mode" (and the fact that the VCB proxy is now supported in a VM) and I am reconsidering my options. First of all, why is it called SCSI hot-add mode, when it seems like it can be used in a NAS environment? I quote from the latest version of the VM Backup Guide, from the "SCSCI hot-add mode section": "In this mode, you can use Consolidated Backup to protect any virtual disks on any type of storage available to your ESX Server host, including NAS or local storage." It also states: "Although this mode is not as efficient as the SAN mode, which does not cause any overhead on the ESX Server host, it is still more efficient than theLAN mode." If the shared storage in question is a NAS, how is this hot-add mode more efficient than the regular LAN mode? Under the "LAN mode (NBD mode)" section it states that the VCB proxy can be either in a physical server or a VM. So in the case in which the shared storage is a NAS, I see no difference between the hot-add mode and the LAN mode. What am I missing?

Like someone else that contributed to this discussion, I also will not implement this new hot-add feature in VCB unless more thorough documentation is made available. But aside from the documentation, I have one more doubt about how having VCB in a physical server vs. a VM compares. I am concerned with the speed with which backups take place. I have 2 ESX hosts with 4 VMs each. Some VMs have their data store in the NAS, some in the local ESX hosts. I intended to install VCB in a physical server, and connect to this server external hard drives via an eSATA connection. I intended to copy the vmdk files straight into this external drives, which I would rotate during the week and take off-site for the sake of off-site backups. If I have VCB in a VM, I suppose I could copy to external drives that are attached to a physical server in the network that has a share for the external drive. Can someone help me understand how the speed with which backups would take place compares in each scenario? If VCB is in a VM, the transfer of data from the ESX host to the VCB proxy happens within the ESX host virtual network, then the copying of the data to the external drive happens over the LAN. If I have a physical server for VCB, the transfer of the data from the ESX host to the VCB proxy happens over the LAN, but the writing of the data to the external drives happens over an eSATA connection (3GBits/second). My VMs' virtual disks are 40 to 50 GB average. The LAN transfer speed would be 1GBit/sec.

Finally, I would greatly appreciate some feedback on the backup schedule I intend to implement. Does anyone see any problems with only doing backups of the full VM images every day, and no backups of specific data files? I suppose the other alternative is to do data file level backups daily and maybe full image backups weekly or so, mainly for disaster recovery purposes. But from a management point of view, it seems to me it would be much simpler to just backup the entire VMs every night and not mess with file-level backups. Any thoughts on this?

Thank you so much in advance for any thoughts anyone cares to share. I am pretty new to VMware and I could use advice from others with more experience.

PS: I am running VirtualCenter 2.5 and VI 3.5

Marcelo

[marcelo_pineyro]

Quick addendum to my previous most: I realize that if I go with the option of having VCB in a VM, I'll either need to have VCB in both ESX hosts, or move the data stores of the VMs in the host that does not have the VCB VM to the NAS

Since I have the FOundation edition of VI, and therefore do not have vMotion, I have not bothered with moving all data stores to the NAS.

Marcelo

[dconvery]

Macelo -

First, Welcome to the forums!

As for the operation of the Hot-Add mode (As everyone says, documentaion is sparse at best and some theories may be changed after the next doc update) The way I understand it, The "helper VM" has the vdisk to be backed up "hot-added" to it. It is called "SCSI" Hot-add, because the vdisk is presented as a SCSI disk. Just like a VMDK on the NAS or FC SAN is presented as a SCSI disk to a regular VM. In order to use VCB to back up a VM, thedisk must be a vdisk. It doesn't matter if the VMDK or RDM is on a NAS, FC SAN, iSCSI SAN or local disk. The key is that it need to be in virtual compatability mode so a snapshot can be taken.

As for throughput, the process is VERY I/O intensive. I have done numerous throughput tests and with a 4GB FC SAN, the best I can get is about 1GB per minute of data throughput for each channel. I have never done timing tests on GbE NAS or iSCSI. It would be more efficient in hot-add mode as opposed to nbd mode because the I/O is at "backplane" speed instead of network speed. The trade-off is that it is one more thing the COS is doing. In your case, it sounds like your VMDKs are on NAS. The decision or physical vs. VM is purely money. Do you really need a separate server when a VM can do it just as well?

The trick with using a VM is where you will place your backups, and ultimately, how are you going to put it on tape....

Dave

[chengyee]

hi all,

I have been working on VCB in SCSI hot-add mode for the last 2 days. Hit some problems. Finally I managed to make it work. I managed to mount the target VM (file level) to VCB-proxy with browse-start.bat. The target vm files are visible in TSM client. Didn't really backup to tape.. most probably will be ok.

I have created the VCB-HELPER VM with 1 vcpu, 256MB ram, 1 NIC, 1 SCSI ctrl, no hdd, no OS . I think the spec of the helper vm does not matter. The helper VM need to be powered off when mounting the target vm to VCB proxy. My experience is if helper VM is powered on, browse-start.bat will fail.

Hope it helps!

[rscherer]

Well, I got hot-add working too....but only for VMs with a single VMDK -- my VMs that have multiple VMDK files crap out. The error is; Error: Failed to hot remove SCSI disk: Incompatible device backing specified for device '1'.

ideas?

~Rick

VMwareTips.com

[Michelle_Laveri]

This HELPER thing is very similiar to the beta of vDR which required the helper for VDR to work. Interesting when VDR was finally release - we discovered the helper was no longer required. I guess that's because the VDR was always a virtual machine, whereas the original intention of VCB was a dedicated physical proxy...

I'm finding that when I run the vcb commands - although the commands remove the snapshots - I'm being left behind with the mounting point for the VM...

I'm also finding hotadd much reliable than ndb mode...

Regards

Mike Laverick

RTFM Education

http://www.rtfm-ed.co.uk

Author of the SRM Book: http://www.lulu.com/content/4343147

[markdjones82]

How come the documentation does not explain all this information about it not even needing an OS? Does the helper machine even need a disk added?

[markdjones82]

Ok, so I created a helper machine and hotadd for the TSM integration modules. When I try to run the pre-command vmname-fullbackup, it mounts but it looks like it doesn't mount the VMDK files. IT does have a folder called vmdkstub, but it is empty.

I am using TSM 5.5 Any help?