On 3/7/19 1:27 PM, Daniel P. Berrangé 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.
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.
Okay then. Jano, can you please send v2? I'll review it.
Michal
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
