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

[Brian K. White]

On 2/2/2012 2:15 PM, Paul Lussier wrote:
> On Thu, Feb 2, 2012 at 2:08 PM, Eric Blake<eblake at redhat.com>  wrote:
>> Did you mean for this to go to the list?
>
> Yes, sorry :)
>
>> On 02/02/2012 12:04 PM, Paul Lussier wrote:
>>> On Thu, Feb 2, 2012 at 1:52 PM, Eric Blake<eblake at redhat.com>  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.
>>>
>>>  From a system administration perspective, though, it's imperative to
>>> know what physical hosts your VMs are running on.  Perhaps the VM
>>> itself doesn't know, but the sysadmin should be able to have some
>>> means of figuring this out in a dynamic manner, not simply by "keeping
>>> track" of where VMs are deployed.
>>
>> Yes, but that's a different question.  It's not the guests' job to know
>> which host they are running on, rather, it's the management app _outside
>> of the guests_ that knows which hosts are running which guests.
>
> What do you mean by "management app", virt-manager, or something else ?
>
>>>> 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.
>>>
>>> Asset tracking, physical host trouble-shooting, etc.  If I'm running
>>> an environment with 2K physical systems, each of which are running 20+
>>> VMs, and someone reports a problem with  vm-23475, it would be really
>>> nice to know that I can ask that VM where it is on my network and on
>>> what physical hosts.  Especially if that VM has been around a while
>>> and possibly migrated to/from several physical systems.
>>
>> That's more a question you should be directing to your management app,
>> not to your guest.  Your management app should know which host is
>> currently running vm-23475; you shouldn't have to directly query
>> vm-23475 itself (besides, if you treat guests as untrusted code, you
>> wouldn't want to rely on any answer vm-23475 gave you in the first place).
>
> While I agree with you in principle, my impression is that people are
> not treating guests as untrusted code, but rather, almost exactly like
> physical hosts.  Perhaps I haven't had the luxury of being in a
> virtual environment where people are doing things the way they were
> intended :)
> --
> Paul

I certainly don't have any such thing as a central management app that 
knows what all the vm's are on all the hosts.

I don't even have any such thing as a management app hat knows what all 
the vm's are on ONE host, because lxc-info doesn't know about 
virtualbox, and virtualbox doesn't know about qemu, etc etc...

I don't even know how such a thing could even exist since it would have 
to involve the built in cooperation of all the different vm technologies 
from chroot to vmware, and/or require some sort of universal agent that 
runs in the guests which is flatly impossible, (you're really going to 
embed a network capable vm management agent into grub? memtest86? 
freedos? let alone all the full os's that just happen to be old.)

There are plenty of bios and acpi calls that return dynamic results 
and/or access hardware which returns dynamic results so I don't believe 
the live migration issue is a problem, you could just 
emulate/hijack/extend/create one of those.

-- 
bkw