Bug 19308

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.

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...

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 => RESOLVED
Resolution: (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.