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-9aadee401eff19b4f32f9a37a124b4e08a19ad2b915a44ff9f4ff43c1da50ca5 -- Andrea Bolognani / Red Hat / Virtualization _______________________________________________ Devel mailing list -- devel@xxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
