pants

Members
  • Posts

    7
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

pants's Achievements

Newbie

Newbie (1/14)

2

Reputation

  1. I was able to get virtio-fs working on Unraid 6.9.2. See this thread for details:
  2. I was able to get virtio-fs working on Unraid 6.9.2. See this thread for details:
  3. After building a custom QEMU 5.2 slackpkg and implementing the workaround described above, I was also able to use virtiofs to pass-through directories on my Unraid host to my VMs. However, determining the correct compilation options for QEMU was a time-consuming, iterative process. I reached out to @limetech and they confirmed that QEMU 6.0 will be included in Unraid 6.10 which is coming "soon". For future readers of this thread, if you are not in immediate need of this functionality, I would recommend waiting for Unraid 6.10. If you cannot wait I have a few notes that may help you get this working. Use a "full Slackware current" VM as your build machine. The Slackware current kernel is slightly ahead of Unraid 6.9.2 at the time of this writing (5.10.39 vs 5.10.28) but the QEMU package it produces is compatible. I downloaded my Slackware current install ISO from AlienBOB here. The QEMU 5.2.0 source code is available at https://www.qemu.org/download/#source (direct download link here). The QEMU 5.2.0 build scripts have a bug which results in incorrect options being passed to the linker. In order to build QEMU 5.2.0, you will need to apply a patch which can be found here (this may be resolved in QEMU 6.0). You might need to download and install a few additional slackpkgs onto your build vm to compile QEMU. I needed libseccomp-2.3.2, spice, and spice-protocol. The spice packages were not available on pkgs.org so I rebuilt them from source on my build machine (Note: these packages are already available on Unraid 6.9.2) A QEMU slackbuild script can be found on slackbuilds.org here. The QEMU build args that worked for me are included below. I also set the environment variables VERSION=5.2.0 and TARGETS="x86_64-softmmu,x86_64-linux-user". Additionally, I commented out the line "make config-all-devices.mak config-all-disas.mak" and removed a few nonexistent files from the cp command near the end of the build script. CXXFLAGS="$SLKCFLAGS" \ ./configure \ --prefix=/usr \ --libdir=/usr/lib${LIBDIRSUFFIX} \ --sysconfdir=/etc \ --localstatedir=/var \ --docdir=/usr/doc/$PRGNAM-$VERSION \ --enable-system \ --enable-kvm \ --disable-debug-info \ --enable-virtiofsd \ --enable-virtfs \ --enable-jemalloc \ --enable-nettle \ --enable-vnc \ --enable-seccomp \ --enable-spice \ --enable-libusb \ --audio-drv-list=" " \ --disable-gtk \ --disable-snappy \ --disable-libdaxctl \ --disable-sdl \ --disable-sdl-image \ --disable-virglrenderer \ --disable-vde \ --disable-vte \ --disable-opengl \ $with_vnc \ $targets The procedure above produces a QEMU 5.2.0 slackpkg which can be installed on Unraid. One final note: Unraid 6.9.2 includes glibc-2.32 and QEMU 5.2.0 depends on glibc-2.33; a slackpkg for glibc-2.33 can be obtained here. It's important to emphasize that I do not know the compilation options used to build QEMU for the official Unraid distribution so it's very possible that the QEMU package produced by the procedure above is missing some features that are present in the pre-installed QEMU. As such, I would caution against taking this route and suggest waiting for Unraid 6.10 unless you are truly in dire need. In the meantime I hope this helps others who may find themselves in the same situation that I was in!
  4. I am also interested in this functionality. I would like to use it to configure the WebUI for my organizr docker container to use my server's hostname rather than its IP. This is important because all of the tabs in my organizr instance are referred to by hostname and if the FQDN of the organizr instance does not match the FQDN of the pages which are loaded within the iframes of each tab logins are redirected indefinitely making it impossible to login. Right now, I have hardcoded my server's hostname into the WebUI field but it would be more robust to refer to the hostname indirectly via a [HOST] or [FQDN] variable.
  5. I recently ran into this problem on a motherboard with no spare USB controllers or free PCIe slots so buying an expansion card or passing an existing controller through to the VM was not an option. In my case, I noticed that as long as the Bluetooth dongle was kept active all connected devices would remain attached and usable. I "solved" the issue in the Windows VM by running a Bluetooth scanning program which would constantly keep the Bluetooth connection active. I configured the scanner to run in the background as a Windows service which is kicked off on the login screen so that I am able to use my bluetooth keyboard and mouse to login to the VM. This is the bluetooth scanning software I am using: https://www.nirsoft.net/utils/bluetooth_log_view.html This solution was inspired by the following reddit post: https://www.reddit.com/r/VFIO/comments/hiwc5u/onboard_usb_bluetooth_passed_to_windows_10_guest/ For me, this solution is acceptable but suboptimal. I would prefer to find some way of fixing the underlying bluetooth-specific disconnect problems that occur when directly passing the dongle through to the VM. I have tried many approaches but am still hopeful there may be some VFIO options that could help. Symptoms of the original problem In my case, I also noticed that the bluetooth connection stopped responding to new events after a few seconds of inactivity but any existing events would still be processed. More specifically, on my bluetooth keyboard if I pressed and held down a key then a "key down event" would be sent and text would appear on screen but if I failed to lift my finger within ~3seconds the corresponding "key up event" would not be received and the VM would behave as though I was still pressing the key until I turned off bluetooth entirely.
  6. I recently ran into this problem on a motherboard with no spare USB controllers or free PCIe slots so buying an expansion card or passing an existing controller through to the VM was not an option. In my case, I noticed that as long as the Bluetooth dongle was kept active all connected devices would remain attached and usable. I "solved" the issue in the Windows VM by running a Bluetooth scanning program which would constantly keep the Bluetooth connection active. I configured the scanner to run in the background as a Windows service which is kicked off on the login screen so that I am able to use my bluetooth keyboard and mouse to login to the VM. This is the bluetooth scanning software I am using: https://www.nirsoft.net/utils/bluetooth_log_view.html This solution was inspired by the following reddit post: https://www.reddit.com/r/VFIO/comments/hiwc5u/onboard_usb_bluetooth_passed_to_windows_10_guest/ For me, this solution is acceptable but suboptimal. I would prefer to find some way of fixing the underlying bluetooth-specific disconnect problems that occur when directly passing the dongle through to the VM. I have tried many approaches but am still hopeful there may be some VFIO options that could help. Symptoms of the original problem In my case, I also noticed that the bluetooth connection stopped responding to new events after a few seconds of inactivity but any existing events would still be processed. More specifically, on my bluetooth keyboard if I pressed and held down a key then a "key down event" would be sent and text would appear on screen but if I failed to lift my finger within ~3seconds the corresponding "key up event" would not be received and the VM would behave as though I was still pressing the key until I turned off bluetooth entirely.