Re: [PATCH 8/8] qemu: migration: Don't remember seclabel for images shared from current host

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jul 30, 2024 at 12:21:56PM GMT, Peter Krempa wrote:
> On Mon, Jul 29, 2024 at 08:29:42 -0700, Andrea Bolognani wrote:
> > On Mon, Jul 29, 2024 at 03:09:55PM GMT, Peter Krempa wrote:
> > > Given though that users might want to share this one, so that they can
> > > start the VM withouth migration on a different host and also we allow
> > > setting the path to a more reasonable directory for sharing
> > > (users should not share /var/lib/libvirt/qemu/nvram/, or anything
> > > belonging to libvirt in the first place)
> >
> > What's wrong with sharing this? It's just another type of storage
> > after all.
>
> Well, in case of this specific directory it'd be okay. But we had users
> wanting to share the XML directory too. In general I'd suggest user not
> share anything that belongs to libvirt.
>
> In worst case they'd share /var/lib/libvirt, which also contains stuff
> that must not be shared, such as the master keys for qemu, dnsmasq data
> files etc.
>
> Similarly, sharing /var/lib/libvirt/qemu as whole is a bad idea.

Right, I agree with you that indiscriminately sharing libvirt-private
directories would be a terrible idea. I was talking about the NVRAM
location and that one only.

> > I think there were some interesting timing issues with swtpm
> > attempting to lock the file while libvirt was trying to perform its
> > own metadata bookkeeping. I need to revisit that because honestly
> > I've forgotten almost everything about it.
>
> IIRC libvirt uses a specific block to apply the lock on so that it's
> locking it only for internal purposes. If 'swtpm' is locking the same
> block it might cause problems.

IIRC libvirt wanted to acquire the lock opportunistically and
specifically for the scope of the relabel operation, while swtpm owns
the storage and so it wants to have a long-term exclusive lock on it.

> > I have encountered at least one
> > case in which XATTRs not being cleaned up correctly on (failed?)
> > migration resulted in having to perform manual fixup tasks before the
> > domain would start again.
>
> It'd be great to know when that happened.

Once I start looking into this again, on top of your updated patches,
I'll probably manage to hit the issue whether I like it or not. When
that happens, I'll make sure to write down some details this time
around.

-- 
Andrea Bolognani / Red Hat / Virtualization



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux