On Mon, Feb 20, 2017 at 09:55:40PM +0100, Laszlo Ersek wrote: > On 02/20/17 21:45, Eric Blake wrote: > > On 02/20/2017 02:19 PM, Dr. David Alan Gilbert wrote: > >> * Eric Blake (ebl...@redhat.com) wrote: > >>> On 02/20/2017 04:23 AM, Dr. David Alan Gilbert wrote: > >>>> * Laszlo Ersek (ler...@redhat.com) wrote: > >>>>> CC Dave > >>>> > >>>> This isn't an area I really understand; but if I'm > >>>> reading this right then > >>>> vmgenid is stored in fw_cfg? > >>>> fw_cfg isn't migrated > >>>> > >>>> So why should any changes to it get migrated, except if it's already > >>>> been read by the guest (and if the guest reads it again aftwards what's > >>>> it expected to read?) > >>> > >>> Why are we expecting it to change on migration? You want a new value > >> > >> I'm not; I was asking why a change made prior to migration would be > >> preserved across migration. > > > > Okay, so you're asking what happens if the source requests the vmgenid > > device, and sets an id, but the destination of the migration does not > > request anything > > This should never happen, as it means different QEMU command lines on > source vs. target hosts. (Different as in "incorrectly different".) > > Dave writes, "a change made prior to migration". Change made to what? > > - the GUID cannot be changed via the monitor once QEMU has been started. > We dropped the monitor command for that, due to lack of a good use case, > and due to lifecycle complexities. We have figured out a way to make it > safe, but until there's a really convincing use case, we shouldn't add > that complexity.
True but we might in the future, and it seems prudent to make migration stream future-proof for that. > - the address of the GUID is changed (the firmware programs it from > "zero" to an actual address, in a writeable fw_cfg file), and that piece > of info is explicitly migrated, as part of the vmgenid device's vmsd. > > Thanks > Laszlo > > > > - how does the guest on the destination see the same id > > as was in place on the source at the time migration started. > > > >> > >> > >>> when you load state from disk (you don't know how many times the same > >>> state has been loaded previously, so each load is effectively forking > >>> the VM and you want a different value), but for a single live migration, > >>> you aren't forking the VM and don't need a new generation ID. > >>> > >>> I guess it all boils down to what command line you're using: if libvirt > >>> is driving a live migration, it will request the same UUID in the > >>> command line of the destination as what is on the source; while if > >>> libvirt is loading from a [managed]save to restore state from a file, it > >>> will either request a new UUID directly or request auto to let qemu > >>> generate the new id. > >> > >> Hmm now I've lost it a bit; I thought we would preserve the value > >> transmitted from the source, not the value on the command line of the > >> destination. > > > > I guess I'm trying to figure out whether libvirt MUST read the current > > id and explicitly tell the destination of migration to reuse that id, or > > if libvirt can omit the id on migration and everything just works > > because the id was migrated from the source. > >