| Summary: | systemd-detect-virt and hostnamectl fail to detect Xen PV | ||
|---|---|---|---|
| Product: | systemd | Reporter: | Andy Melnikov <andy.melnikov> |
| Component: | general | Assignee: | systemd-bugs |
| Status: | RESOLVED FIXED | QA Contact: | systemd-bugs |
| Severity: | minor | ||
| Priority: | medium | ||
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
Hmm, the current code looks for the CPUID virtualization leaf and for the DMI vendor information. Are you suggesting that detecting Xen with that is not possible anymore? http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/virt.c#n33 Supporting /sys/hypervisor/type sounds like a good thing, but if the CPUID stuff/DMI stuff could be made work then I'd prefer that. Could you paste "grep . /sys/class/dmi/id/*" on your xen guest? *** Bug 61490 has been marked as a duplicate of this bug. *** I'm only suggesting that Xen is not detected on my 3 servers from different providers. There are many kinds of Xen: HVM, PV and PVHVM. I have PV, so the existing detection may still work with HVM and PVHVM flavours. /sys/class/dmi folder doesn't exist. /sys/class contains the following folders, most of them empty: backlight/ firmware/ leds/ power_supply/ vtconsole/ bdi/ gpio/ mem/ rtc/ watchdog/ block/ graphics/ misc/ thermal/ bsg/ hwmon/ net/ tty/ dma/ input/ pci_bus/ vc/ dmidecode says the following: # No SMBIOS nor DMI entry point found, sorry. /proc/cpuinfo contains the following flags: flags : fpu de tsc msr pae cx8 sep cmov pat clflush mmx fxsr sse sse2 ss ht nx constant_tsc nonstop_tsc pni pclmulqdq ssse3 sse4_1 sse4_2 popcnt aes hypervisor Not sure how these translate to CPUID flags but note the hypervisor flag. CONFIG_DMIID=y in the kernel probably makes the stuff work for you, without additional systemd changes. DMI data is used by other parts of the system too, and we kind of rely on that being available. CONFIG_DMIID=y is set in kernel config. It seems Xen lacks DMI support in PV flavour: --- https://bugzilla.redhat.com/show_bug.cgi?id=210295 In addition if Xen is every fixed to emulate DMI blocks in paravirt as it does in full virt then such a check would be wrong. --- I infer that Xen PV (paravirtualized), unlike Xen HVM (hardware virtual machine), doesn't emulate DMI blocks yet. git will now check /sys/hypervisor/type. I didn't actually test this against a real Xen, but I am quite sure this works now. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
When running inside a Xen PV virtual machine, systemd-detect-virt displays "none" and hostnamectl doesn't display "Virtualization" line: [root@foo ~]# systemd-detect-virt none [root@foo ~]# hostnamectl Static hostname: foo Pretty hostname: foo Icon name: computer Chassis: n/a Machine ID: baad787b99df4cc7a8ff801dfd96c735 Boot ID: baad822deca749a496ee91406681ebd6 Operating System: Foo Linux Kernel: Linux 3.x.x-foo Architecture: i686 Compare with running in vmware: [root@bar ~]# systemd-detect-virt vmware [root@bar ~]# hostnamectl Static hostname: bar Transient hostname: localhost Pretty hostname: n/a Icon name: computer-vm Chassis: vm Machine ID: d2016ade07564ecfb465fa009630602e Boot ID: 09105e4eea624316a8eda284739dcc45 Virtualization: vmware Operating System: Foo Linux Kernel: Linux 3.x.x-foo Architecture: i686 One way to detect is to look for presense of /sys/hypervisor/type: [root@zorro ~]# cat /sys/hypervisor/type xen Or /proc/xen/ folder.