[libvirt] [PATCH v2 3/3] qemu: add memfd source type

[Michal Privoznik]

On 09/19/2018 01:43 PM, Jiri Denemark wrote:
> On Wed, Sep 19, 2018 at 13:10:42 +0200, Michal Privoznik wrote:
>> On 09/19/2018 12:02 PM, Pavel Hrdina wrote:
>>> One thing about the migration though.  I'm not sure what are we
>>> officially supporting in libvirt because it might cause us some issues.
>>>
>>> We need to make sure that if you live-migrate domain from old libvirt
>>> to new libvirt you should be able to migrate that domain back to old
>>> libvirt.  The question is, whether this applies if you destroy and
>>> start the domain on the new libvirt before you live-migrate it back
>>> to old libvirt.
>>>
>>> Without the restart there is no issue, because the backend would not
>>> be changed, but once you start the same domain again we would pick
>>> new backend which would prevent migrating it back to the old libvirt.
>>>
>>
>> This is not supported. Exactly because of this reason. If we were to
>> preserve this forward compatibility (i.e. migration from newer libvirt
>> to older) then we couldn't use any new feature qemu has. For instance,
>> if qemu introduces a new device and a user starts a domain with it,
>> migration to older qemu will not work then, obviously. This also applies
>> for other qemu capabilities.
>>
>> Migrating from newer version to older is not supported. It might work,
>> but that's rather coincidence than intent.
> 
> Not really. The key point is whether a user explicitly asked for the new
> feature. In other words, taking an old XML usable with old libvirt and
> starting it on new libvirt should result in a domain which can be
> migrated back to the old version.
> 
> Think about oVirt and its transient domains which are always started
> from scratch using a generated XML. They need to be able to support
> heterogeneous clusters where some hosts run an old OS while some were
> already updated to a newer version of the host OS (and libvirt). Both
> existing and newly started domains should be migratable to any host in
> the cluster no matter when they were initially started. Unless of course
> oVirt's cluster level (or what the name for it is) is upgraded from at
> which point all hosts need to support new features.
> 
> So much for a theory. I think have bugs which prevent such migration
> compatibility in some specific cases. I'm not sure whether we
> intentionally broke this in the past, but I think we should avoid
> breaking it if possible.

Well, in that case we don't have a good option. If we have say three
options to chose from (say mem backend to use), and they are not
interchangeable, the moment we chose one the domain is not migratable.
Yet, when starting the domain we want to give our users the best option
available.

BTW: what features does this new memfd backend provides that can't be
achieved via traditional -file or -ram backends?

Michal