[libvirt-users] Can a VM tell what host it's on?

[Brian K. White]

On 2/2/2012 1:52 PM, Eric Blake wrote:
> On 02/02/2012 11:33 AM, Whit Blauvelt wrote:
>> Is there a way internal to a KVM VM to know which host it's running on?
>
> No.  The ideal hypervisor is one where the guest doesn't even know it is
> running as a virtual machine.  And consider live migration - a guest
> might not be running on the same host over its lifetime.  Therefore,
> there should be nothing that requires a guest to know which host it is
> running on.
>
>>
>> It could send a command via ssh to virsh on a host, and learn from that
>> whether the host currently has it running. But is there something within the
>> VM itself which will reveal this?
>
> Why do you think you need it?  Perhaps if you ask a better question
> about what you are really trying to solve, we can give a better answer.

Why does a process ever need to know it's PPID? Countless unpredictable 
reasons. It's the wrong question to ask in the first place.

It's a thing you should be able to know whenever you find yourself 
needing to know it, without having to first come up with the justifying 
condition. Any given example can probably be solved some other way, 
which just ends up missing the point, because the next situation will 
then need it's own different work around since the work around for the 
first situation probably only handles that particular situation.

I admin vm's and real hosts and I do need to know sometimes whether the 
machine I am on is a vm or not, what kind of vm (lxc, kvm, etc) and what 
real host it's on. For one thing rebooting from within the vm is 
imperfect. For another resource/load reporting from within the vm is 
imperfect, I need to go to the host to look at the host's overall 
resource situation to see if some other vm on the same host is causing a 
problem with ram, cpu, disk i/o, network i/o, maybe the hosts network 
veth bridge or nat routing or iptables need to be looked at etc...
For another, I need the equivalent of the serial console for the vm 
sometimes for install/repair, which means going to the host to run a 
virsh or lxc-console or screen command.

But forget those specific examples. Most of them can sort of be worked 
around via network connection, but that requires working network which 
is not always the case, or a guest OS that even has such a thing as 
networking which is also not always the case.

I see no inherent brokenness with the nvram idea. Even for the live 
migration case, the contents of the fake nvram should be able to change 
along the way, or, maybe a special acpi or bios call that normally 
returns a dynamic response anyways, and so is perfectly ok to return 
value A one minute and value B the next.

-- 
bkw