KVM Guest Detection

KVM Guest Detection

[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

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

Re: KVM Guest Detection

[Paolo Bonzini]

On 06/02/2015 21:08, Chris J Arges wrote:
> 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.

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

> 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

> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: KVM Guest Detection

[Chris J Arges]

On 02/09/2015 07:26 AM, Paolo Bonzini wrote:
> 
> 
> On 06/02/2015 21:08, Chris J Arges wrote:
>> 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.
> 
>> 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.

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

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

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

>> 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 majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> 

Re: KVM Guest Detection

[Paolo Bonzini]

On 09/02/2015 15:37, Chris J Arges wrote:
> > 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

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

KVM Guest detection

[jd]

Hi

Is there a way to detect if a particular machine is a VM running on KVM hypervisor or not. i.e from within a guest can one figure out if it is running on top of a hypervisor and not physical machine ? [For both Linux guests and Windows guests ]

/Jd



      

Re: KVM Guest detection

[David Mair]

jd wrote:
> Hi
> 
> Is there a way to detect if a particular machine is a VM running on KVM
> hypervisor or not. i.e from within a guest can one figure out if it is running on
> top of a hypervisor and not physical machine ? [For both Linux guests and Windows
> guests ]

You can generally infer the presence of qemu hosting based on the device name for 
certain devices. On a Linux guest for example:

# hwinfo --all | grep -i qemu

AFAIK, it can't tell you if it is a kvm accelerated guest though.

FWIW, it isn't really an interface to qemu or kvm so you probably can't guarantee it 
will continue to work or that the device strings can't be masked by something else 
on the host or guest. The same method is often suggested as a cheap (sleazy) way of 
detecting VMware hosting.

-- 
David.

Re: KVM Guest detection

[Anthony Liguori]

jd wrote:
> Hi
>
> Is there a way to detect if a particular machine is a VM running on KVM hypervisor or not. i.e from within a guest can one figure out if it is running on top of a hypervisor and not physical machine ? [For both Linux guests and Windows guests ]
>   

The preferred way of doing this is checking CPUID leaf 0x4000 0000 for 
the signature "KVMKVMKVM".

Most hypervisors (KVM, Xen, VMware, and Hyper-V) are adopting this as 
the preferred detection mechanism.

Regards,

Anthony Liguori

> /Jd
>
>
>
>       
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>   

Re: KVM Guest detection

[jd]

Thanks. Good to know that most hypervisors are using this mechanism.

/Jd

--- On Wed, 8/13/08, Anthony Liguori <anthony@codemonkey.ws> wrote:

> From: Anthony Liguori <anthony@codemonkey.ws>
> Subject: Re: KVM  Guest detection
> To: jdsw2002@yahoo.com
> Cc: "KVM List" <kvm@vger.kernel.org>
> Date: Wednesday, August 13, 2008, 11:59 AM
> jd wrote:
> > Hi
> >
> > Is there a way to detect if a particular machine is a
> VM running on KVM hypervisor or not. i.e from within a guest
> can one figure out if it is running on top of a hypervisor
> and not physical machine ? [For both Linux guests and
> Windows guests ]
> >   
> 
> The preferred way of doing this is checking CPUID leaf
> 0x4000 0000 for 
> the signature "KVMKVMKVM".
> 
> Most hypervisors (KVM, Xen, VMware, and Hyper-V) are
> adopting this as 
> the preferred detection mechanism.
> 
> Regards,
> 
> Anthony Liguori
> 
> > /Jd
> >
> >
> >
> >       
> > --
> > To unsubscribe from this list: send the line
> "unsubscribe kvm" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at 
> http://vger.kernel.org/majordomo-info.html
> >   
> 
> --
> To unsubscribe from this list: send the line
> "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at 
> http://vger.kernel.org/majordomo-info.html