On 2/2/2012 1:41 PM, Bryan Kearney wrote: 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:33 AM, Whit Blauvelt wrote: 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. 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(a)redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org

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: