reluctantflux

Unless you set it up weird, yes, it'll be accessible. If you are running it on your cache drive, just go to your cache share.

Caused my system to blue screen with "Your PC ran into a problem " Then it auto reboots. Let it do that three times, to no avail. Was able to revert back without having to restore from a backup. I did change my target device from "vdc" to "hda". Would that affect anything? Should I have left it at vdc?

Windows 8.1 guest.

So when I setup a VM a long time ago, I set it up on bus="Sata" instead of bus="Virtio". I understand that Virtio will get better performance. The disk type is "raw". Is there any way to change this after the fact? The drive is an OS drive. I really can't rebuild this OS from scratch, as it's the primary HTPC currently. I do have backups I can test any suggestions with. Thanks.

When you use GPU passthrough, and start a VM, it grabs that video card for itself and can't be used for the host system again until reboot. You can use it for different VM's as long as you have only one VM that uses the GPU at a time. You do not need to use 2 GPUs. You can run your unRAID system headless (no monitor). Then just manage it through SSH and the webgui. I have 2 GPU's in mine, and my ATI HD7770 is for my HTPC VM, and then my ATI R9 270X is for my gaming VM. I don't have any output for the unRAID host system. As for the order of the cards, unRAID is going to want to grab that first card, cause that's how the BIOS is going to load it. Unless you have a BIOS that allows you to choose the second card as your primary graphics card, the card in the first slot will always be the unRAID's card. I recommend just going headless, though. SSH gives you all the capabilities that you would want from a monitor'd connection anyway.

I needed the vm HD image to be in raw format, and I attached it as a sata bus instead of virtio. This is because Openelec doesn't have virtio drivers installed. Then I had to do a manual install from a live ubuntu iso, since there's no iso file for Openelec. Afterwards, I heard someone made a vmdk from the OpenElec img file and attached it as another hard drive in order to perform an install. Would've been much easier and probably would have worked, but that wasn't the route I went. That got it to boot, but then there was no NIC detected, as that needed virtio drivers as well. I then did physical passthrough of a physical NIC, and I was up and operational except for the sluggishness and ticks and everything. Here's my XML. <domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'> <name>OpenElec</name> <uuid>8c998f9d-0d03-2cbc-5a33-c77fd685c1af</uuid> <memory unit='KiB'>2097152</memory> <currentMemory unit='KiB'>2097152</currentMemory> <vcpu placement='static'>1</vcpu> <os> <type arch='x86_64' machine='pc-q35-2.1'>hvm</type> <boot dev='hd'/> <boot dev='cdrom'/> </os> <features> <acpi/> <apic/> </features> <clock offset='localtime'> <timer name='rtc' tickpolicy='catchup'/> <timer name='pit' tickpolicy='delay'/> <timer name='hpet' present='yes'/> </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'/> <source file='/mnt/disk/snapvms/vm/OpenElec/OpenElec5.qcow2'/> <target dev='hda' bus='sata'/> <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/iso/ubuntu-14.04.1-desktop-amd64 (1).iso'/> <target dev='hdc' bus='sata'/> <readonly/> <address type='drive' controller='0' bus='0' target='0' unit='2'/> </disk> <controller type='usb' index='0' model='ich9-ehci1'> <address type='pci' domain='0x0000' bus='0x02' slot='0x02' function='0x7'/> </controller> <controller type='usb' index='0' model='ich9-uhci1'> <master startport='0'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x02' function='0x0' multifunction='on'/> </controller> <controller type='sata' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/> </controller> <controller type='pci' index='0' model='pcie-root'/> <controller type='pci' index='1' model='dmi-to-pci-bridge'> <address type='pci' domain='0x0000' bus='0x00' slot='0x1e' function='0x0'/> </controller> <controller type='pci' index='2' model='pci-bridge'> <address type='pci' domain='0x0000' bus='0x01' slot='0x01' function='0x0'/> </controller> <interface type='bridge'> <mac address='52:54:00:f1:2b:97'/> <source bridge='br0'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x01' function='0x0'/> </interface> <serial type='pty'> <target port='0'/> </serial> <console type='pty'> <target type='serial' port='0'/> </console> <input type='tablet' bus='usb'/> <hostdev mode='subsystem' type='usb' managed='no'> <source> <vendor id='0x046d'/> <product id='0xc52b'/> </source> </hostdev> <hostdev mode='subsystem' type='usb' managed='no'> <source> <vendor id='0x045e'/> <product id='0x006d'/> </source> </hostdev> <hostdev mode='subsystem' type='usb' managed='no'> <source> <vendor id='0x0cf3'/> <product id='0x3002'/> </source> </hostdev> <memballoon model='virtio'> <address type='pci' domain='0x0000' bus='0x02' slot='0x04' function='0x0'/> </memballoon> </devices> <qemu:commandline> <qemu:arg value='-device'/> <qemu:arg value='ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,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:arg value='-device'/> <qemu:arg value='vfio-pci,host=02:00.1,bus=pcie.0'/> <qemu:arg value='-device'/> <qemu:arg value='vfio-pci,host=04:00.0'/> </qemu:commandline> </domain>

Was very sluggish and had some weird audio ticks/pops. I think I'm going to wait for the unVM.

I've got OpenElec booted, but it's not recognizing the virtual NIC. Will I have to either passthrough a dedicated NIC or recompile OpenElec to include the driver? I've never compiled before, and there don't appear to be any thorough instructions so I'm hesitant to go that route. Tips would be greatly appreciated!

Try this: <hostdev mode='subsystem' type='usb' managed='no'> <source> <vendor id='0x413c'/> <product id='0x2501'/> </source> </hostdev> Where are you placing it? It should be within the <devices> </devices> headers.

What happens when you manually add the following to your xml when the VM is off? <hostdev mode='subsystem' type='usb'> <source> <vendor id='0x413c'/> <product id='0x2501'/> </source> </hostdev>

Make sure the device isn't being used by another running VM. Also, make sure that it doesn't have old bus/host information in there. It shouldn't have any bus/host info, as it will create that at startup.

Not sure this is the best way, but it is a driver issue. I changed the qcow2 image to a raw file, and was then able to get OpenElec to boot to its start up cli stuff. Won't go into OpenElec due to no vid card. I'll have to continue this tonight when I have access to the monitor it'll be connected to.

I'm trying to build an OpenElec 5 VM, but I can't get it to boot. It appears to be having trouble mounting the System drive. I've followed the manual install from a Live Ubuntu CD from here: http://wiki.openelec.tv/index.php/Live_Boot_%26_Manual_Installation DEFAULT linux PROMPT 0 LABEL linux KERNEL /KERNEL APPEND boot=LABEL=System disk=LABEL=Storage quiet ssh Basically, the APPEND boot=LABEL=System command is not working. I also tried changing it to /dev/### but the few options I tried for that didn't work. I think it's having issues with drivers for the virtio qcow2 drive. Any tips?

Might be that it's not signed or verified. Workaround for 8.1 that could be relevant to 10. http://www.howtogeek.com/167723/how-to-disable-driver-signature-verification-on-64-bit-windows-8.1-so-that-you-can-install-unsigned-drivers/ What error are you getting?

If you have any success with this please let us know! I'm pretty certain that Jon and team had to create a custom build to incorporate the needed drivers and such. John Jonp, Is this true? If so that's beyond my skills or available time to learn.

Pretty sure no one had gotten this to work. Not even kvm devs. Hopefully someone will chime in and say I'm wrong And it's just a new kernel build.

Is there any way for me to setup openvpn client connections on selected docker containers, so that they use a VPN connection going out, but everything else is routed regularly? This would be great for putting on Sab and Transmission. Thanks.

A few things from my experience. Anyone feel free to correct me if I'm wrong. First off, the very first line of your xml needs to be: <domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'> If you don't have the xmlns part, the qemu:commandline section will get stripped out automatically. Secondly, in the qemu:commandline section, I believe you need the following: <qemu:arg value='-device'/> <qemu:arg value='ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1'/> <qemu:arg value='-device'/> Not exactly sure what it does, but I've seen it in every xml that uses passthrough. I think it's a necessary piece for other items to get passed through. Third, you need to remove the VNC section, as you can't have VNC and Passthrough working at the same time. Your VM will fail to boot. <graphics type='vnc' port='-1' autoport='yes' websocket='-1' listen='0.0.0.0'> <listen type='address' address='0.0.0.0'/> </graphics> <video> <model type='vmvga' vram='9216' heads='1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </video> While not required, as I understand it, it is recommended to use pc-q35-2.1 emulation. So change this in your os section from: <type arch='x86_64' machine='pc-i440fx-2.1'>hvm</type> to: <type arch='x86_64' machine='pc-q35-2.1'>hvm</type> I think that may break current installations, so I'd only make the change if you're doing a fresh install. I wouldn't put this part in your go script until after testing it. You can simply run the vfio-bind command from the cli. /usr/local/sbin/vfio-bind 0000:00:02.0 You can add it to the go script once you have a working VM. For your syslinux.cfg, I merely added: append pcie_acs_override=downstream initrd=/bzroot I don't think you need this: append intel_iommu=on vfio_iommu_type1.allow_unsafe_interrupts=1 pcie_acs_override=downstream initrd=/bzroot Although I think that's hardware dependent. I'm using an intel i7 4790. If you still continue to have problems with it booting at that time, you may need to mess with the <controller> sections. I'd probably remove all of your controllers and try adding some that other people have said are working. This is what I have. <controller type='usb' index='0' model='ich9-uhci1'> <alias name='usb0'/> <master startport='0'/> </controller> <controller type='sata' index='0'> <alias name='sata0'/> </controller> <controller type='pci' index='0' model='pcie-root'> <alias name='pcie.0'/> </controller> <controller type='pci' index='1' model='dmi-to-pci-bridge'> <alias name='pci.1'/> </controller> <controller type='pci' index='2' model='pci-bridge'> <alias name='pci.2'/> </controller>

