* 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. > 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. Dave > > -- > Eric Blake eblake redhat com +1-919-301-3266 > Libvirt virtualization library http://libvirt.org > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK