New Feature Coming in Beta 15: VM Manager

[mr-hexen]

Is there a "system requirements" section for VM's anywhere? Reason being I'd like to play with a win7 VM when 6 goes final using my current hardware, after adding more RAM of course.

Your build is similar to mine except for CPU.

 

There has been limited (or maybe no) success with iGPU (e.g. Intel HD Graphics), and the CPU in your build thread will not do hardware passthru.

 

And our small form factor is not conducive to adding video cards anyway.

 

I have a passive HD5450 low profile that would likely fit in my case. I'm not looking to get my game on or anything, maybe just consolidate some stuff (i.e. transmission, sickrage, couchpotato, openelec).

[JonathanM]

Is there a "system requirements" section for VM's anywhere? Reason being I'd like to play with a win7 VM when 6 goes final using my current hardware, after adding more RAM of course.

Your build is similar to mine except for CPU.

 

There has been limited (or maybe no) success with iGPU (e.g. Intel HD Graphics), and the CPU in your build thread will not do hardware passthru.

 

And our small form factor is not conducive to adding video cards anyway.

 

I have a passive HD5450 low profile that would likely fit in my case. I'm not looking to get my game on or anything, maybe just consolidate some stuff (i.e. transmission, sickrage, couchpotato, openelec).

Why not just VNC into the VM instead of having another monitor, keyboard and mouse to worry about? That way you don't even have to worry about a video card.

[mr-hexen]

Is there a "system requirements" section for VM's anywhere? Reason being I'd like to play with a win7 VM when 6 goes final using my current hardware, after adding more RAM of course.

Your build is similar to mine except for CPU.

 

There has been limited (or maybe no) success with iGPU (e.g. Intel HD Graphics), and the CPU in your build thread will not do hardware passthru.

 

And our small form factor is not conducive to adding video cards anyway.

 

I have a passive HD5450 low profile that would likely fit in my case. I'm not looking to get my game on or anything, maybe just consolidate some stuff (i.e. transmission, sickrage, couchpotato, openelec).

Why not just VNC into the VM instead of having another monitor, keyboard and mouse to worry about? That way you don't even have to worry about a video card.

 

Because of Openelec

[sane]

Have even more powerful hardware that includes hardware-assisted virtualization (Intel VT-x / AMD-V) and IOMMU (Intel VT-d AMD-Vi) support?  Perfect!

 

I'm out of the loop on UNRAID developments (I got bored waiting for RC as deadlines whistled by) but does the above mean you require IOMMU? Like many, I have the Gen7 Microserver (without IOMMU) and would want to be able to run VNC'ed sessions if possible. Hopefully the above just means we are short the passthrough?

[archedraft]

VT-x is needed to run a virtual machine (VNC sessions) & VT-d is needed to pass through PCIe devices but VT-d is not required to run a VM if you do not want to pass through devices.

[mr-hexen]

which is the cheapest processor that supports VT-d?

[archedraft]

which is the cheapest processor that supports VT-d?

Best bet would be to start here:

http://ark.intel.com/search/advanced?s=t&VTX=true&VTD=true

[archedraft]

According to Intel's Website price data exported and sorted with excel (some of these don't make since... I mean $13, really? and an i7 for $59??) I cut off the values at $200.

 

I removed these after searching the interwebs for 6 CPU's and all of them are the wrong price. Don't want to confuse anyone.

 

 

 

[garycase]

Realistically, if you're buying a new CPU you want to limit yourself to Haswell processors ... and probably just to Socket 1150 units.    Limiting Intel's ARK site to Socket 1150 CPU's with vt-x and vt-d support, the least expensive units are several Core i5 units in the $180 range.

 

This shows you the list: 

http://ark.intel.com/search/advanced?s=t&SocketsSupported=FCLGA1150&VTX=true&VTD=true

 

There's not much difference in the pricing of the previous generation Ivy Bridge units; but you may be able to find them discounted and/or used, so if the goal is to shave all you can off the price, you may want to consider these as well:  http://ark.intel.com/search/advanced?s=t&SocketsSupported=FCLGA1155&VTX=true&VTD=true

 

[meep]

So I've been using unRAID VMs since the early days of Beta6(when it was only Xen!)

 

Very familiar with you and your blog!  You've been a great supporter and we appreciate it!

 

I invested the time in getting to grips with Xen config, Xen passthrough, VM drivers & optimisation etc.

 

