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.