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
