Bumping to prove that under certain conditions, great things could happen for no apparent reason, other than hopefully more optimal configuration settings.

 

Upon adding to my domain tag:

 

<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>

 

And adding the following override to the -cpu switch to the end, just before the end of the domain tag:

 

  <qemu:commandline>
    <qemu:arg value='-cpu'/>
    <qemu:arg value='host,kvm=off,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time,hv_vendor_id=Microsoft'/>
  </qemu:commandline>

 

I was able to eke out some more performance, by turning on the hypervisor enlightenments, without tripping the Nvidia drivers. Doing it this way requires qemu version 2.5.0. It is possible to pass that vendor_id argument through the features->hyperv block, but only in libvirt 1.3.3 or newer, or possibly 2.1.0.

 

On the left, my first post here. On the right, my most recent benchmark of the same VM setup, only with the enlightenments enabled. Again, it's still possible to trick Nvidia's drivers, by faking the vendor_id of the hypervisor, which they specifically blacklist. I chose Microsoft for the lulz.

 

If you want to move your VM your best bet is to use "CA Appdata Backup/Restore" which from memory also backs up your VM as well.

 

But I can tell you without question that those original disk performances specially the read side of things are a little on the poor side.

 

The image gives you an idea.

 

Understanding that this is spread across 3 x SSD's (OCZ-TRION100 240GB, Samsung SSD 840 Series 120GB and a Intel 520 Series 120GB) in Raid 0