On 2/2/2012 2:15 PM, Paul Lussier wrote:
On Thu, Feb 2, 2012 at 2:08 PM, Eric Blake<eblake@xxxxxxxxxx> 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@xxxxxxxxxx> 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