Finally got an openelec vm running on virtual box, so I could just copy the qcow over to unraid, that is proving fruitless. I guess I'll wait for unVM's. I'd be very happy to be an early tester!

So far, I'm having some trouble just getting the darn thing to boot to the installation media.

Looking to whip up an openelec vm. Any gotchas or is it pretty straightforward? Or should I wait for the unvm release?

So, I was having a similar issue and this is what I found in my scenario. Symptoms: Gui would hang for 5-10 minutes, or indefinitely Shares were accessible VM's stayed up (on non-array snaps) All dockers were still accessible through their webpages. Basically, it was just the unraid GUI that was hanging, which proved to be very frustrating. Well, as it turned out, it was because my syslog was huge! 18MB (almost 200,000 lines) . How'd this happen? Well, I wanted external access so I setup port forwards for both the web and ssh (with very secure passwords). Well, that doesn't stop others from pounding on your door like maniacs, and getting every attempt logged in your syslog. Even after I disabled the port forwarding, I had to go and clear my syslog in order for the webgui to return to its prior snappy performance. So yeah, 2 lessons. First, If your webgui is unresponsive, but everything else is fine, check your syslog. It could be huge. And second, if you really want external access, don't be stupid like me and just take the time to setup a VPN connection.

Can someone please help me figure out the correct parameters for me to setup cache_dirs correctly? The last time I tried, it ended up killing my router somehow, and my whole network went down. I don't know how, but as soon as I killed the cache_dir process, everything resumed to normal. My directory structure is: /mnt/user/Movies/{Moviename} [year]\filename.mkv /mnt/user/TV Shows/{TV show name}/Season ##/filename.mkv /mnt/user/Music/{Bitrate}/Artist/Album/filename.mp3 I seem to have narrowed down my problematic program to be Recorded TV HD for Windows Media Server. Thanks!

Ha, that's what I ended up doing (creating a separate non-passthrough VM.) Running a qemu-img check did find some stuff. Not sure if it will clear the dirty bit as now my VM crashes at the Windows boot. root@Tower:/mnt/disk/snapvms/vm# qemu-img check WindowsMediaCenter.qcow2 Leaked cluster 1349986 refcount=1 reference=0 Leaked cluster 1349987 refcount=1 reference=0 Leaked cluster 1349988 refcount=1 reference=0 Leaked cluster 1349990 refcount=1 reference=0 Leaked cluster 1349991 refcount=1 reference=0 Leaked cluster 1349992 refcount=1 reference=0 Leaked cluster 1349993 refcount=1 reference=0 Leaked cluster 1349994 refcount=1 reference=0 Leaked cluster 1349995 refcount=1 reference=0 9 leaked clusters were found on the image. This means waste of disk space, but no harm to data. 839813/983040 = 85.43% allocated, 17.67% fragmented, 0.00% compressed clusters Image end offset: 88473337856 ETA: This is the second time a snapshot has magically disappeared. I really have to just start copying the qcow2 file for backup purposes. Is there an automated way to do this? ETA2: Wasn't booting cause I ran out of disk space on the physical disk. ETA3: Turns out running out of disk space was also why chkdsk wasn't completing. *sigh*

Is there any way to have a discrete graphics card passthrough and still have VNC access to the VM at a bios level? It would really help with troubleshooting my VM's remotely. Currently having a "Disk check" issue with my VM that I was hoping to not have to redo the XML in order to troubleshoot it remotely.