8:15 p.m.
On Thu, Feb 2, 2012 at 2:08 PM, Eric Blake <eblake(a)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(a)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
8:30 p.m.
New subject: [libvirt-users] Can a VM tell what host it's on?
On 2/2/2012 2:15 PM, Paul Lussier wrote:
On Thu, Feb 2, 2012 at 2:08 PM, Eric Blake<eblake(a)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(a)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
10:54 p.m.
New subject: [libvirt-users] Can a VM tell what host it's on?
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
6:28 p.m.
New subject: [libvirt-users] Can a VM tell what host it's on?
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
4611
days inactive
4612
days old
3 comments
3 participants
participants (3)
-
Brian K. White -
Paul Lussier -
Whit Blauvelt