On Wed, Mar 20, 2024 at 12:37:37 +0100, Peter Krempa wrote: > On Wed, Mar 20, 2024 at 10:19:11 +0100, Andrea Bolognani wrote: > > As explained in the comment, this can help in scenarios where > > a shared filesystem can't be detected as such by libvirt, by > > giving the admin the opportunity to provide this information > > manually. > > > > Signed-off-by: Andrea Bolognani <abologna@xxxxxxxxxx> > > --- > > src/qemu/libvirtd_qemu.aug | 3 +++ > > src/qemu/qemu.conf.in | 17 +++++++++++++++++ > > src/qemu/qemu_conf.c | 17 +++++++++++++++++ > > src/qemu/qemu_conf.h | 2 ++ > > src/qemu/test_libvirtd_qemu.aug.in | 5 +++++ > > 5 files changed, 44 insertions(+) > > [...] > > > diff --git a/src/qemu/qemu.conf.in b/src/qemu/qemu.conf.in > > index f406df8749..db42448239 100644 > > --- a/src/qemu/qemu.conf.in > > +++ b/src/qemu/qemu.conf.in > > @@ -986,3 +986,20 @@ > > # note that the default might change in future releases. > > # > > #storage_use_nbdkit = @USE_NBDKIT_DEFAULT@ > > + > > +# 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. _______________________________________________ Devel mailing list -- devel@xxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
