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 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. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature