snocrash

Oh I see. Well this is the largest size disk at 8TB and my parity rebuilds run about 128MB/s at the moment. A standard rebuild is certainly easier to run, too.

I could rebuild, sure. But if I have an identical drive and can take the array offline, a clone would be much faster wouldn’t it? Assuming it could be done.

I have a working drive in my array that has some physical damage. It works for now but I want to swap while I have a chance. I have a spare identical model drive. Can I remove the damaged one and clone it to my spare and just swap it in? Would the array not understand the new serial number and assume the old one is missing?

I've done a few builds for Unraid that are on the larger side - 4U chassis with dual CPU motherboards. They are big ugly brutes relegated to the network closet. I'm looking to build a smaller, somewhat better looking system for a friend that will serve as a Drobo replacement. It will use 5-8 drives (8 would really be the max). No Docker, no VMs. Just basic network shares for Kodi / Plex. I'm sure I can source just about anything on eBay, but trying to figure out the best approach: Case: Something like the Silverstone CaseStorage CS380 It has 8 front facing slots for drives. Motherboard: Having trouble with this. I don't need much, so I can go with an older chipset. MicroATX? Low power CPU? Should I look for a micro-ATX motherboard with a single PCI slot and grab one of those IT flashed DELL HBAs with dual SAS ports on it? I've used those cards before - that would give me 8 SATA, plus bonus ports on the motherboard. Something in the LGA1150 socket like this, for $50? (Gigabyte H81) CPU: If I do an 1150 socket, I've seen i5-4460 CPUs for $30-$40. ------ Has anyone done a build like this, where you just want basic file sharing only? Thanks so much!

And that was with Seabios or OVMF? (You didn't ask me, but I'm here reading) This only worked with SeaBIOS, not OVMF, as I get the boot loader options, and no booted Kodi Installer menu. On another note: I still don't get why SeaBIOS doesn't work for you!?.. I have 2 different makes/brands of the GT720, and they all work with it. Here is my XML of the VM. It's a Q35 machine, not 440fx. <domain type='kvm' id='29' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'> <name>Kodibuntu-MBR</name> <uuid>2216af8a-f4ec-4bcf-2f81-4a2b3efee705</uuid> <metadata> <vmtemplate name="Custom" icon="ubuntu.png" os="ubuntu"/> </metadata> <memory unit='KiB'>1048576</memory> <currentMemory unit='KiB'>1048576</currentMemory> <memoryBacking> <nosharepages/> <locked/> </memoryBacking> <vcpu placement='static'>2</vcpu> <cputune> <vcpupin vcpu='0' cpuset='10'/> <vcpupin vcpu='1' cpuset='11'/> </cputune> <resource> <partition>/machine</partition> </resource> <os> <type arch='x86_64' machine='pc-q35-2.3'>hvm</type> </os> <features> <acpi/> <apic/> </features> <cpu mode='host-passthrough'> <topology sockets='1' cores='2' threads='1'/> </cpu> <clock offset='utc'> <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='writeback'/> <source file='/mnt/disk1/Kodi/Kodibuntu-MBR.img'/> <backingStore/> <target dev='hda' bus='virtio'/> <boot order='1'/> <alias name='virtio-disk0'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x04' function='0x0'/> </disk> <controller type='usb' index='0' model='ich9-ehci1'> <alias name='usb'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x02' function='0x7'/> </controller> <controller type='usb' index='0' model='ich9-uhci1'> <alias name='usb'/> <master startport='0'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x02' function='0x0' multifunction='on'/> </controller> <controller type='sata' index='0'> <alias name='ide'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/> </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'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x1e' function='0x0'/> </controller> <controller type='pci' index='2' model='pci-bridge'> <alias name='pci.2'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x01' function='0x0'/> </controller> <controller type='virtio-serial' index='0'> <alias name='virtio-serial0'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x03' function='0x0'/> </controller> <interface type='bridge'> <mac address='52:54:00:95:5c:a5'/> <source bridge='br0'/> <target dev='vnet4'/> <model type='virtio'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x01' function='0x0'/> </interface> <serial type='pty'> <source path='/dev/pts/4'/> <target port='0'/> <alias name='serial0'/> </serial> <console type='pty' tty='/dev/pts/4'> <source path='/dev/pts/4'/> <target type='serial' port='0'/> <alias name='serial0'/> </console> <channel type='unix'> <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/Kodibuntu-MBR.org.qemu.guest_agent.0'/> <target type='virtio' name='org.qemu.guest_agent.0' state='disconnected'/> <alias name='channel0'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> <hostdev mode='subsystem' type='usb' managed='yes'> <source> <vendor id='0x20a0'/> <product id='0x0001'/> <address bus='6' device='2'/> </source> <alias name='hostdev0'/> </hostdev> <memballoon model='virtio'> <alias name='balloon0'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x05' function='0x0'/> </memballoon> </devices> <qemu:commandline> <qemu:arg value='-device'/> <qemu:arg value='ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=2,chassis=1,id=root.1'/> <qemu:arg value='-device'/> <qemu:arg value='vfio-pci,host=03:00.0,bus=pcie.0,multifunction=on,x-vga=on'/> <qemu:arg value='-device'/> <qemu:arg value='vfio-pci,host=03:00.1,bus=pcie.0'/> </qemu:commandline> </domain>

First off - the total resources needed for a Kodibuntu install is 3.5G. I put mine on an 8G drive, running with 2-cores, and 1G of RAM. It's definitely smaller than Windows, and when its this small, I say its competitive with OE. You are close on your install. This is the video I was trying to link in my first post - but it just wont show up for some reason. Go to Youtube and search this video: "16qSdmtxPdQ". Its called "Update Kodibuntu and Upgrade Kodi---Step Two" The step they have in there that you may not have done is to update the core Ubuntu: sudo apt-get update sudo apt-get install update-manager-core sudo apt-get install software-properties-common Then add the repository for Kodi: sudo add-apt-repository ppa:team-xbmc/ppa Update, then install Kodi sudo apt-get update sudo apt-get install kodi ------- Again the OpenGL error occurs on first boot while still in VNC mode. SSH in to the machine while that error is on-screen and do all of these updates. Then, you do have to add the sound.conf file to the system. I don't think it exists by default, so you have to make it: sudo nano /etc/modprobe.d/sound.conf add this line: "options snd-hda-intel enable_msi=1" Shut it down, add your video card and sound card in to the VM definition, remove VNC and start it up. That's literally all I had to do. Once inside, you can check System Info in Kodi to see the version you are running (16), and the Nvidia driver version (361 at the time of this writing).

I don't see why not - we have the exact same setup. My GT720s work just fine. What happens when you boot the Kodibuntu ISO? Are you taken to the EFI menu or does it boot straight away? When I first set up the VM, I use the stock KodiBuntu installer ISO. (its v14) as my OS install disk, and VNC as my graphics card. It boots immediately to the Kodi Installer Boot Menu. After the install, I add the graphics card in, replacing VNC. During that next boot up, the VM will stop and give you an error about not having a card. thats when you SSH in to install the drivers. After that reboot, the VM will boot up each time to the standard Ubuntu boot menu, which has a 10-second timer, and auto-boots in to KodiBuntu.

2nd post in this thread: https://lime-technology.com/forum/index.php?topic=45227.msg431817#msg431817

I don't see why not - we have the exact same setup. My GT720s work just fine.

In just about all the VMs I've tried, when a video card is passed through and connected to an HDMI output (TV, receiver, etc), the VM will not boot unless the output is connected and turned on. Is there a global solution that addresses this? Or are there VM-specific methods that address this? In particular, I'd like to reboot OpenElec/Kodibuntu VMs without having to go to the TV and receiver and power everything on. Is there some way to grab the last-used EDID and code it in somewhere? Something along those lines?

Yeah, go for it. The install was really not that bad. Set up a stock Ubuntu VM in Unraid, with 2GB of RAM and a new 8GB vdisk. Use the 2GB of RAM for the install process - I think it makes it go a little quicker. Use the official Kodibuntu release as your installer ISO. Once you are done installing, you can drop the RAM down to 1GB. I'm pretty sure if you do the install with VNC (instead of a graphics card), the moment you reboot with a graphics card added in, it will error out, telling you to install the card. From there, just follow the basic command line instructions for installing Nvidia drivers: add the graphics-drivers ppa: $ sudo add-apt-repository ppa:graphics-drivers/ppa $ sudo apt-get update install the latest driver (use the major release number) $ sudo apt-get install nvidia-361 restart your system $ sudo reboot After that, there are a couple tutorials on updating the core Ubuntu, and the kodi release, also via SSH. I need to find the link, but I believe this Youtube covered it:

I'm using KodiBuntu installations on multiple VMs, and they all use a MySQL database. I thought I'd share a quick and easy method for building and sharing the Thumbnail art cache that multiple Kodi installations can share. I am sure this works the same with an OE install. So far, I haven't had any issues, and it seems very snappy on each VM. There's several ways to accomplish it - this just happens to be one method. In short, I use an NFS share as my central folder for all artwork, and I mount that share into the "Thumbnails" folder on each VM. Then, I force a manual build of the artwork cache, so its already set. I did this because I like having my central MySQL DB, and if I want to add, remove, or change my Kodi VMs, I can have a central, pre-built artwork cache ready to go. A newly created VM can be fully up to date with the entire library. Make the Share for the Cache: Create an NFS-exported Share in UnRaid - call it "cache" (this is an example) Clear out the current Cache: SSH or navigate to each VM and delete the contents of your "Thumbnails" folder. Keep the folder, but delete out all the subfolders. Mount the Share for each VM: SSH in to each VM and edit your FSTAB file to mount that share. I use nano, so the command is "sudo nano /etc/fstab" The line you will add to FSTAB is "unraid-server-IP:/mnt/user/cache /home/kodi/.kodi/userdata/Thumbnails nfs" This mounts the nfs share into the Thumbnails folder. If your share name is something other than "cache", use that share name. Check the path to the Thumbnails folder - on kodibuntu, that's where it is located. Reboot the first VM to make sure the mount works. Force build the Cache: Starting with the first VM, make sure it is connected to the MySQL DB. SSH in to this VM and run this Kodi utility: Texture Cache Maintenance Utility (http://forum.kodi.tv/showthread.php?tid=158373) The only command switch you really need to use is "c", which is to Create the texture cache. You run this once for "Movies" and once for "TVShows" Once those two passes complete, you should now have a folder full of artwork like normal. And you should also see that same artwork on your NFS share. Reboot all the other VMs and make sure the mounts worked. It's pretty easy to test - anytime you make a change to artwork or add a movie, they will all reflect that change. But more importantly, each VM should display the artwork in your library very quickly, since it is all pre-cached. Any time you make a new VM, just do the same FSTAB mount routine.

This thread is pretty long-running, but I thought I'd throw in another recommendation for MediaMonkey, and its really powerful Auto-Organize feature. It lets you set up a staging area that it monitors for incoming music. From there, it will create a folder structure and rename the music files to any destination you want, based on a custom criteria you set up. You define the folders and name structure of the files. If you need to re-tag the metadata and clean up filenames, you can use its built-in tagging functionality, and as soon as you update the files, it auto-organizes them again. It's a nice way to not only tag the metadata, but it keeps your folders and filenames nice and clean.

