dakota_654

I guess I answered my own question once I got a chance to try it out; I basically made the following change to make the network node to appear as such, and the VM was able to start and work with networking as expected! <model type='virtio-net'/> to <model type='e1000-82545em'/> <interface type='bridge'> <mac address='52:54:00:53:be:20'/> <source bridge='br0'/> <target dev='vnet1'/> <model type='e1000-82545em'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </interface>

Hello, is there a known way where I can emulate or otherwise pass networking into a VM in any ways other than the out of the box virtio method? I have a use case where I have a crypto mining OS (Rave OS/Hive OS) running on my primary GPU when I am not using it for gaming/ect, the problem being that the out-of-the-box version of those operating system does not have any kernel/driver support for virtio and cannot leverage the standard VM networking. My current "ugly" workaround for this is that I have a USB ethernet dongle in which I pass thru to the VM (as a single USB device) and is able to work in that manner just fine. I would rather not tamper with the mining OS as any changes I make would be subject to be blown away by any of its OS updates that come thru, ideally there could be something I could leverage in KVM to give it the more "typical hardware" network interface that the OS is expecting. Odd thought I had as I typed this out, is it odd that virtio networking cant run thru these, yet the USB device passthru, presumably thru some manner of virtio, is able to work? Another technique that strikes me as worth a shot is how the adapter type is manually tweaked to something the VM config UI doesn't offer in the XML in SpaceInvaders MacInaBox videos for OSX compatibility, I'll have to try that tonight Thanks for the read/consideration

Actually had been booting bios in legacy mode this whole time, but spurred me to try out UEFI boot, not much luck getting ANY graphics boot though; there is a line in the attached dmesg output that kept repeating while attempting this. So it would appear vendor-reset is operating as expected; I attached some output for that in an attached file if you have any final thoughts there, otherwise I'll take further action to the vendor-reset github, looks like the the kernel helper implementation works just fine so won't clutter this thread with any more on this tangent. Thanks all for the replies and suggestions (+++ to ich777 for this and a number of the other great dockers you have thrown to the community) powercolor_vega_56_vendor-reset_20210111.txt

Got that line out of there, thank you both for the insight; Didn't do the trick though. I've had been using an Ubuntu VM mostly, seems like I've had the most luck getting things to boot (initially with my AMD card) and consistently with my Nvidia card Critical thing I forgot to mention in my last post is that I receive this same behavior even with the vanilla Unraid kernels and no vendor-reset things in play at all, so I'm not 100% certain if the reset code is being triggered in my setup; is there any logs or otherwise diagnostic I can dig up that would indicate or be helpful with what is going on?

Hi all, hoping for a sanity check on the kernel driver docker; I'm attempting to use it to build a custom kernel with the addition of vendor-reset and hopefully get rid of the dreaded vfio reset issue on my AMD GPU; I started into this after I found the treyf711 youtube video a couple of other posters had mentioned and then this kernel-building docker to find that the docker in its current state has a simple option to apply the vendor reset (good stuff), now I'm able to run the docker and get the files (leaving all default settings other than vendor_reset=true). Everything seems to work fine except the the reset issue persists. Hopefully I didn't miss a step, but this seems to be about all that is needed. Quick info/steps to get the seemingly relevant info out there: Ryzen 3950x -> Asus X470 Crosshair VII Powercolor AMD Vega 56 Unraid 3.9.0-rc2 As I was troubleshooting this last night, I noticed my GPU was particularly hot to the touch as I replaced with a nvidia gpu to further test; maybe the kernel module is not playing nice with it? Run plugin, all defaults aside from vendor_reset=true Patiently wait, I get the 'ALLDONE please copy..' a short wait later Use Unraid root terminal window to copy the newly created output bz* files to /boot; timestamps update, all seems good nano edit /boot/config/go and add in 'modprobe vendor-reset' line reboot run 'lsmod | grep vendor' as a verification; line shows up (perhaps I'm unfamiliar with the kernel bootup routine but is it expected that this also shows up for me when rebooted WITHOUT 'modprobe vendor-reset'?) Start VM with the GPU, boots as expected, shut it down Start up that same vm again, I see my passed thru keyboard and mouse flash colors indicating the startup is rolling, but my display will never load the graphical output. Need to force stop VM As generally known, the full bare metal restart will get the VM working (once), any subsequent VM boots will not have display out from the GPU Thank you for time and consideration