It was made clear many moons ago by Tom (when KVM was introduced) that it was unlikely that both would be supported long term. It looks like KVM is the winner and getting all the love.

 

The primary reason it was unlikely to support both hypervisors was because we didn't want to maintain two separate VM management tools.  Since implemented in beta 3, our Xen Manager has leveraged the user-space tools provided directly by the Xen project to create and manage Xen-based guests.  The new VM Manager, however, is built entirely upon Libvirt, a management framework that can support BOTH Xen and KVM.  Now this has been the case for some time, but early on, when we experimented with creating VMs using libvirt, we found that several features made possible with the native Xen tools were NOT available when creating those VMs using libvirt.  One of the big ones was PCI device assignments.  Another big challenge was that Libvirt had a tool which was supposed to convert a Xen CFG file into a Libvirt domain XML file.  This tool didn't work very well in our testing.  However, as of Libvirt 1.2.8, we found substantial improvements to manageability of Xen-based guests using KVM.  There are still some "gotchas," but there is hope that when combined with Xen 4.5, manageability may see feature parity with the native Xen tools.  If this is the case, it would be of little effort for us to add support for Xen to the new VM Manager.  To be clear though, we have yet to test Xen 4.5 with the newer versions of Libvirt, so while we are hopeful, I cannot say for certain that this will happen.  What I can say for certain is that 6.0's release will not be held back in order for us to add Xen support to the VM Manager.

 

I'd love to migrate but really don't want to go through a learning curve all over again and have so much Xen specific stuff in my VMs that it's going to be a bunch of hassle (GPU start/stop scripts, Xen drivers, windows licences now tied to Xen virtual hardware etc.)

 

It would be really nice if there was a quick easy and foolproof method of migrating Xen -> KVM. Anyone got any pointers?

 

Thanks

 

From a licensing standpoint, Windows-based guests shouldn't require reactivation as a result of moving from Xen to KVM.  Garycase's post is right in that both KVM and Xen utilize QEMU's i440fx emulated chipset, which means that when converting from Xen to KVM, you should not have to reactivate your copy of Windows.  In addition, KVM doesn't require start/stop scripts for GPU assignment and in my testing, VirtIO from KVM blows away what Xen has to offer in terms of paravirtualization drivers.  The most time-consuming aspect in migrating will be the process of converting from a Xen domain CFG format to libvirt XML format and replacing the Xen drivers with VirtIO.  When I find time, I will write up a guide on how to do this (maybe even craft a video walk through).

 

JonP

 

Many thanks for that really detailed reply.

 

I think I'll stick with Xen for now as my VMs have been very stable of late and see how this all pans out.

 

Appreciate all the work

 

Peter

[sparklyballs]

I'm having some issues with this new VM-Manager.

 

on the basic screen i can't select my own network mac and when i do on the advanced screen it's not getting the DHCP information from my router and when i get to the host section in ubuntu it's not auto filled as it should be and was in the last iteration of VM-Manager.

 

ubuntu 14.04 refuses to load with OVMF set ,trying to install and instead of the normal ubuntu menu for installation it goes to either the grub menu or a shell prompt depending on which it feels like.

 

my bridge is shown as br0 in network settings and in the create VM screen the automatically filled value is virbr0 , is that normal ? because it's confusing otherwise.

 

and also intermittently the picker for the primary vdisk location tells me it's unable to load the filetree in /mnt/user

[jonp]

 

 

I'm having some issues with this new VM-Manager.

 

on the basic screen i can't select my own network mac and when i do on the advanced screen it's not getting the DHCP information from my router and when i get to the host section in ubuntu it's not auto filled as it should be and was in the last iteration of VM-Manager.

 

ubuntu 14.04 refuses to load with OVMF set ,trying to install and instead of the normal ubuntu menu for installation it goes to either the grub menu or a shell prompt depending on which it feels like.

 

my bridge is shown as br0 in network settings and in the create VM screen the automatically filled value is virbr0 , is that normal ? because it's confusing otherwise.

 

and also intermittently the picker for the primary vdisk location tells me it's unable to load the filetree in /mnt/user

 

Virbr0 is a auto created private bridge that uses NAT and DHCP from the unRAID server to give a private IP to your vm. If you wish the VM to get an IP from your router, you can change virbr0 to the name of your network bridge you created on the unraid network settings page. If you want ALL VMs you create to use a specific bridge, you can change this setting from the vm settings page.

 

