Re: [libvirt] [PATCH 6/8] virQEMUCapsSetFromNodes: Skip setting deprecated flags

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. > > >> >> Yeah, downgrades of libvirt are not something we claim is supported. If >> will often work but we're not guaranteeing it & have broken it in the >> past, especially for running guests. You might be lucky if you have >> upgraded & immedaitely downgrade, but if you've made changes to guests >> while the new libvirt was running all bets are off. > > Not even in the case I'm describing above? Yep. IMHO if you are upgrading just to test a new version, you should expect to have to stop & start your guests if you see problems after a subsequent downgrade. This kind of testing is not something to be done in production, only in dev/test where VMs are disposable. We should not go out of our way to intentionally break downgrades, but if the best way to change something for new libvirt happens to break dowgrades of running VMs that's acceptable.