KVM Guest Detection
Is there a architecture and machine type independent way to detect that one is running inside a KVM guest? I've noticed the following systemd code which does this detection and it seems to be very architecture dependent for KVM:
https://github.com/systemd/systemd/blob/master/src/shared/virt.c
In addition one could grep for strings in the kernel log or CPU types if using QEMU CPU model.
Given the many ways to do this, would it make sense to create a sysfs entry (similar to how Xen does this with /sys/hypervisor/type), so that one can easily tell they are running in a KVM guest?
I can work on a patch, but initial feedback would be helpful.
Thanks,
--chris j arges
Paolo Bonzini
maintainerQuoted 5 lines · Chris J Arges
Is there a architecture and machine type independent way to detect that one is running inside a KVM guest? I've noticed the following systemd code which does this detection and it seems to be very architecture dependent for KVM:
https://github.com/systemd/systemd/blob/master/src/shared/virt.c
No, there is no other way. In fact on some architectures (PPC and s390 for example) KVM implements the same paravirtualized architecture that is used by proprietary hypervisors, and should be indistiguishable from them.
Quoted 2 lines
In addition one could grep for strings in the kernel log or CPU types if using QEMU CPU model.
KVM can also be used without QEMU though. Also, not all architectures support custom model names the way x86 has them in /proc/cpuinfo.
Quoted 3 lines
Given the many ways to do this, would it make sense to create a sysfs entry (similar to how Xen does this with
/sys/hypervisor/type), so that one can easily tell they are running in a KVM guest?
Why do you need that? If you are disabling something if you are on a virtualized platform, then that is most of the time (and I am not saying always only because of things like microcode.service) wrong.
In order of likelihood:
1) you are working around a bug in KVM, and the developers won't know;
2) you are sweeping under the carpet a bug in your program (e.g. in the service that you're writing a unit file for);
3) your assumptions are flawed. For example the (now removed) readahead daemon in systemd was disabled under virtualization... except that most of the time production virtual machines are run with O_DIRECT so the benefit from readahead is the same as on bare metal.
Paolo
Quoted 9 lines
I can work on a patch, but initial feedback would be helpful.
Thanks,
--chris j arges
--
To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 14 lines · Paolo Bonzini
Quoted 5 lines · Chris J Arges
Is there a architecture and machine type independent way to detect that one is running inside a KVM guest? I've noticed the following systemd code which does this detection and it seems to be very architecture dependent for KVM:
https://github.com/systemd/systemd/blob/master/src/shared/virt.cNo, there is no other way. In fact on some architectures (PPC and s390 for example) KVM implements the same paravirtualized architecture that is used by proprietary hypervisors, and should be indistiguishable from them.
Quoted 6 lines
Quoted 2 lines
In addition one could grep for strings in the kernel log or CPU types if using QEMU CPU model.
KVM can also be used without QEMU though. Also, not all architectures support custom model names the way x86 has them in
/proc/cpuinfo.
Yes, I understand.
Quoted 8 lines
Quoted 3 lines
Given the many ways to do this, would it make sense to create a sysfs entry (similar to how Xen does this with
/sys/hypervisor/type), so that one can easily tell they are running in a KVM guest?Why do you need that? If you are disabling something if you are on a virtualized platform, then that is most of the time (and I am not saying always only because of things like microcode.service) wrong.
A use-case is disabling KSM if running inside an L1 guest. This would be changed to ensure better defaults rather than work around issues. The qemu-kvm packaging in Ubuntu enables KSM by default if you install the package. If we are attempting to do things like nested guests, then it may make sense to disable KSM when installing qemu-kvm in the L1 guest. Another solution to this issue is to not enable KSM in the package and let the user configure this when necessary.
Quoted 7 lines
In order of likelihood:
1) you are working around a bug in KVM, and the developers won't know;
2) you are sweeping under the carpet a bug in your program (e.g. in the service that you're writing a unit file for);
Quoted 7 lines
3) your assumptions are flawed. For example the (now removed) readahead daemon in systemd was disabled under virtualization... except that most of the time production virtual machines are run with
O_DIRECTso the benefit from readahead is the same as on bare metal.Paolo
Thanks for the response. My hope was that there could be a more uniform way of exposing the fact that we are running on a hypervisor for userspace programs.
--chris
Quoted 10 lines
Quoted 9 lines
I can work on a patch, but initial feedback would be helpful.
Thanks,
--chris j arges
--
To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Paolo Bonzini
maintainerQuoted 5 lines · Chris J Arges
Quoted 3 lines
Why do you need that? If you are disabling something if you are on a virtualized platform, then that is most of the time (and I am not saying always only because of things like microcode.service) wrong.
A use-case is disabling KSM if running inside an L1 guest.
But even that might not make sense if KSM is disable in L0, I think.
BTW, I think Fedora has disabled KSM by default.
Paolo
Quoted 7 lines
This would be
changed to ensure better defaults rather than work around issues. The qemu-kvm packaging in Ubuntu enables KSM by default if you install the package. If we are attempting to do things like nested guests, then it may make sense to disable KSM when installing qemu-kvm in the L1 guest. Another solution to this issue is to not enable KSM in the package and let the user configure this when necessary.