Re: [libvirt-users] Can a VM tell what host it's on?
On Thu, Feb 2, 2012 at 2:08 PM, Eric Blake <eblake@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@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
On 2/2/2012 2:15 PM, Paul Lussier wrote:
On Thu, Feb 2, 2012 at 2:08 PM, Eric Blake<eblake@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@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
On Thu, Feb 02, 2012 at 02:30:45PM -0500, Brian K. White wrote:
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.
At the level of the VM, I'd certainly hope going forward that there's no assumption of a "central management app" at all. The beauty of a UNIX component-tool architecture is that the parts can be recombined in novel ways for very different projects. A VM is going to be a more generally-useful part if it has access to contextual information re: where it's running. And there are going to be more ways to assemble the local architecture around the VM if the tools both outside and potentially inside the VM make no assumptions about being in a context where a "central management app" exists at all. They shouldn't depend on that assumption. The whole Internet is arguably based on an ideal of distributed management rather than central management. Capitalism is too, for that matter. While it's quite understandable that a particular Linux distro will want to feature a polished, one-size-fits-all cluster stack - and it's wonderful that the market for such a solution can fund and encourage the development of the underlying pieces - in the *nix world it should be expected and even encouraged that those pieces will be refitted into contexts of quite different design. As such, the components should have flags and hooks available to them which are not part of the spec of the one-size-fits-all cluster stack, to facilitate their reuse in novel contexts. Sure, a lot of that reuse will be rinky-dink stuff of poor design. But some of it will blossum into stuff that can feed back into improving the models used by the main-stream distros. Gluster is a good example, in a way. It was created by people who weren't "real" file system engineers, so hadn't received the conventional wisdom on the "right" way to do it. They did it "wrong." Yet RH just paid big bucks for it, warts and all, because it turns out to be smarter than the file system end of the current RH cluster stack, at least in potential. And RH's said some very positive stuff about making sure that Gluster's even more open to diverse use and development than it was under its old owner. That seems like the right philosophy for all this stuff. Best, Whit
On 2/2/2012 4:54 PM, Whit Blauvelt wrote:
On Thu, Feb 02, 2012 at 02:30:45PM -0500, Brian K. White wrote:
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.
A VM is going to be a more generally-useful part if it has access to contextual information
It needs to be admin configurable of course, because there are also times when you specifically want to disable or spoof all such context info. The day the fake bios/acpi/efi info becomes standard is the day microsoft and apple start looking for it to disable your windows/osx install, so while one guy needs to supply this info, another guy specifically needs to avoid supplying this same info. -- bkw
participants (3)
-
Brian K. White -
Paul Lussier -
Whit Blauvelt