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

On 06/23/2015 11:57 AM, Ján Tomko wrote: > On Mon, Jun 22, 2015 at 02:44:05PM -0400, Laine Stump wrote:

>> === >> 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.

> 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).

> >> === >> 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 :-/