August 16, 20223 yr This is a bit of a rant, so please bear with me. I do have some valid questions at the end of this but I really want to offer as much of the surrounding information as I can give, as to not waste anyones time with a wild goose chase that I already did... Hardware For the hardware changes, to understand all that rambling at all: Server was first on an ASUS P7P55D with a Xeon L3426, with working GPU passthrough, then I switched to ASUS P6T SE with a Xeon L5460 for more cores, didn't get the passthrough to work again on that one, then I switched to ASUS P7P55D-E with an i7 870 for slightly bigger single thread rating (according to passmark ca. 1300 vs ca. 1100 on the Xeons), again, not getting the GPU passthrough to work and yesterday I switched back to the L3426 combination, mainly for power saving reasons (45W TDP vs 80W TDP on the i7 870). Additional hardware: 16GB DDR3 UDIMM RAM (4x 4GB) for the 115x boards, 12GB DDR3 UDIMM RAM (6x 2GB) for the 1366 boards, that damned ASUS GeForce GT 1030, passive, 2GB GDDR5, a Dell Perc H310 controller flashed to IT (non-raid) mode with that electrical tape mod on PCIe pins 4+5 iirc for 7 of the 8 HDDs... should probably move the last one there, too... 8th HDD, 2 SATA SSDs and optical drive are connected to onboard SATA of the mainboard. Of course there's also a case and PSU, but those don't seem very relevant. Also a DVB-S PCI card is somewhere in there, but it's not in use currently, as I haven't connected it to the sat dish yet. What happened? So... after months (okay, with also months in breaks in between), I finally managed to get my Windows 10 VM with GPU passthrough to work again yesterday, after rebuilding my server back to that L3426. I then thought "hey, why not try with a few Linux distros, too?". As I wanted to put those onto my cache pool, too, for speed reasons, I had to clean that one up before. The cache pool is only 120GB in size (2x 120gb sata ssd, btrfs encrypted mirror, btw.), and so I needed all the space I could get. What seemed to be using the most space were the docker.img and libvirt.img in the system share. So I made the stupid mistake to think "hey, those are also on drive 6 - just disable cache use, start mover and they'll be gone". Which of course they weren't, since mover doesn't remove jack shit when changing cache use from "prefer" to "no". As I then learnt, those two versions of the files aren't even synced either, which became pretty clear since after manually deleting the offending files from the cache_pool, my 2 VM's (had just started with a Linux VM when it game to a screeching halt because of "cache pool full") and 6 or so Docker apps were gone. My main problem at this point is: I can't for the life of me get that stupid VM to see the GPU again. It's just gone. Not found in the device manager of that Win10 installation, unless "hidden devices" are shown, but that, of course, doesn't help. What did I try? I did however have a slightly older version of the VM configuration XML (from yesterday, but before getting the GPU passthrough to work), so I used that as a starting point to recreate that Win10 VM with the still existing vdisk.img. I'm pretty sure at this point that the mistake can only be the VM configuration XML file, since I didn't change anything apart from deleting the libvirt.img. Since I got it to work yesterday, the hardware and BIOS of the hardware can't be a problem. Neither can the settings of Unraid in genral, since I didn't change anything after getting it to work yesterday. PCIe ACS override is set to disabled, VFIO allow unsafe interrupts is set to yes - as I said: with these setting it was working yesterday. I bound IOMMU groups 7 (one of the onboard USB controllers for mouse/keyboard use on the front of the case in the VM) and 17 (GT 1030 GPU and its Audio component in one group) to VFIO. This is still the state it was in when working yesterday. I have attached the current VM configuration XML - only deleted UUID and bridge network MAC address from it, otherwise it is the current state. The VM starts and stops as it should, is accessible via RDP and Anydesk (though on Anydesk it is nearly unusable, because no GPU found in the system, so 640x480 resolution which just isn't workable in Win10 anymore). Also the Bluetooth dongle I put into that passed through USB port seems to work just fine for mouse and keyboard, which I was able to confirm via Anydesk. Does anyone have any idea, what could be wrong with that XML? I'm relatively sure that putting GPU and its audio device on Bus 5, Slot 0 and Function 0x0 and 0x1 respectively was what I did yesterday before getting it to work. I'm equally relatively sure, that the edited vbios rom (dumped on a windows baremetal machine from the actual graphics card, then deleted the first bit of the file as per SpaceInvader's video guide with a hex editor) is the one that worked yesterday. I have tried it with the not-edited version of that same vbios dump and without passing the vbios at all as well. I also tried setting the multifunction GPU/Audio device on Bus 4 and also without editing the XML which results in putting the GPU on Bus 4 and the audio device on Bus 5, both as Function 0x0 then. Since the installed driver inside the Windows VM speaks of "PCI Bus 5, Slot 0, Function 0" for the GPU part in the details of the driver under "Location Information" - the GPU gets shown when "show hidden devices" is enabled in the device manager - I think Bus 5 should be the correct one. Configuration as a multifunction device I'm pretty sure was the correct one yesterday. I can't confirm that with the Audio part, since it only gives something like "HD Audio Device" as location information in it's driver details - also hidden of course. When putting both on Bus 6 as a multifunction device, the VM doesn't start anymore but seems to hang in the starting process, causing the first of the 4 pinned and isolated CPU cores for that VM to stay on 100% with the 3 others on 0%. If the VM boots in another configuration (Bus 5 for example for GPU and audio), this is only for a few seconds after which all 4 assigned CPU cores get used and the system then boots. Now the weird thing is, I kind of remember I put it onto Bus 6 yesterday, but I can't remember if that was when I got it to work or not. It really could have been Bus 5, which the state of the driver in the VM suggests. Also: yesterday the GPU passthrough only really started working after I got the Nvidia driver via Windows update while in the VM via Anydesk or RDP - sadly not sure which. But as I said before - the device is still "installed" driver wise, just hidden in the device manager as if it wasn't physically there. Only thing I could still think about would be removing that driver completely from Windows and hoping for the GPU to show up again then... Also: since I'm obviously not nearly experienced enough with libvirt - is there something else that might have been lost due to the deletion of that libvirt.img? What I'm trying to ask: is there something apart from the VM configuration XML, that might be messed up now, that I don't know about? I also attached the log of the VM how it starts and stops (via shutdown command inside the VM) when used with the attached VM configuration XML. For a layman like me it seems okay, notably probably this part for GPU, its audio and i guess PCI.8 is probably that USB port: -device vfio-pci,host=0000:06:00.0,id=hostdev0,bus=pci.5,multifunction=on,addr=0x0,romfile=/mnt/user/isos/vbios/GT1030_GP108_edited.rom \ -device vfio-pci,host=0000:06:00.1,id=hostdev1,bus=pci.5,addr=0x0.0x1 \ -device vfio-pci,host=0000:00:1a.0,id=hostdev2,bus=pci.8,addr=0x1 \ When starting the VM, the Unraid log shows the following, if that is any help: Aug 16 14:17:40 yggdrasil kernel: br0: port 2(vnet9) entered blocking state Aug 16 14:17:40 yggdrasil kernel: br0: port 2(vnet9) entered disabled state Aug 16 14:17:40 yggdrasil kernel: device vnet9 entered promiscuous mode Aug 16 14:17:40 yggdrasil kernel: br0: port 2(vnet9) entered blocking state Aug 16 14:17:40 yggdrasil kernel: br0: port 2(vnet9) entered forwarding state Aug 16 14:17:41 yggdrasil kernel: vfio-pci 0000:06:00.0: vfio_ecap_init: hiding ecap 0x19@0x900 Aug 16 14:17:41 yggdrasil kernel: vfio-pci 0000:06:00.0: No more image in the PCI ROM Aug 16 14:17:42 yggdrasil avahi-daemon[9926]: Joining mDNS multicast group on interface vnet9.IPv6 with address REDACTED. Aug 16 14:17:42 yggdrasil avahi-daemon[9926]: New relevant interface vnet9.IPv6 for mDNS. Aug 16 14:17:42 yggdrasil avahi-daemon[9926]: Registering new address record for REDACTED on vnet9.*. Aug 16 14:17:42 yggdrasil kernel: vfio-pci 0000:00:1a.0: vfio_cap_init: hiding cap 0xa@0x58 I'd really appreciate some input here, especially about something I possibly overlooked regarding the loss of the libvirt.img file. Best regards, buetzel current_vm.xml vm.log
August 16, 20223 yr 1 hour ago, buetzel said: This is a bit of a rant, so please bear with me. I do have some valid questions at the end of this but I really want to offer as much of the surrounding information as I can give, as to not waste anyones time with a wild goose chase that I already did... Hardware For the hardware changes, to understand all that rambling at all: Server was first on an ASUS P7P55D with a Xeon L3426, with working GPU passthrough, then I switched to ASUS P6T SE with a Xeon L5460 for more cores, didn't get the passthrough to work again on that one, then I switched to ASUS P7P55D-E with an i7 870 for slightly bigger single thread rating (according to passmark ca. 1300 vs ca. 1100 on the Xeons), again, not getting the GPU passthrough to work and yesterday I switched back to the L3426 combination, mainly for power saving reasons (45W TDP vs 80W TDP on the i7 870). Additional hardware: 16GB DDR3 UDIMM RAM (4x 4GB) for the 115x boards, 12GB DDR3 UDIMM RAM (6x 2GB) for the 1366 boards, that damned ASUS GeForce GT 1030, passive, 2GB GDDR5, a Dell Perc H310 controller flashed to IT (non-raid) mode with that electrical tape mod on PCIe pins 4+5 iirc for 7 of the 8 HDDs... should probably move the last one there, too... 8th HDD, 2 SATA SSDs and optical drive are connected to onboard SATA of the mainboard. Of course there's also a case and PSU, but those don't seem very relevant. Also a DVB-S PCI card is somewhere in there, but it's not in use currently, as I haven't connected it to the sat dish yet. What happened? So... after months (okay, with also months in breaks in between), I finally managed to get my Windows 10 VM with GPU passthrough to work again yesterday, after rebuilding my server back to that L3426. I then thought "hey, why not try with a few Linux distros, too?". As I wanted to put those onto my cache pool, too, for speed reasons, I had to clean that one up before. The cache pool is only 120GB in size (2x 120gb sata ssd, btrfs encrypted mirror, btw.), and so I needed all the space I could get. What seemed to be using the most space were the docker.img and libvirt.img in the system share. So I made the stupid mistake to think "hey, those are also on drive 6 - just disable cache use, start mover and they'll be gone". Which of course they weren't, since mover doesn't remove jack shit when changing cache use from "prefer" to "no". As I then learnt, those two versions of the files aren't even synced either, which became pretty clear since after manually deleting the offending files from the cache_pool, my 2 VM's (had just started with a Linux VM when it game to a screeching halt because of "cache pool full") and 6 or so Docker apps were gone. My main problem at this point is: I can't for the life of me get that stupid VM to see the GPU again. It's just gone. Not found in the device manager of that Win10 installation, unless "hidden devices" are shown, but that, of course, doesn't help. What did I try? I did however have a slightly older version of the VM configuration XML (from yesterday, but before getting the GPU passthrough to work), so I used that as a starting point to recreate that Win10 VM with the still existing vdisk.img. I'm pretty sure at this point that the mistake can only be the VM configuration XML file, since I didn't change anything apart from deleting the libvirt.img. Since I got it to work yesterday, the hardware and BIOS of the hardware can't be a problem. Neither can the settings of Unraid in genral, since I didn't change anything after getting it to work yesterday. PCIe ACS override is set to disabled, VFIO allow unsafe interrupts is set to yes - as I said: with these setting it was working yesterday. I bound IOMMU groups 7 (one of the onboard USB controllers for mouse/keyboard use on the front of the case in the VM) and 17 (GT 1030 GPU and its Audio component in one group) to VFIO. This is still the state it was in when working yesterday. I have attached the current VM configuration XML - only deleted UUID and bridge network MAC address from it, otherwise it is the current state. The VM starts and stops as it should, is accessible via RDP and Anydesk (though on Anydesk it is nearly unusable, because no GPU found in the system, so 640x480 resolution which just isn't workable in Win10 anymore). Also the Bluetooth dongle I put into that passed through USB port seems to work just fine for mouse and keyboard, which I was able to confirm via Anydesk. Does anyone have any idea, what could be wrong with that XML? I'm relatively sure that putting GPU and its audio device on Bus 5, Slot 0 and Function 0x0 and 0x1 respectively was what I did yesterday before getting it to work. I'm equally relatively sure, that the edited vbios rom (dumped on a windows baremetal machine from the actual graphics card, then deleted the first bit of the file as per SpaceInvader's video guide with a hex editor) is the one that worked yesterday. I have tried it with the not-edited version of that same vbios dump and without passing the vbios at all as well. I also tried setting the multifunction GPU/Audio device on Bus 4 and also without editing the XML which results in putting the GPU on Bus 4 and the audio device on Bus 5, both as Function 0x0 then. Since the installed driver inside the Windows VM speaks of "PCI Bus 5, Slot 0, Function 0" for the GPU part in the details of the driver under "Location Information" - the GPU gets shown when "show hidden devices" is enabled in the device manager - I think Bus 5 should be the correct one. Configuration as a multifunction device I'm pretty sure was the correct one yesterday. I can't confirm that with the Audio part, since it only gives something like "HD Audio Device" as location information in it's driver details - also hidden of course. When putting both on Bus 6 as a multifunction device, the VM doesn't start anymore but seems to hang in the starting process, causing the first of the 4 pinned and isolated CPU cores for that VM to stay on 100% with the 3 others on 0%. If the VM boots in another configuration (Bus 5 for example for GPU and audio), this is only for a few seconds after which all 4 assigned CPU cores get used and the system then boots. Now the weird thing is, I kind of remember I put it onto Bus 6 yesterday, but I can't remember if that was when I got it to work or not. It really could have been Bus 5, which the state of the driver in the VM suggests. Also: yesterday the GPU passthrough only really started working after I got the Nvidia driver via Windows update while in the VM via Anydesk or RDP - sadly not sure which. But as I said before - the device is still "installed" driver wise, just hidden in the device manager as if it wasn't physically there. Only thing I could still think about would be removing that driver completely from Windows and hoping for the GPU to show up again then... Also: since I'm obviously not nearly experienced enough with libvirt - is there something else that might have been lost due to the deletion of that libvirt.img? What I'm trying to ask: is there something apart from the VM configuration XML, that might be messed up now, that I don't know about? I also attached the log of the VM how it starts and stops (via shutdown command inside the VM) when used with the attached VM configuration XML. For a layman like me it seems okay, notably probably this part for GPU, its audio and i guess PCI.8 is probably that USB port: -device vfio-pci,host=0000:06:00.0,id=hostdev0,bus=pci.5,multifunction=on,addr=0x0,romfile=/mnt/user/isos/vbios/GT1030_GP108_edited.rom \ -device vfio-pci,host=0000:06:00.1,id=hostdev1,bus=pci.5,addr=0x0.0x1 \ -device vfio-pci,host=0000:00:1a.0,id=hostdev2,bus=pci.8,addr=0x1 \ When starting the VM, the Unraid log shows the following, if that is any help: Aug 16 14:17:40 yggdrasil kernel: br0: port 2(vnet9) entered blocking state Aug 16 14:17:40 yggdrasil kernel: br0: port 2(vnet9) entered disabled state Aug 16 14:17:40 yggdrasil kernel: device vnet9 entered promiscuous mode Aug 16 14:17:40 yggdrasil kernel: br0: port 2(vnet9) entered blocking state Aug 16 14:17:40 yggdrasil kernel: br0: port 2(vnet9) entered forwarding state Aug 16 14:17:41 yggdrasil kernel: vfio-pci 0000:06:00.0: vfio_ecap_init: hiding ecap 0x19@0x900 Aug 16 14:17:41 yggdrasil kernel: vfio-pci 0000:06:00.0: No more image in the PCI ROM Aug 16 14:17:42 yggdrasil avahi-daemon[9926]: Joining mDNS multicast group on interface vnet9.IPv6 with address REDACTED. Aug 16 14:17:42 yggdrasil avahi-daemon[9926]: New relevant interface vnet9.IPv6 for mDNS. Aug 16 14:17:42 yggdrasil avahi-daemon[9926]: Registering new address record for REDACTED on vnet9.*. Aug 16 14:17:42 yggdrasil kernel: vfio-pci 0000:00:1a.0: vfio_cap_init: hiding cap 0xa@0x58 I'd really appreciate some input here, especially about something I possibly overlooked regarding the loss of the libvirt.img file. Best regards, buetzel current_vm.xml 8 kB · 0 downloads vm.log 4.08 kB · 0 downloads Dude, i read 2/3 of the post and i am speechless, i didn't even know that you could delete when VMs it is not stopped from unraid settings. And how do you expect mover to move open file? Try open any document in windows and cut/paste or delete it.... The other thing i don't believe that you delete it because inside of it are xmls and nvrams, so after deleting it you would be left without any VMs. As for 1030 passthru it is not anymore dark magic. So the fastest way is to create a new VM without attaching anything else except your virtual img drive. Use q35,ovmf, qlx/vnc gpu ,dont use same name for the vm, pin your cores . Start the vm and connect with VNC client of the unraid. If windows is up and working download DDU and clean nvidia drivers in safe mode. After that turn off the VM. Go to its template and attach 1030 as a second graphics card with its audio.(Don`t mess with the xml before you try the GUI that unraid gave as, go there if you have problem or for otimizing). Don`t put vbios. Start the VM. The card will be there from here on if you have problems with installing drivers you could try with passing vbios and correct xml to put the gpu and audio as one unit. PS: Latest version of unraid just work out of the box... A lot of things that is in this forum and out in the ether are things from the past. > Rule of the thumb first try the normal way that it is presented to you and if it is not working try the hacker way
August 16, 20223 yr Author Hm. Well... did it over the Terminal in the Web GUI. So a simple rm linux command.... it didn't complain. They were gone. The free space wasn't reclaimed though, I had to restart the array for that. As I said, I learned that mover doesn't move anything anyway when switching from cache: prefer to cache: no. So even if I had disabled vm's completely, it probably wouldn't have done that. But I can't be sure in that case. But yeah, I learned that the VMs are gone. By seeing them gone. I don't want to create a new VM - the VM per se is okay. Can't switch from SeaBIOS to OVMF though, since that doesn't work after the VM is created. DDU is an idea, though... gonna go and try that. Also: no second graphics card. Also - is OVMF a good idea on an old system like that? Remember: that Xeon is equivalent to first generation core i7. There is no UEFI support on that... so... things from the past might still be relevant for this hardware since it's also a thing from the past. Of course, the Unraid Version still is 6.10.3 currently, started as 6.9.2 i think. Edit: also, that VM is an activated Windows license, so I kinda want to keep that without hassle. And hassle is what you get, when you have to reactivate it as "changed" hardware for more than once (which I already used). So... no recreating as a new VM with a new vdisk with a different configuration. Edited August 16, 20223 yr by buetzel added Win license info
August 16, 20223 yr Solution Ops my bad, it was fairly long post.....don`t know what happened... So lets try again. You can create Vm without deleting old one, so that you can be sure if the problem is with the xml itself. It is 30 second process like 3-4 clicks. It is recommended to use OVMF for passthru, most ppl had better success with it .( for me works both ways). As for your hardware OVMF and Seabios are emulations and are not dependent on what type bios you use in your real machine. Interestingly most ppl recommend to boot unraid legacy and use ovmf for vms. (for me works both) One of the problem for you which may arise is that does you have uefi bios on the 1030. But it is not so big, because you wouldn't see VM boot process but you will see output on your monitor when windows starts and have installed drivers. As for that, that your windows is installed on seabios, yes it wont start as it is on OVMF. Microsoft had tool for converting "mbr" to "gpt" and i thing there was a command to do it from command prompt. For the license thing it is not a problem you have to just copy 'UUID' number of the old xml > 3th row. And for starters just make another vm template with same version of q35 same vdisk, qlx as 1st gpu and 1030 as second gpu.Start it connect tru vnc and install drivers. And if you afraid that you could mess your vdisk just make a copy of it.... - It will work every update i change chipset version with the new q35 and VM doesn't work and i just recreate it from gui make my edits for uuid and mac address (and multifinctional) and is up. (1 minute). PS: for the DELL h310 i have one and i had the booting hang problem, it is from that, that controller doesn't have uefi rom so if you try to boot with uefi and have boot option rom enabled in bios it hangs.... So use legacy or disable boot option rom in bios. no taping required. PS2: For others if something doesn't work don`t try multiple things at the same time, do it one at time methodical. - it will be faster. Edited August 16, 20223 yr by ilarion
August 17, 20223 yr Author 17 hours ago, ilarion said: For the license thing it is not a problem you have to just copy 'UUID' number of the old xml > 3th row. And for starters just make another vm template with same version of q35 same vdisk, qlx as 1st gpu and 1030 as second gpu.Start it connect tru vnc and install drivers. And if you afraid that you could mess your vdisk just make a copy of it.... - It will work every update i change chipset version with the new q35 and VM doesn't work and i just recreate it from gui make my edits for uuid and mac address (and multifinctional) and is up. (1 minute). This was actually the solution to my problem. Recreating the VM, setting everything as it already was, setting UUID and MAC to what it was before and adding the multifunction part to GPU and audio (audio somehow doesnt work, though - might be a problem of the monitor with speakers I use, I'll try to get that to work somewhen else). VBIOS was in fact not needed. Or maybe it is for the audio... who knows. What I learned from this: backups of VM configuration XMLs bring you only so far. UUID, MAC and that multifunction part are the important things to "backup". Quote PS: for the DELL h310 i have one and i had the booting hang problem, it is from that, that controller doesn't have uefi rom so if you try to boot with uefi and have boot option rom enabled in bios it hangs.... So use legacy or disable boot option rom in bios. no taping required. Yeah... there's still no UEFI in my system, so I can't switch anything to legacy. The system IS legacy. I might have a look at this again after an upgrade to the server in the future, but for now it is running and I don't change running systems if I don't have a reason. After getting this to work yesterday I wanted to add two more cores to the VM because it was a bit slow for my tastes (transition from Ryzen 9 3900X baremetal to 4 cores of that L3426 in a VM for power saving reasons IS a big step down). While it mostly was just switching the configuration back to Form View, adding two cores, saving, editing again in XML mode and redoing the multifunction part, it somehow got an error back in there, threw an error on VM start about PCI.1 missing or something and the GPU passthrough was borked again. Had to redo the VM from the newst XML backup again. I found that very strange and very annoying. But I'm currently writing from inside that VM, so I got it to work again. Whatever. You helped me very much, ilarion, and I thank you for that!
August 17, 20223 yr The UEFI part is that your VM is better on OVMF and that is not in correlation with what type of bios you use bare metal. From what i read OVMF have more optimized communication with real hardware. As for editing problems with the Unraid GUI and XML form. If you want GUI you can use Virt-Manager docker from APPS > it is standard VM linux manager and doesn't bleach your xml when editing with it. AS for power saving 6.11 bring the new amd-pst driver for rizen, but from testing and from reading it is garbage for desktop it cut the performance too much. Edited August 17, 20223 yr by ilarion
August 17, 20223 yr Author Okay, now you completely lost me. I can only suspect that you still didn't get my point, so I'm gonna try again. I'm getting really frustrated right now, so excuse me if this gets too direct. You wrote in your PS about the H310 controller not having an UEFI rom. Which is totally irrelevant to me because the mainboard it is physically slotted into, has only BIOS, NOT UEFI, because of the motherboard's age. So there is no legacy mode in the mainboard's BIOS that I could activate. There is only legacy mode. NO UEFI AT ALL. So i literally CANNOT boot in UEFI mode which then could become problematic for the controller. That controller is what connects the drives in my array to my mainboard. This thing is NOT being passed through to the VM. It's what makes my Unraid server my Unraid server. As far as I researched I still needed that tapemod to get said controller to work with my mainboard at all. It didn't work without the tapemod, it works with the tapemod. It was what made me able to use that controller at all in the first place. It may be that disabling a "boot rom option" in the BIOS (! NOT UEFI !) could be another solution for the problem I had, but I don't care, since it works fine with the tapemod. So: what the fuck has any of this to do with a VM being better on OVMF? Also: it would be REALLY helpful for the readability of your posts, if you would make a new paragraph when changing the topic. I will have a look at Virt-Manager, though. It would be nice if it was a solution for my "VM losing the GPU after some changes to the configuration" problem.
August 17, 20223 yr 1 hour ago, buetzel said: Okay, now you completely lost me. I can only suspect that you still didn't get my point, so I'm gonna try again. I'm getting really frustrated right now, so excuse me if this gets too direct. You wrote in your PS about the H310 controller not having an UEFI rom. Which is totally irrelevant to me because the mainboard it is physically slotted into, has only BIOS, NOT UEFI, because of the motherboard's age. So there is no legacy mode in the mainboard's BIOS that I could activate. There is only legacy mode. NO UEFI AT ALL. So i literally CANNOT boot in UEFI mode which then could become problematic for the controller. That controller is what connects the drives in my array to my mainboard. This thing is NOT being passed through to the VM. It's what makes my Unraid server my Unraid server. As far as I researched I still needed that tapemod to get said controller to work with my mainboard at all. It didn't work without the tapemod, it works with the tapemod. It was what made me able to use that controller at all in the first place. It may be that disabling a "boot rom option" in the BIOS (! NOT UEFI !) could be another solution for the problem I had, but I don't care, since it works fine with the tapemod. So: what the fuck has any of this to do with a VM being better on OVMF? Also: it would be REALLY helpful for the readability of your posts, if you would make a new paragraph when changing the topic. I will have a look at Virt-Manager, though. It would be nice if it was a solution for my "VM losing the GPU after some changes to the configuration" problem. Yes i understand that your mboard doesn't have UEFI and it is only BIOS. I was talking about that from what i read OVMF has better communication than SEABIOS with real hardware overall. > (something that i don't detect...) that is what i have in mind, the thing about raid controller was separate thought. And yep maybe some formatting will express my thoughts accurate. PS: Long i stopped become frustrated on forums because first expressing your thoughts with words especially in writing form without visual contact of any mannerism is difficult thing, and second if it is not your native language.... which english is not mine..
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.