On Tue, Jun 23, 2015 at 09:06:24PM -0400, Laine Stump wrote: > On 06/23/2015 11:57 AM, Ján Tomko wrote: > > On Mon, Jun 22, 2015 at 02:44:05PM -0400, Laine Stump wrote: [snip] > >> === > >> Idea 3: interpret controllers with missing subType as above, but > >> actually write it out to the config/migration/etc in the new modified > >> format. > >> > >> Cons: This would prevent downgrading libvirt or migrating from a host > >> with newer libvirt to one with older libvirt. (Although preserving > >> compatibility at some level when downgrading may be a stated > >> requirement of some downstream distros' builds of libvirt, I think for > >> upstream it is only a "best effort"; I'm just not certain how much "best" is considered to be :-) > >> > > I do not know of any effort done to make downgrading libvirt work. > > You haven't talked to enough people deploying RHEV/oVirt in production - > they want the ability to upgrade some nodes, migrate guests over to > them, then migrate the guests back if the upgrade needs to be undone. > That is migration, where we pass the "migratable" XML. The domain configs and live status XMLs can contain things that won't be parsable by older libvirt. Under 'downgrade' I imagined simply installing older libvirt packages - this can possibly fail, even if the domains only use features present in the old libvirt too. > > Any machine configs that use new values for old attributes will > > disappear (and so will running machines, because of new qemu > > capabilities). > > > > Migration is somewhat supported, so the compatible format could be used > > only when the model is default and VIR_DOMAIN_DEF_FORMAT_MIGRATABLE was > > specified? > > Isn't VIR_DOMAIN_DEF_FORMAT_MIGRATABLE there in part so that migrations > from newer libvirt to older libvirt might work? (it doesn't guarantee > it, but it does make it work in some situations where it otherwise > wouldn't). > Yes, if the domain worked with the old libvirt, we should be able to migrate to the new libvirt and back, thanks to this flag. > > > >> === > >> Idea 4: Unlike other uses of "model" in libvirt, for pci controllers, > >> continue to use "model" to denote the subtype/class/whatever of > >> controller, and create a new attribute to denote the different > >> specific implementations of each one. So for example: > >> > >> [4] <controller type='pci' model='dmi-to-pci-bridge'/> > >> > >> would become: > >> > >> [5] <controller type='pci' model='dmi-to-pci-bridge' > >> implementation='i82801b11-bridge'/> > >> > >> (or some other name in place of "implementation" - ideas? I'm horrible > >> at thinkin up names) > >> > > device? actualModel? :) > > hey, I think I might like "device"! > > > > >> Pros: wouldn't create compatibility problems when downgrading or > >> migrating cross version. > >> > > If you tried to migrate to older libvirt with: > > model='dmi-to-pci-bridge' impl='generic', older libvirt would not parse > > the impl flag and create a machine with i8201b11-bridge. (Assuming the > > QEMU would know the machine type). > > Well, yeah, this does point out a flaw in my thinking :-/ > This happens with all new XML elements - libvirt's parser usually does an XPath query for the elements it knows and ignores the unknown ones. IIRC this is on purpose. Jan
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list