On Tue, Mar 07, 2017 at 02:55:43PM +0100, Andrea Bolognani wrote: > On Tue, 2017-03-07 at 09:19 +0100, Pavel Hrdina wrote: > > > However, after migration is complete, the <controller> > > > element has model='nec-xhci' instead of model='pci-ohci', > > > which means that power cycling the guest results in > > > breaking the guest ABI. > > > > I'm not so sure that this is an ABI change. The guest ABI is to ensure > > that the same guest XML will always start the same QEMU guest. However > > the PERSISTENT migration can make ABI changes because it is the same as > > virsh dumpxml $domain > $domain.xml && copy the XML onto remote host > > and virsh define $domain.xml. This would also change the *model*. > > > > If this would be considered to be guest ABI stable it would mean that > > other changes done by using this flag would be wrong because they also > > modifies the persistent XML during migration. > > I assume there are very good reasons for persistent > migration to behave differently, but as a user I find > it extremely surprising. Do you have any insight on the > rationale behind allowing ABI changes when performing > persistent migration? Well it's a different kind of migration which is almost similar to the virsh dumpxml --inactive && virsh define, with one more feature, migration hook that can update the XML before it's defined on the destination. I agree that it may seem that we should handle this type of migration to be guest ABI stable, on the other hand this basically defines new domain on the destination where we allow to do the ABI updates. I'm adding Dan to CC to get his opinion about the guest ABI. > The only other example I could find of ABI update being > used is in virDomainDefPostParseMemory(), and AFAIU adding > or removing memory from a guest is not an ABI change. Did > I miss other uses? There is also an update of USB addresses in qemuDomainAssignUSBAddresses. Pavel
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