I've spent so much time testing (sitting and watching movies, really) and I've started nit-picking my Kodi experience, looking for a flawless setup. At any rate, I have tested three versions of a Kodi installation, using the same movies on the same home theater setup, and I'm finding that KodiBuntu seems to be the "best" solution so far for me. For every setup, I'm using 2-cores, 2GB RAM (for OE/Kodibuntu) and 8GB RAM (Windows), an Nvidia GT720, fed in to a Marantz SR5009, going to a Panasonic VT50 plasma, and "set refresh rate of TV to match" is enabled in Kodi. Video playback is perfect on all my setups - low CPU usage and buttery smooth. OpenElec is a great starter, and it is very stable during use. It's super easy to set up. The built-in template is decent, and JohnOdons writeup on how to do a proper installation is better. (https://lime-technology.com/forum/index.php?topic=44683.0). The built in template is a little bit behind the regular release, and I find that the latest release reduces a lot of these issues, but doesn't entirely eliminate them. I will randomly get SMB "issues". Slow network browsing, and every once in a while when I choose a video from my Library, OE throws an error saying the "media is gone, do you want it removed from your library?" On initial bootup, OE doesn't see the MySQL database for the library and needs to be restarted from within OE. That restart always results in the DB connecting and Library showing up correctly. The glitch is only on first boot. If left on for a few days, eventually it just crashes. I don't know if this is an HDMI handshaking issue, or a screen/interface issue, but I'll come back to OE and it will be a black screen. (My receiver has been off, the TV off, but OE left running) Interface sounds will work, and it is still on the network, but the screen is gone. I haven't experimented specifically with disabling screen saver yet. I have been using a mix of "Dim" and "image slideshows" HD audio passthrough does work, and I can confirm that every type of audio I have will passthrough correctly. The problem is I get audio dropouts during a movie. It is usually 2-5 events, about a half second each. It happens totally randomly - not in the same place twice. No combination of settings in OE seem to make any improvement. Nitpicky, I know. But when you have it cranked up full blast, that little hiccup is annoying. Kodi under Windows 7 feels like ridiculous overkill. I had to waste 25-30GB of an SSD setting up Windows7 with ServicePack1 (no DXVA2 without SP1). It works, and I don't have a ton of complaints, but I'm not setting up 4 Windows installations just to run Kodi. Audio passthrough seems to work flawlessly. I haven't heard a single dropout yet. SMB performance seems to be just fine - I haven't noticed any hiccups or slowness. DXVA2 works, and I do get lower CPU usage (vs non-dxva). But I still have odd spikes in CPU usage during playback. Nothing that causes jerkiness or dropped frames, but overall this setup uses the CPUs a lot more than OE or KodiBuntu does. I don't know if I'm imagining things, but the image quality with DXVA2 looks slightly different than what you get with VDPAU. Highlight edges seemed a little rougher / more jagged. Again, I could be wrong. KodiBuntu is interesting, and it feels like a nice compromise right between the first two. I set up an Ubuntu VM and used the official "KodiBuntu" release from Kodi.com as the installation OS, and I gave the VM an 8GB drive. Installation was pretty straightforward, except I ran mine through VNC at the beginning. Once installation finished, I added my video card to the VM, and let it boot up to my TV and got an error screen saying "there is no OpenGL card installed". SSH is enabled by default, so I was able to quickly install the latest Nvidia drivers and reboot it once more. From there, I had a working Kodi v14. A couple of quick PPA updates later, and I had the latest Ubuntu release and the latest Kodi v16 release. Any of the three major components can be updated via simple SSH commands: the core Ubuntu, the Kodi release, the Nvidia drivers. This is a big deal, because it gives me all the flexibility I would get in Windows, but with that compact OE feel. SMB is much snappier, and I haven't seen the errors or issues I had with OE. I've rebooted the VM several times, and each time it connects to the MySQL correctly on the first boot. HD audio passthrough works right out of the box, and I haven't had any drop-outs. Oh wait, I lied - I DID add the MSI interrupt line to the sound.conf file on this install, same as you would for OE. So one tiny tweak. Image quality is good (as good as OE was) and all playback has been very smooth. Setup is about as complex as a regular OE install, but all the work is in the updates via SSH (not hard) - and no real tweaks to the VM XML are needed. Other thoughts: I'm not sure exactly why OE and KodiBuntu are noticeably different, but I assume it is because with KodiBuntu, I'm able to use the latest release of all the underlying components (Ubuntu, Kodi, Nvidia), and Ubuntu is totally ready to use in a VM environment. They take up the same resources, run the same, and install with about the same amount of work.

