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

Michal Privoznik mprivozn at redhat.com
Thu Mar 7 12:23:14 UTC 2019


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?

Michal




More information about the libvir-list mailing list