On Wed, Mar 20, 2024 at 01:22:15PM +0100, Peter Krempa wrote:
> > +# libvirt will normally prevent migration if the storage
backing the VM is not
> > +# on a shared filesystems. Sometimes, however, the storage *is* shared
despite
> > +# not being detected as such: for example, this is the case when one of the
> > +# hosts involved in the migration is exporting its local storage to the other
> > +# one via NFS.
TBH this feels a bit weird. Having the NFS server on the host you are
migrating from will e.g. cause storage to start have network latency
which it didn't before.
Additionally you can't even take the host down for maintenance as it's
still serving storage for the VM.
How is this expected to be used? I don't seem to understand why would
anybody want to do this in contrast to e.g. migrating also the storage
fully to the destination.
The main driver for this feature is KubeVirt, and more specifically
its integration with a storage provider called Portworx.
From what I understand, the way this provider works is that it will
initially configure the VM storage so that it's local to the machine
running the pod; when migration occurs, however, the same storage
will be exported to the destination machine via NFS.
Since currently libvirt blocks attempt to migrate from local storage,
in order to make things work they're tricking it into thinking it's
NFS instead by using an LD_PRELOAD hack[1].
Since that's a... Somewhat questionable approach, the idea here is to
provide a more targeted and supportable way to let libvirt know that
some host paths are shared, even though a shared filesystem is not
used locally.
In the more general case, there's really nothing preventing people
from creating a similar setup outside of KubeVirt with Portworx. As
you rightfully point out, there are some drawbacks to the approach
but it's not necessarily an invalid one per se.
[1]
https://github.com/libopenstorage/stork/pull/1117/files#diff-9aadee401eff...
--
Andrea Bolognani / Red Hat / Virtualization