The disk picker issue is new to us. Will need to investigate. Thank you for reporting!

 

OVMF was a last minute inclusion for beta 15.  It does work, but I need to write up a brief guide on this today on working with the EFI shell to install and boot VMs as it is not in the wiki documentation yet.

[GHunter]

 

Virbr0 is a auto created private bridge that uses NAT and DHCP from the unRAID server to give a private IP to your vm. If you wish the VM to get an IP from your router, you can change virbr0 to the name of your network bridge you created on the unraid network settings page. If you want ALL VMs you create to use a specific bridge, you can change this setting from the vm settings page.

 

The disk picker issue is new to us. Will need to investigate. Thank you for reporting!

 

OVMF was a last minute inclusion for beta 15.  It does work, but I need to write up a brief guide on this today on working with the EFI shell to install and boot VMs as it is not in the wiki documentation yet.

 

Does this also apply to VM's with static IP addresses? I seem to have problems with this where every time I restart the VM, I'm back on a public network and have to change it to private before using RDP with a static IP to the VM. This is more of a problem with beta 15 than previous betas. I've been using br0 as the bridge as defined in the unRAID network settings for my VM's.

 

If there is a more reliable way to do this, I'm all ears.

 

Gary

[jonp]

 

Virbr0 is a auto created private bridge that uses NAT and DHCP from the unRAID server to give a private IP to your vm. If you wish the VM to get an IP from your router, you can change virbr0 to the name of your network bridge you created on the unraid network settings page. If you want ALL VMs you create to use a specific bridge, you can change this setting from the vm settings page.

 

The disk picker issue is new to us. Will need to investigate. Thank you for reporting!

 

OVMF was a last minute inclusion for beta 15.  It does work, but I need to write up a brief guide on this today on working with the EFI shell to install and boot VMs as it is not in the wiki documentation yet.

 

Does this also apply to VM's with static IP addresses? I seem to have problems with this where every time I restart the VM, I'm back on a public network and have to change it to private before using RDP with a static IP to the VM. This is more of a problem with beta 15 than previous betas. I've been using br0 as the bridge as defined in the unRAID network settings for my VM's.

 

If there is a more reliable way to do this, I'm all ears.

 

Gary

Gary can you send me PM with an example setup for what you are trying to do so I can try to replicate?

[GHunter]

Yeah, I'm heading to work now so I'll send you details when I get home. Thanks.

 

Gary

[expressexcess]

Any trick to getting GPU pass through to work with a NVIDIA 970 on Windows 7?

 

I used VNC to install drivers for the 970, and verified that the card is seen in the VM. When I disable VNC and start the VM I don't get any video. The card seems to be working—I'm using it to access BIOS and view the console. As soon as I start the VM I lose the console and just see a black screen.

 

Any advice would be appreciated.

 

XML:

