Eyup chaps. I'd ask this on the VMware forums, but those will simply not let me log in, so.. Here I am in the vain hope someone knows! The situation is as follows: ESXi 5 server running on an Ml350 G6, running off an SD card, bunch of TB drives as the primary data store. The virtual machines run fine and dandy - No issues there. However. It's running a few Sbs2008 boxes, which have the Windows Backup option. I've passed through USB ports, and it sees those flawlessly, and I've no issues with that. However - USB is dastardly slow. Not so much of an issue doing an incremental backup, however, restoring takes an unforgivable amount of time - It took 36 hours to do 200gb of data. I had a thought, though - Why not just plug an eSATA card in, pass that through, and plug an eSATA drive in? Grabbed an, admittedly cheap, eSATA card - But the controller is on the supported hardware list - and great. It passes through to the virtual machine I've been testing with absolutely fine, and I can see it in the Device mangler. However. The virtual machine does not see the harddrive when it's connected, but the drive is no longer visible by the ESX server. All I can see is some long winded, utterly useless (To me) command line system for hooking drives in as vmdk - I absolutely cannot touch the drive, it must be passed through as-is so the SBS backup system can see it. Any thoughts as to why the controller isn't connecting the drive in the VM?
Well, not all hardware works reliably through VT-d. But you still have an alternative option : http://blog.davidwarburton.net/2010/10/25/rdm-mapping-of-local-sata-storage-for-esxi/ The issue is that you won't be able to just remove the drive, as it will act like a fixed SATA/SCSI drive, and not as a removable eSATA drive.
Yeah, that's what I've seen so far when searching google, but it's not a suitable way to do it. The concept is - although not the way I'd do it - Physical server A backs up to USB drive A, and is (every other month) converted to a VM on the ESX server running on another site. Physical server A is stolen/burned down/irrecoverable hardware issue, USB drive A is plumbed into the ESX copy of the server, data restored, ESX server goes out and is used as a stand-in until Physical server B is built and ready to go back (Roughly a week). So, really, the USB drive is too slow via USB, is not going to be in/near the ESX server very regularly (If at all), and must be untouched so SBS Backup can restore data off it. All these methods involving the raw device mapping seem to involve, at least partially, touching the disk - Or am I misreading that blog post?
You don't do anything to the disk at all, that is the point. You create a vmdk files, which will have the size of the hard drive, but in reality it is just few kB of mapping data... Imagine it as a symbolic link to your real hard drive device. As i mentoined, the only issue is that the device you create this way is not removable. If the hard drive goes missing, you won't be able to boot the VM (missing device) and who knows what will it do if you remove the drive when VM runs. PS: Just to be sure, did you tried "Scan for hardware changes" in the VM when you connected the drive to the eSATA controller passed through VT-d ? One more option would be backing up to some iSCSI device instead of a local eSATA drive.
Why not scrap that entire idea and use Shadow Protect with headstart restore to image the physical boxes continuously to a NAS & to your offsite location via a VPN? or use veeam if you're backing up just VM's
