On Tue, Sep 04, 2012 at 12:50:55 +0100, Daniel P. Berrange wrote: > When I think of upgrade issues, i consider the scenario where the new > libvirt is configured in the same way as the old livirt, and we need > to make sure the guest behaviour remains the same. This scenario you > describe obviously doesn't fall under that, since you're enabling new > behaviour that was not previously possible. I so don't think that is > an upgrade problem, but rather just a case of defining what the new > behaviour should be. > > IMHO, the behaviour is thus > > - A single <seclabel> with no model=XXX attribute, refers to the first > security driver > - Multiple <seclabel> with explicit model=XXX attributes refer to the > corresponding driver > - Multiple <seclabel> with no model=XX -> forbidden config > > If you want to set behaviour for the secondary, or tertiary security > drivers then you are required to provide multiple <seclabel> elements > with explicit model=XXXX attributes. We shouldn't try to abuse a single > <seclabel> element to set properties against multiple security drivers. Fair enough and works for me :-) We ended up with a clearly defined behavior, which is worth including in formatdomain.html Jirka -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list