On Wed, Mar 20, 2024 at 12:37:37PM +0100, Peter Krempa wrote:
> On Wed, Mar 20, 2024 at 10:19:11 +0100, Andrea Bolognani 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.
> > +#
> > +# Any directory listed here will be assumed to live on a shared filesystem,
> > +# making migration possible in scenarios such as the one described above.
> > +#
> > +# If you need this feature, you probably want to set remember_owner=0 too.
>
> Could you please elaborate why you'd want to disable owner remembering?
> With remote filesystems this works so I expect that if this makes
> certain paths behave as shared filesystems, they should behave such
> without any additional tweaks
To be quite honest I don't remember exactly why I've added that, but
I can confirm that if remember_owner=0 is not used on the destination
host then migration will stall for a bit and then fail with
error: unable to lock /var/lib/libvirt/swtpm/.../tpm2/.lock for
metadata change: Resource temporarily unavailable
Things work fine if swtpm is not involved. I'm going to dig deeper,
but my guess is that, just like the situation addressed by the last
patch, having an additional process complicates things compared to
when we need to worry about QEMU only.
> > +#shared_filesystems = [
> > +# "/var/lib/libvirt/images",
> > +# "/var/lib/libvirt/qemu/nvram",
> > +# "/var/lib/libvirt/swtpm"
> > +#]
>
> Do we want to give real paths as examples? Users might think that they
> are the 'suggested' values, while it really depends on how they've
> configured it. I sugest using something clearly dummy here.
Hopefully people will read the comment, but I can change those to
something like
shared_filesystems = [
"/path/to/images",
"/path/to/nvram",
"/path/to/swtpm"
]
if you think it's less likely to cause confusion.
--
Andrea Bolognani / Red Hat / Virtualization
_______________________________________________
Devel mailing list -- devel@xxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
