On Thu, Mar 07, 2019 at 01:34:15PM +0100, Erik Skultety wrote: > On Thu, Mar 07, 2019 at 01:23:14PM +0100, Michal Privoznik wrote: > > On 3/7/19 1:07 PM, Daniel P. Berrangé wrote: > > > On Thu, Mar 07, 2019 at 12:52:46PM +0100, Erik Skultety wrote: > > > > > However, looking at the bigger picture is this a safe thing to do? I mean, > > > > > imagine the following scenario: > > > > > > > > > > 1) say there is capability X that affects certain part of cmd line. And > > > > > assume that those two possibilities are incompatible. If cmd line is > > > > > generated one way then migration to a qemu which has cmd line generated the > > > > > other way fails. > > > > > > > > > > 2) in release R we deprecate X and thus do not format it in <capabilities/> > > > > > in status XML. > > > > > > > > > > 3) user starts a domain D. > > > > > > > > > > 4) user saves D into a file > > > > > > > > > > 5) sysadmin downgrades libvirt to R-1 > > > > > > > > Do we even support downgrade this way? I know we migrate to older version but > > > > isn't that different? > > > > Okay, forget about save+restore. Let's just keep the domain D running and > > then downgrade libvirt. Now, instead of X affecting cmd line let it affect > > how we talk to qemu on monitor. Since R assumed X always being there then X > > wouldn't be recorded in status XML. Later when R-1 daemon is starting and > > parsing the status XML it won't find X and thus might make wrong decissions. > > For instance, if X would be some capability that affects the way we generate > > PCI addresses for guest devices, then this would really harm the user. > > > > Worse, let just start the domain with R-1, then upgrade to R to test it, > > call an API over D (at which point the status XML is regenerated, now > > without X stored in it), find that it's not working so roll back to R-1 and > > puff. The capability is gone. > > I understand the X_ flags as something we implicitly expect from QEMU, IOW we > bump the minimal version of QEMU we expect (with all the supported distros in > mind) and so we mark a bunch of capabilities with X, if we drop them, how is > what you're describing an issue since the capability is implicitly assumed to > be supported by given version of QEMU regardless of libvirt version? > Maybe I misunderstood your example, but I don't think we can ever mark a > capability as X if that is still not an integral part of that QEMU version. > Therefore, it should not affect the way we construct the cmdline and how we > talk to the monitor, right? I think in general you are right - the X_ flags represent some feature we now assume exists. There's a few exceptions though. The most notable being the first 'KQEMU' which was simply deleted. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
