June 26, 20206 yr If I understand correctly, unraid uses KVM hypervisor, I noticed that systemd-detect-virt under Linux VMs is detecting the hypervisor as QEMU and not as KVM. Looking at the VM templates the domain type is KVM, I run into a service which was designed to run only under KVM environment and also noticed that HassOS (Home assistant operating system) which is based on Alpine Linux is running the qemu guest agent only if system is detected as KVM. I wonder if someone has some information about it and maybe it is possible to let the OS detect this as KVM by changing the VM template.
June 27, 20206 yr You might find this section of the online documentation to be useful in understanding the technology stack behind the Unraid VM support. Whether it will help you I am not sure. However as you will see QEMU is not a hypervisor but a resource managing component that runs under KVM.
June 27, 20206 yr Author 32 minutes ago, itimpi said: You might find this section of the online documentation to be useful in understanding the technology stack behind the Unraid VM support. Thanks for the link, but it still doesn't explain why under unraid VMs are detecting QEMU hypervisor and not KVM. 32 minutes ago, itimpi said: However as you will see QEMU is not a hypervisor but a resource managing component that runs under KVM. QEMU can work in two modes: 1. as an emulator under KVM only responsible for the emulation of devices (unraid usage). 2. a standalone type 2 hypervisor - performing software virtualization. Linux machines has an option to detect the type of virtualization used while it is not critical they can detect if they run under QEMU as an hypervisor or KVM. I encountered the usage of KVM as a condition in a service in few places, since QEMU is mostly never used as hypervisor most implementations only check for KVM hypervisor. I find the following two articles explaining the differences: https://www.quora.com/Virtualization-What-is-the-difference-between-KVM-and-QEMU https://www.packetflow.co.uk/what-is-the-difference-between-qemu-and-kvm/ I'm going to setup a KVM under Fedora to understand if there are any differences.
June 28, 20206 yr Author I have installed Fedora Linux on another machine and under it installed same OS (debian in this case, but it does not matter). On the VM running under Unraid the output of systemd-detect-virt is "qemu", on the VM running under Fedora it is "kvm" Unraid "virsh version": Compiled against library: libvirt 5.10.0 Using library: libvirt 5.10.0 Using API: QEMU 5.10.0 Running hypervisor: QEMU 4.2.0 Fedora "virsh version": Compiled against library: libvirt 6.1.0 Using library: libvirt 6.1.0 Using API: QEMU 6.1.0 Running hypervisor: QEMU 4.2.0 I also compared the VMs XML files, they are almost identical, minor changes.
December 19, 20205 yr @thecode did you find a solution to this, i am also having trouble getting Hassos to enable QEMU guest agent and i suspect it is down to Unraid hypervisor identifying as QEMU rather than KVM.
December 19, 20205 yr Author 11 hours ago, bung said: @thecode did you find a solution to this, i am also having trouble getting Hassos to enable QEMU guest agent and i suspect it is down to Unraid hypervisor identifying as QEMU rather than KVM. For HassOS I submitted a poll request to support QEMU hypervisors, so that it also loads the guest agent for them. Since HassOS 4.11 (dated 3-Jul-2020) you should not have any problem with this (although the OS does not detect UNRAID as KVM hypervisor). When the VM is running, edit the VM in in UNRAID and view as XML, look for this part: <channel type='unix'> <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/HassOS/org.qemu.guest_agent.0'/> <target type='virtio' name='org.qemu.guest_agent.0' state='connected'/> <alias name='channel0'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> Make state=connected. I can run live snapshots without stopping the machine after my change was merged. Edited December 19, 20205 yr by thecode Fix path
Archived
This topic is now archived and is closed to further replies.