Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm fiddling with Windows Server Backup in Hyper-V virtual machines, testing backup and recovery time.

While ( full ) backup time is pretty good, Bare Metal Recovery time using recovery DVD is 5 times longer.

Here is backup ...

backup to iSCSI target mounted in hyper-v VM via iSCSI initiator

... and there is recovery ( notice y-axis scale difference ):

restore from iSCSI target mounted in parent partition and attached as SCSI virtual drive

Reading about Hyper-V, on, I learned that Integration Services are behind fast I/O: actually there are virtual drivers and hypervisor-aware kernel working together to do paravirtualized I/O, so to speak.

Is there any chance to get hypervisor-aware kernel into recovery DVD using dism.exe from Windows® Automated Installation Kit (AIK) for Windows?

The test setup is composed by:

  • Entry level 4C Xeon Server with 4 GiB RAM and one SATA controller/disk;
  • Windows 2008 R2 with Hyper-V role installed;
  • Two Hyper-V machines, source and target;
  • FreeNAS 8.3.0 iSCSI target provider for backup and restore volume;
share|improve this question
Neat question. I hope somebody knows the answer. – Ryan Ries Jan 9 '13 at 15:41

Installing the Integration Components can be done off-line. The packages used by dism.exe are on the virtual CD-ROM image called vmguest.iso on the Hyper-V host. As for the exact command you'd need, I don't know that. Sorry.

share|improve this answer
You headed me in the right direction. I managed to get cab files inside vmguest.iso on Hyper-V host; after a successful driver injection into boot.wim I made a fresh install ISO DVD using oscdimg.exe. Services like storflt, storvsc, vmbus and vmbushid are running, but still I can't get past 55 Mbit/s treshold... What am I doing wrong? – Marco De Lellis Jan 10 '13 at 15:11
Did you change from the Legacy NIC to the fast NIC? If you had networking before you had those drivers installed, then you must have been using the emulated (legacy) NIC. Installing those drivers doesn't make the legacy NIC go any faster. Using a completely different networking stack does. (I know that this isn't intuitive, because exactly the opposite is true of the IDE storage.) – Jake Oshins Jan 10 '13 at 17:38
I did it but it wasn't required, given the recovery setup: the Hyper-V server is connected with an iSCSI target, which was the drive used for backups; that drive is offline on Hyper-V server ( diskpart.exe ) and is connected directly to the virtual machine SCSI controller, as a SCSI virtual disk. This recovery setup is designed to bypass the network stack entirely, with a fast media ( virtual SCSI is faster than virtual IDE ) to read from. Why is it so slow to get data even from a "local" virtual SCSI drive? Does poor write speed to IDE show itself as slow read from SCSI? – Marco De Lellis Jan 10 '13 at 19:57
With those drivers installed IDE is no slower than SCSI. I'd look for other bottlenecks. Open Performance Monitor in the Hyper-V management OS and see what it tells you is happening. – Jake Oshins Jan 10 '13 at 22:58
I opened perfmon during restore phase in Hyper-V server. Virtual disks are on drive D: ( disc 0 ), so I measured avg. write queue length for logical drive D:, and avg. read queue length for physical disc 1 ( iSCSI target ). In a scale of 100,0, I got a steady line around 90 for the write queue length, and values in the 20-30 range for the read queue length. I'd look for other performance objects, but being a real noob in the field of Windows, it will take some time to choose the right ones... – Marco De Lellis Jan 11 '13 at 8:57

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.