Description of problem: When installing Mageia 6 on a KVM host, it does not automatically add 'qemu-guest-agent', 'spice-vdagent', and 'spice-webdavd' to the installation to support the virtual hardware platform. How reproducible: Always Steps to Reproduce: 1. Create a VM on a KVM host (I used an oVirt system and a Fedora 24 system as KVM hosts) 2. Install Mageia 6 3. Check post-install for the packages noted in the description to be installed and that the KVM integration is working. They will not be installed, and things like the mouse pointer will be jittery and the UI will be laggy.
As an aside, systemd-detect-virt(1) indicates that when KVM/Xen acceleration is used, it'll report "kvm" or "xen" instead of "qemu". We currently have logic for handling "qemu", but not the other two.
CC: (none) => thierry.vignaudAssignee: bugsquad => mageiatools
KVM is easy to fix. For xen it's harder as systemd-detect-virt doesn't make a difference between a domU hvm and pv, it detects both separately but return the same value. From some reading there are a few ways to decide: HVM (is_qemu should return true): - cpuid is XenVMMXenVMM - there is DMI and product name is "HVM domU" PV (is_qemu should return false): - /proc/xen/capabilities exists, but that relies on the xenfs being mounted on /proc/xen - /sys/hypervisor/type exists and contains xen
CC: (none) => pterjan
So I think we want to return true if: virt_technology() eq 'qemu' || virt_technology() eq 'kvm' || (virt_technology() eq 'xen' && dmidecode_category('System Information')->{'Product Name'} eq 'HVM domU') Maybe it would be more reliable to just detect whatever device the agent makes use of?
AFAIC, systemd-detect-virt always returned "qemu" on a FC2[34] host... (using virt-manager) If some other KVM wrappers make it returns "kvm", we can indeed handle that...
Summary: DrakX not properly detecting KVM/Xen and installing the guest agents => DrakX not properly detecting KVM/Xen and installing the guest agents in some cases (ovirt)
Summary: DrakX not properly detecting KVM/Xen and installing the guest agents in some cases (ovirt) => DrakX not properly detecting KVM/Xen and installing the guest agents in some cases (eg: ovirt)
commit 304762e02f2eded90b1718303bb164e12024574e Author: Thierry Vignaud <thierry.vignaud@...> Date: Fri Sep 9 14:19:13 2016 +0200 detect ovirt too (mga#19308) it looks like not all KVM GUIes result in the same result with systemd-detect-virt let's handle both cases --- Commit Link: http://gitweb.mageia.org/software/drakx/commit/?id=304762e02f2eded90b1718303bb164e12024574e
(In reply to Pascal Terjan from comment #2) (In reply to Pascal Terjan from comment #3) No. We don't want to bring virt detection details back into detect_devices. Please suggest a patch against systemd so that it can return a different value for Xen and try to get it merged upstream On second looks, it looks like this is not needed and that the man page is wrong instead: According to https://github.com/systemd/systemd/issues/2625, dom0 is treated as a hypervisor and "xen" should be returned only for domU
Status: NEW => RESOLVEDResolution: (none) => FIXED
And please, next time do not report a false issue with Xen unless you've tested it. Thanks again for the ovirt test. BTW we got testers for Vmware too but if someone could test with hyper-v, that would be nice
Thierry, I first discovered the issue using KVM on Fedora 24 host (controlled via virt-manager), it most definitely reports "kvm" there. If I switch the VM to emulator mode, it'll go back to calling it "qemu".
Some of my older VMs from before I upgraded to F24 also have exactly the same problem, which makes me believe the issue existed with F23 KVM hosts, too.
(In reply to Thierry Vignaud from comment #6) > (In reply to Pascal Terjan from comment #2) > (In reply to Pascal Terjan from comment #3) > > No. > We don't want to bring virt detection details back into detect_devices. > Please suggest a patch against systemd so that it can return a different > value for Xen and try to get it merged upstream Yes it would be nice to have different values for HVM and PV but I doubt changing the values will be accepted as people may already rely on == xen :( > On second looks, it looks like this is not needed and that the man page is > wrong instead: > According to https://github.com/systemd/systemd/issues/2625, dom0 is treated > as a hypervisor and "xen" should be returned only for domU That bug is about the PV case we don't care about for this problem and that doesn't help in the HVM case.