Re: [libvirt] [PATCH v2 3/3] qemu: add memfd source type
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.
Jirka