[libvirt-users] Can a VM tell what host it's on?
Is there a way internal to a KVM VM to know which host it's 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? Thanks, Whit
On 02/02/2012 01:33 PM, Whit Blauvelt wrote:
Is there a way internal to a KVM VM to know which host it's 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?
Thanks, Whit
I was under the impression that without some creative uses of DMI, this could not be done. -- bk
On 2/2/2012 1:41 PM, Bryan Kearney wrote:
On 02/02/2012 01:33 PM, Whit Blauvelt wrote:
Is there a way internal to a KVM VM to know which host it's 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?
Thanks, Whit
I was under the impression that without some creative uses of DMI, this could not be done.
-- bk
No idea what is or is not in the code in this regard, but as a purely conceptual thought, why couldn't the host elect to put a small amount of info, whatever the admin wishes, into the fake nvram presented to the vm for it's bios? -- bkw
On 02/02/2012 11:54 AM, Brian K. White wrote:
On 2/2/2012 1:41 PM, Bryan Kearney wrote:
On 02/02/2012 01:33 PM, Whit Blauvelt wrote:
Is there a way internal to a KVM VM to know which host it's 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?
Thanks, Whit
I was under the impression that without some creative uses of DMI, this could not be done.
-- bk
No idea what is or is not in the code in this regard, but as a purely conceptual thought, why couldn't the host elect to put a small amount of info, whatever the admin wishes, into the fake nvram presented to the vm for it's bios?
Yes, the host can pass through information visible through the guest's SMBIOS. In fact, libvirt even supports a passthrough mode for SMBIOS information, where the host's information (except for UUID) is copied to the guest; http://libvirt.org/formatdomain.html#elementsOSBIOS (under <os>, use <smbios mode='host'/>). But note that this is only valid from the time the guest was started; SMBIOS information is read-only, and must not modify itself on the fly when the guest is migrated, so you cannot assume that what the guest reads out of SMBIOS via 'dmidecode' is still pertaining to the host currently running guest. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
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. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
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
Thanks Eric and Bryan. What I'm interested in is an unconventional failover arrangement. Say there are hosts 1 and 2, with guest A in a DRBD-mirrored partition on each. Then when guest A starts, as it happens, on host 1, it initiates a ucarp instance locally, and also causes a linked ucarp instance to run on host 2. In the event host 2 sees that guest A has become unavailable (with diverse checks to be positive) it starts it on host 2. It gets more elaborate, but that's the rough outline. Obviously this could be done by the guest, on starting, causing both hosts to run a script whose logic is: if I'm _not_ the host of this VM at present, start my side of the ucarp link with it. Thus my question whether the guest already has enough internal knowledge to simply address the other host, rather than broadcast to both. If so, it would be the simplest route to implementation. I'm sure there are many arguments to be made for not doing it this way at all. Still this way may have an advantage of simplicity, if done right, compared to the more-usual Pacemaker/OpenAIS setups, at least in the limited, well-defined context where I want to run it. A related question to my first one: The design here is for resurrection rather than live migration. But live migration would have to be dealt with. When a guest is live-migrated, is there any internal clue that the migration has occurred? This is not the question of whether the guest knows _which_ host it's on. It's the question of whether the guest knows, or can know, "Hey, I've just changed hosts!" I get it that nothing that a guest is doing by way of its normal tasks should depend on its state vis-a-vis the host of the moment. Still, there may be exceptional tasks like this where it can be useful if it knows its context. For instance, I'm expecting that within a year we may be using Gluster's geo-replication for some VMs in a DR context. If a critical VM comes up on a host on the other coast, it could be useful for some of the processes running there to know this is the context. It's not that they should _depend_ on knowing, but if they do know, it may well be we'd like them to adjust their behavior automatically according to location. Whit On Thu, Feb 02, 2012 at 11:52:37AM -0700, 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.
participants (4)
-
Brian K. White -
Bryan Kearney -
Eric Blake -
Whit Blauvelt