I assigned 1 core / 1 GB just as proof of concept. I finally settled on 2 cores / 2 GB for each VM since I have plenty of headroom. So, OE1 has cores 15/16 pinned. OE2 has cores 13/14 pinned. OE3 has cores 11/12 pinned. I have not done anything special in advancedsettings or any extra config. I haven't experienced any CPU spikes when watching movies on my VM for the home theater which as an amp. All of my media is MKVs. John Perfect, thank you. It looks like I had all of my cores assigned and running on several test VMs, so I had all my resources completely maxed out. Now that I freed those up, those spikes are gone. Just basic VM management. It looks like one core is plenty for basic playback and the stock skin. I found that if I started using some of the more advanced skins with all the extra plugins, 2-cores makes the interface a little snappier.

Hey JohnOdon, You said you allocated a single core to each of your VMs, with 1GB of RAM. Did you make any configurations to the buffer, or anything else in AdvancedSettings? Or, when you split up a physical core by assigning one core to a VM - where did the other one go? I thought it didnt really matter how you split up physical cores. When I enable DTS-HD or TRUE-HD passthrough, I get random CPU spikes during playback. Sometimes playback settles in around 25%, but then it goes on these long runs of 60,70,80% or higher. I get occasional frame skips - maybe 200-300 for a full movie run when the CPU spikes up to 100%. If I enable 2-cores, they each settle in around 25%, and can spike as high as 50%. No skips or drops - its nice and clean. We have the same board, same chips, and same video cards. I'm streaming my m2ts files off a NAS.

I actually just enabled SSH from inside OE and copied my user data files in that way.

This is soooo good. Thanks for putting this together. I have an almost identical setup to you and have been using the built-in LT templates without HD audio passthrough up until this. Now, I have 4 of these running with the GT720s and full HD audio passthrough and IR control, all tied to a centralized MySQL DB on a separate Debian VM. It's awesome when it all comes together.

Here's a few little tips I discovered about using the OpenELEC VMs. In short, the built-in templates CAN work flawlessly, but you have to be very careful how you connect everything up and how you boot up. I now have three simultaneous OE VMs running, with a centralized MySQL DB for the library, which is hosted on a Debian VM. It all finally works. I've had a TON of very frustrating inconsistencies with my OpenElec VMs not starting up properly, and I have been chasing my tail trying to figure out what was wrong. I could start one, but not another. After reboot, one that used to work no longer worked. I ASSumed the issue was the video card passthrough, and I even went on a wild tangent resetting all my storage devices to see if that was the problem. It wasn't. Point #1 - All your home theater gear has to be on first! In my initial setup and testing, I created three OpenElec VMs, with their own video cards. I wanted to start them all up, do my configurations, then deploy them to the TVs in my house. But I don't have all three TVs set up yet, and my test bench was set up with one screen only. I just ASSumed I could start each one up, switch the HDMI cable between the three, and test/configure. This created chaos, because only the active/plugged in VM would launch - the others would fail. Or more precisely - they are waiting. OpenELEC will pause the boot up if all the HDMI handshaking doesn't work from the beginning. If your receiver is off, OpenELEC will "start", but will not actually finish booting, or load up Kodi. I discovered this when I started my VM from the web console, and waited for the Kodi Remote app to pick up the IP for that VM. The VM never appeared, never got an IP, and appeared to be stuck. I went to the TV is was connected to, turned ON my receiver, and suddenly that VM finished its boot and worked perfectly. I've had all these issues because I never tested the full setup at once, with all the TVs and receivers connected and running until now. Point #2 - Not all connections will work! Here's another ugly discovery I made. If I connect my video card direct to a receiver, and even direct to a TV with an HDMI cable, things work just fine. However, I am not having much luck using HDMI splitters and switches. In one of my setups, I have an HDMI cable running from the video card direct to an HDMI switch (the other port is my cable box). The switch only shows a blank screen on the OpenELEC input. I hate, hate, hate HDMI for this and I wish I understood more about why these kinds of things dont work. HDCP and EDID are soooo frustrating. Point #3 - HDBASET works just fine I can confirm that HDBASET works great. I am using the Monoprice sender unit, and the Monoprice wall mount receiver unit (at the TV). I have connected the video card to a receiver with HDMI-out (and audio diverted to TV instead of speakers). The receiver HDMI-out pipes in to the HDBASET transmitter, and is sent along its way via CAT6. The CAT6 run is about 60-70' in-wall and connects to the receiver unit (wall mounted behind the TV). That HDMI out can go direct to the TV, or instead, I've run it through a splitter which passes the HDMI out, and splits off a TOSLINK connection for a sound bar. The result is 5.1 audio to the soundbar, and HDMI picture to the TV.

