[libvirt] [PATCH 00/13] PCIe fixes + new PCI controllers w/RFC

[Ján Tomko]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20150624/de64ced0/attachment-0001.sig>