<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
  <name>Windows 7</name>
  <uuid>d46c5469-e9f2-edbe-01b2-63da5d44202c</uuid>
  <description>Gaming PC</description>
  <memory unit='KiB'>8388608</memory>
  <currentMemory unit='KiB'>8388608</currentMemory>
  <memoryBacking>
    <nosharepages/>
    <locked/>
  </memoryBacking>
  <vcpu placement='static'>6</vcpu>
  <cputune>
    <vcpupin vcpu='0' cpuset='0'/>
    <vcpupin vcpu='1' cpuset='1'/>
    <vcpupin vcpu='2' cpuset='2'/>
    <vcpupin vcpu='3' cpuset='3'/>
    <vcpupin vcpu='4' cpuset='4'/>
    <vcpupin vcpu='5' cpuset='5'/>
  </cputune>
  <os>
    <type arch='x86_64' machine='pc-i440fx-2.2'>hvm</type>
  </os>
  <features>
    <acpi/>
    <apic/>
  </features>
  <cpu mode='host-passthrough'>
    <topology sockets='1' cores='6' threads='1'/>
  </cpu>
  <clock offset='localtime'>
    <timer name='rtc' tickpolicy='catchup'/>
    <timer name='pit' tickpolicy='delay'/>
    <timer name='hpet' present='no'/>
  </clock>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <devices>
    <emulator>/usr/bin/qemu-system-x86_64</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw' cache='none' io='native'/>
      <source file='/mnt/cache/VM/Windows 7/vdisk1.img'/>
      <target dev='hdc' bus='virtio'/>
      <boot order='1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </disk>
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/mnt/user/VM/GSP1RMCHPXFREO_EN_DVD.iso'/>
      <target dev='hda' bus='ide'/>
      <readonly/>
      <boot order='2'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/mnt/user/VM/virtio-win-0.1-100.iso'/>
      <target dev='hdb' bus='ide'/>
      <readonly/>
      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
    </disk>
    <controller type='usb' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/>
    </controller>
    <controller type='pci' index='0' model='pci-root'/>
    <controller type='ide' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
    </controller>
    <interface type='bridge'>
      <mac address='52:54:00:a2:d0:6d'/>
      <source bridge='virbr0'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </interface>
    <serial type='pty'>
      <target port='0'/>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>
    <hostdev mode='subsystem' type='pci' managed='yes'>
      <driver name='vfio'/>
      <source>
        <address domain='0x0000' bus='0x02' slot='0x00' function='0x1'/>
      </source>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </hostdev>
    <memballoon model='virtio'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </memballoon>
  </devices>
  <qemu:commandline>
    <qemu:arg value='-device'/>
    <qemu:arg value='ioh3420,bus=pci.0,addr=1c.0,multifunction=on,port=2,chassis=1,id=root.1'/>
    <qemu:arg value='-device'/>
    <qemu:arg value='vfio-pci,host=02:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on'/>
  </qemu:commandline>
</domain>

[jonp]

Any trick to getting GPU pass through to work with a NVIDIA 970 on Windows 7?

 

I used VNC to install drivers for the 970, and verified that the card is seen in the VM. When I disable VNC and start the VM I don't get any video. The card seems to be working—I'm using it to access BIOS and view the console. As soon as I start the VM I lose the console and just see a black screen.

 

Any advice would be appreciated.

 

XML:

<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
  <name>Windows 7</name>
  <uuid>d46c5469-e9f2-edbe-01b2-63da5d44202c</uuid>
  <description>Gaming PC</description>
  <memory unit='KiB'>8388608</memory>
  <currentMemory unit='KiB'>8388608</currentMemory>
  <memoryBacking>
    <nosharepages/>
    <locked/>
  </memoryBacking>
  <vcpu placement='static'>6</vcpu>
  <cputune>
    <vcpupin vcpu='0' cpuset='0'/>
    <vcpupin vcpu='1' cpuset='1'/>
    <vcpupin vcpu='2' cpuset='2'/>
    <vcpupin vcpu='3' cpuset='3'/>
    <vcpupin vcpu='4' cpuset='4'/>
    <vcpupin vcpu='5' cpuset='5'/>
  </cputune>
  <os>
    <type arch='x86_64' machine='pc-i440fx-2.2'>hvm</type>
  </os>
  <features>
    <acpi/>
    <apic/>
  </features>
  <cpu mode='host-passthrough'>
    <topology sockets='1' cores='6' threads='1'/>
  </cpu>
  <clock offset='localtime'>
    <timer name='rtc' tickpolicy='catchup'/>
    <timer name='pit' tickpolicy='delay'/>
    <timer name='hpet' present='no'/>
  </clock>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <devices>
    <emulator>/usr/bin/qemu-system-x86_64</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw' cache='none' io='native'/>
      <source file='/mnt/cache/VM/Windows 7/vdisk1.img'/>
      <target dev='hdc' bus='virtio'/>
      <boot order='1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </disk>
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/mnt/user/VM/GSP1RMCHPXFREO_EN_DVD.iso'/>
      <target dev='hda' bus='ide'/>
      <readonly/>
      <boot order='2'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/mnt/user/VM/virtio-win-0.1-100.iso'/>
      <target dev='hdb' bus='ide'/>
      <readonly/>
      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
    </disk>
    <controller type='usb' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/>
    </controller>
    <controller type='pci' index='0' model='pci-root'/>
    <controller type='ide' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
    </controller>
    <interface type='bridge'>
      <mac address='52:54:00:a2:d0:6d'/>
      <source bridge='virbr0'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </interface>
    <serial type='pty'>
      <target port='0'/>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>
    <hostdev mode='subsystem' type='pci' managed='yes'>
      <driver name='vfio'/>
      <source>
        <address domain='0x0000' bus='0x02' slot='0x00' function='0x1'/>
      </source>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </hostdev>
    <memballoon model='virtio'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </memballoon>
  </devices>
  <qemu:commandline>
    <qemu:arg value='-device'/>
    <qemu:arg value='ioh3420,bus=pci.0,addr=1c.0,multifunction=on,port=2,chassis=1,id=root.1'/>
    <qemu:arg value='-device'/>
    <qemu:arg value='vfio-pci,host=02:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on'/>
  </qemu:commandline>
</domain>

 

So when you start the VM with this configuration, you get nothing on the monitor at all?

 

What brand video card specifically (evga, asus, etc)?  Do you have the make / model handy?

[expressexcess]

So when you start the VM with this configuration, you get nothing on the monitor at all?

 

What brand video card specifically (evga, asus, etc)?  Do you have the make / model handy?

 

Correct. It's currently hooked up to a TV via HDMI and is black.

 

The card is made by EVGA, specifically: VGA EVGA GTX 970 04G-P4-3978-KR RTL

[jonp]

So when you start the VM with this configuration, you get nothing on the monitor at all?

 

What brand video card specifically (evga, asus, etc)?  Do you have the make / model handy?

 

Correct. It's currently hooked up to a TV via HDMI and is black.

 

The card is made by EVGA, specifically: VGA EVGA GTX 970 04G-P4-3978-KR RTL

 

Hmm, try advanced mode in the editor and instead of i440fx, try Q35 and let me know if that changes anything.

[expressexcess]

Hmm, try advanced mode in the editor and instead of i440fx, try Q35 and let me know if that changes anything.

 

Hi Jon,

 

No dice. It does the same thing. Though, differently from the i440fx, if I have VNC and the 970 as a second GPU, then when I try to VNC into the VM it says something like Guest has not initialized the display (yet).

 

I tried a different monitor, same result. I also tried the DVI port on the graphics card instead of HDMI and the same thing happened. I saw elsewhere on the forum that Jude was able to successfully get a 970 working with Windows 8.1 (http://lime-technology.com/forum/index.php?topic=37495.0)—maybe it's a Windows 7 thing?

 

[jonp]

Well it should at least throw up a SeaBIOS screen before Windows even gets loaded. Need to think on this.

[stottle]

Any trick to getting GPU pass through to work with a NVIDIA 970 on Windows 7?

 

I used VNC to install drivers for the 970, and verified that the card is seen in the VM. When I disable VNC and start the VM I don't get any video. The card seems to be working—I'm using it to access BIOS and view the console. As soon as I start the VM I lose the console and just see a black screen.

 

Any advice would be appreciated.

Is the VM Manager adding anything hyper-v related?  Like the clock element?  Maybe check the output xml, rather than the input xml.

[landS]

How does one increase the resolution / zoom in the NoVNC viewer?  It is coming up in my browser using only about a quarter of my 720p 12.5" monitor.... kinda hard to work in.

 

Ubuntu 14 LTS server

SeaBIOS

sudo apt-get install  xrdp

sudo apt-get install xubuntu-desktop

echo "xfce4-session" > ~/.xsession

sudo /etc/init.d/xrdp restart

sudo shutdown -h 0

 

***EDIT***

Maximizing the browser and setting the VM resolution to the native resolution of the laptop allows a usable desktop.

[01111000]

It's great and all that unRaid is getting these new features, but only a portion of its users can take advantage of this whereas a feature like Dual Parity can be used by everyone and is arguably more valuable.  Is that even being worked on?

 

[jonp]

It's great and all that unRaid is getting these new features, but only a portion of its users can take advantage of this whereas a feature like Dual Parity can be used by everyone and is arguably more valuable.  Is that even being worked on?

Let's not start down a path of comparing features and order of importance. Its not a good idea. There is an open thread with discussion on dual parity support, but its never been on the roadmap and there are plenty of other features that we have added with 6.0 that can be used with lesser hardware (e.g. docker).

 

I'd also argue the value of dual parity for the majority of our users. Dual parity is only beneficial in arrays with larger quantities of disk devices for which only a small percentage of our users need.  It is certainly a good feature idea for us to add at some point, but as drive size capacities seem to keep growing faster and faster, the need for extremely large arrays will dwindle in the home market.  Anyhow, this topic of dual parity has been discussed ad nauseum and again, don't want to derail yet another thread on this topic.