Is there a guide or writeup on how to add additional drives to a Windows 7 VM? I have my VM up and running and wanted to add 4TB of space to a new drive in Windows. I keep getting errors inside Windows, so I must not be doing something quite right. I installed Win7 using the RedHat VirtIO drivers - the OS is installed to a 50GB OS drive. When I add a 4TB disk image to the VM, it shows up in Windows 7 as x2 2TB drives. I can't get them to combine to a single 4TB. Is there a driver or a specific way to set this up correctly? Thanks!

Ive marked this as solved for now and updated the original post with the update, in case anyone comes across similar issues.

I'm having similar issues as mark, actually. I've been through a billion reconfigs and variations of my setup, but if I enable the PCIe ACS Override setting, I can get one of my VMs to run, and passthrough a video card (doesnt matter which - any one will work). If I attempt to launch a second or a 3rd, I get errors just like his. My IOMMU groups are listed totally wrong, with the video and audio portion of the card getting different groups. When I disable the ACS Override, all my groups return to normal again and I don't get the error. Unfortunately, I still can't get more than one VM to work with a video card passthrough. Where my experience starts to differ from the expected is that when I get my one VM to work with a video card passthrough (using SeaBios), I STILL retain my VGA console. Works just fine, side by side with my passthrough VM.

Update: I have updated the BIOS of my motherboard to 2.1b, which is the latest version. My startup log doesn't seem to have the same PCI errors, but there are a few strange ones. I have attached the latest system log from the point of boot, through trying to start an OpenElec VM. Back to Broken: Now my problem is that no matter what my primary boot video device is - no other video device will work. If I launch a VM that is set to use the boot video card - the VM will take it over and work. None of my other VMs will launch and use their video cards. I can't get the two to start up like I did before. Any attempt at launching VMs that use extra video cards results in the Console locking up and no VMs launching. Once I try to launch a VM that has been assigned a video card, my primary console screen is locked, and I can't type in to it anymore. I have to restart the entire server again. It seems like my primary boot video card gets locked in to a state where no other video cards are allowed to work. This is the final entry in the log when I attempt to start up my OpenElec VMs. In this scenario 84 is my boot video card, and 03 and 04 are my extra cards. Sep 23 10:35:40 Tower kernel: device vnet0 entered promiscuous mode Sep 23 10:35:40 Tower kernel: virbr0: port 2(vnet0) entered listening state Sep 23 10:35:40 Tower kernel: virbr0: port 2(vnet0) entered listening state Sep 23 10:35:40 Tower kernel: vgaarb: device changed decodes: PCI:0000:03:00.0,olddecodes=io+mem,decodes=io+mem:owns=none Sep 23 10:35:40 Tower kernel: vgaarb: device changed decodes: PCI:0000:04:00.0,olddecodes=io+mem,decodes=io+mem:owns=none Sep 23 10:35:40 Tower kernel: vgaarb: device changed decodes: PCI:0000:84:00.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem Sep 23 10:35:41 Tower kernel: vfio-pci 0000:04:00.0: enabling device (0000 -> 0003) Sep 23 10:35:42 Tower kernel: virbr0: port 2(vnet0) entered learning state Sep 23 10:35:43 Tower kernel: vgaarb: device changed decodes: PCI:0000:84:00.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem Sep 23 10:35:43 Tower kernel: vgaarb: device changed decodes: PCI:0000:04:00.0,olddecodes=io+mem,decodes=io+mem:owns=none Sep 23 10:35:43 Tower kernel: vgaarb: device changed decodes: PCI:0000:03:00.0,olddecodes=io+mem,decodes=io+mem:owns=none Sep 23 10:35:44 Tower kernel: virbr0: topology change detected, propagating Sep 23 10:35:44 Tower kernel: virbr0: port 2(vnet0) entered forwarding state Is it possible that a BIOS setting is causing these issues? (VT-D has always been on) Do I have bad video cards? All three video cards? Are there variations in the 6450 series that would make these particular ones not work, but others will?

