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

[Michal Privoznik]

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