Thanks guys, for helping out. I might have found something, but not sure how to track it down. Update - Partially working setup: My best configuration is with the onboard VGA enabled for console, and three video cards in slots 84,85,86. I have three VMs: OE1, OE2, OE3. They are each assigned a card. I started up OE1, and my console screen showed a PXE boot message, while my secondary display actually showed OpenElec. Working! I started up OE2, and my console screen showed the same PXE boot message, while my secondary display showed OpenElec. Working! So that's two simultaneous VMs running correctly. When I started up OE3, I got nothing. No log, no video. So that's two out of three. Tests I decided to switch the cards around to match Johnodon's setup (83,84,86), and while booting I happened to see some errors come across the screen while UnRaid was starting up. Sep 22 13:57:37 Tower kernel: pci 0000:80:09.0: BAR 13: no space for [io size 0x1000] Sep 22 13:57:37 Tower kernel: pci 0000:80:09.0: BAR 13: failed to assign [io size 0x1000] Sep 22 13:57:37 Tower kernel: pci 0000:80:00.0: PCI bridge to [bus 81] Sep 22 13:57:37 Tower kernel: pci 0000:80:01.0: PCI bridge to [bus 82] Sep 22 13:57:37 Tower kernel: pci 0000:80:03.0: PCI bridge to [bus 83] Sep 22 13:57:37 Tower kernel: pci 0000:80:03.0: bridge window [io 0xd000-0xdfff] Sep 22 13:57:37 Tower kernel: pci 0000:80:03.0: bridge window [mem 0xf8d00000-0xf8dfffff] Sep 22 13:57:37 Tower kernel: pci 0000:80:03.0: bridge window [mem 0xb0000000-0xbfffffff 64bit pref] Sep 22 13:57:37 Tower kernel: pci 0000:80:05.0: PCI bridge to [bus 84] Sep 22 13:57:37 Tower kernel: pci 0000:80:05.0: bridge window [io 0xe000-0xefff] Sep 22 13:57:37 Tower kernel: pci 0000:80:05.0: bridge window [mem 0xf8e00000-0xf8efffff] Sep 22 13:57:37 Tower kernel: pci 0000:80:05.0: bridge window [mem 0xc0000000-0xcfffffff 64bit pref] Sep 22 13:57:37 Tower kernel: pci 0000:80:07.0: PCI bridge to [bus 85] Sep 22 13:57:37 Tower kernel: pci 0000:86:00.0: BAR 4: no space for [io size 0x0100] Sep 22 13:57:37 Tower kernel: pci 0000:86:00.0: BAR 4: trying firmware assignment [io size 0x0100] Sep 22 13:57:37 Tower kernel: pci 0000:86:00.0: BAR 4: [io size 0x0100] conflicts with PCI Bus 0000:80 [io 0xd000-0xffff window] Sep 22 13:57:37 Tower kernel: pci 0000:86:00.0: BAR 4: failed to assign [io size 0x0100] Sep 22 13:57:37 Tower kernel: pci 0000:80:09.0: PCI bridge to [bus 86] Sep 22 13:57:37 Tower kernel: pci 0000:80:09.0: bridge window [mem 0xf8f00000-0xf8ffffff] Sep 22 13:57:37 Tower kernel: pci 0000:80:09.0: bridge window [mem 0xd0000000-0xdfffffff 64bit pref] Sep 22 13:57:37 Tower kernel: pci_bus 0000:80: Some PCI device resources are unassigned, try booting with pci=realloc Sep 22 13:57:37 Tower kernel: pci_bus 0000:80: resource 4 [io 0xd000-0xffff window] Sep 22 13:57:37 Tower kernel: pci_bus 0000:80: resource 5 [mem 0xb0000000-0xdfffffff window] Sep 22 13:57:37 Tower kernel: pci_bus 0000:80: resource 6 [mem 0xf0000000-0xf8ffffff window] Sep 22 13:57:37 Tower kernel: pci_bus 0000:83: resource 0 [io 0xd000-0xdfff] Sep 22 13:57:37 Tower kernel: pci_bus 0000:83: resource 1 [mem 0xf8d00000-0xf8dfffff] Sep 22 13:57:37 Tower kernel: pci_bus 0000:83: resource 2 [mem 0xb0000000-0xbfffffff 64bit pref] Sep 22 13:57:37 Tower kernel: pci_bus 0000:84: resource 0 [io 0xe000-0xefff] Sep 22 13:57:37 Tower kernel: pci_bus 0000:84: resource 1 [mem 0xf8e00000-0xf8efffff] Sep 22 13:57:37 Tower kernel: pci_bus 0000:84: resource 2 [mem 0xc0000000-0xcfffffff 64bit pref] Sep 22 13:57:37 Tower kernel: pci_bus 0000:86: resource 1 [mem 0xf8f00000-0xf8ffffff] Sep 22 13:57:37 Tower kernel: pci_bus 0000:86: resource 2 [mem 0xd0000000-0xdfffffff 64bit pref] Sep 22 13:57:37 Tower kernel: pci_bus 0000:fe: resource 4 [io 0x0000-0xffff] Sep 22 13:57:37 Tower kernel: pci_bus 0000:fe: resource 5 [mem 0x00000000-0xffffffffff] Sep 22 13:57:37 Tower kernel: pci_bus 0000:ff: resource 4 [io 0x0000-0xffff] Sep 22 13:57:37 Tower kernel: pci_bus 0000:ff: resource 5 [mem 0x00000000-0xffffffffff] This looks like something is going wrong during the boot up. Those BAR4 errors are for one of the video cards (86). I have attached the syslog from the most recent boot up. Strange console screen blank out After reboot and re-setting up the OE VMs, I'm back to everything being broken again. When I start OE1, my console screen blanks out, and i get no video from the card. When I start OE2, nothing happens at all. I'm going to see if I can set it back up to 83,84,85 and get two of them working again. Johnodon - for clarification, here is the issue: I can create multiple VMs in UnRaid and assign each a video card+sound card. But when I try to start them, I'm not able to get all of them to display video simultaneously. I can sometimes get one to work. All of my VMs have been set up using SeaBios and the stock OE VM. My Power Supply is a Seasonic SS-600H2U (http://www.seasonicusa.com/PDF/Catalog/NEW/Bulk/IPC/2U/SS-600H2U-APFC.pdf), because I am using a 2U chassis. syslog.txt

The video cards are MSI Radeon HD 6450 R6450-2GD3H/LP 2GB 64-Bit DDR3 PCI Express 2.0 x16 - http://www.newegg.com/Product/Product.aspx?Item=N82E16814127738 Now, that said - the motherboard PCIE slots are x8 (in x16 slot size). Would that cause an issue? - http://www.supermicro.com/products/motherboard/QPI/5500/X8DTH-iF.cfm Don't worry, you can't confuse the system or anything like that. ;-) Ok that's a good sign. This means you are having an issue with VGA arbitration but OVMF doesn't use VGA, so we can overcome this. If you try the ROM file with OVMF mode, OpenELEC should work just fine. Have you tried your knoppix VM with OVMF? You'd have to install it from scratch, but I'd bet other VMs would work ok. Ok please do and capture what error you receive. I've seen multiple instances of AMD cards still needing this ROM file to be specified and I bet this is another example of one of those. If we can confirm, I can get the necessary information to the upstream to see if this is fixable in a future patch. Nothing out of the ordinary there. Typically when GPU pass through doesn't work like this (black screen), the logs are not going to reveal anything. Bottom line: your motherboard and processors clearly aren't the issue. The GPUs however may be suspect. Can you provide the exact make model brand info (part number would be nice) of the 6450s you are using?