On Mon, Apr 24, 2023 at 12:08:57PM +0200, Laszlo Ersek wrote:
> On 4/24/23 10:46, Richard W.M. Jones wrote:
> > On Fri, Apr 21, 2023 at 09:01:40PM +0300, Andrey Drobyshev wrote:
> >> This patch effectively limits the number of cases when we would want to
> >> do a complete SELinux relabeling on Linux guest conversion.
> >>
> >> This was brought to my attention as we've recently had a support case
> >> when the conversion was taking too much time mostly because of
> >> relabeling performed with "setfiles -F".
> >>
> >> Although this patch might be worthy of taking as it is, I'd also like to
> >> clarify, do we really need relabeling of the entire file system during
> >> conversion? What exactly might go wrong here if we don't do that?
> >> Since this process might take hours on VMs big enough, it would be
> >> beneficial to be able to limit number of such cases even further, if
> >> possible. Unfortunately I couldn't find any hints in the libguestfs commit
> >> history as the relabeling code goes back to 0131d6f666 ("New tool:
> >> virt-v2v.").
> >
> > Relabelling is generally needed because we may have modified or
> > created files during the conversion. These will not be labelled
> > correctly by the libguestfs appliance (as would happen when the guest
> > runs normally) because whatever SELinux mechanism that does this isn't
> > running.
> >
> > If SELinux is enforcing this can and will stop services from starting
> > up at boot (you will see permission errors), and can even prevent a
> > guest from booting at all.
> >
> > Note we don't even have a list of possible files affected because we
> > run stuff like dracut & rpm.
> >
> > We should probably only need to relabel over "system directories"
> > (whatever that means), but we currently relabel over everything
> > mounted (basically everything mentioned in /etc/fstab) because that's
> > easier. The alternate path if setfiles doesn't work touches
> > /.autorelabel, but that just moves the same work to boot time.
> >
> > I don't think we've seen a case of labelling taking a long time, but
> > it could happen.
>
> (1) In "daemon/selinux-relabel.c", we have this comment:
>
> /* If setfiles takes an excessively long time to run (but still
> * completes) then removing .../contexts/files/file_contexts.bin
> * appears to help. If you find any such cases, please add
> * observations to the bug report:
> * https://bugzilla.redhat.com/show_bug.cgi?id=1396297
> */
>
> Perhaps it still applies.
>
> (2) We've touched on passing "--smp N" with N>1 to virt-customize.
> Recent versions of the selinux library can utilize multiple threads for
> relabeling. For example, the "restorecon" and "setfiles" utilities
> gained the "-T nthreads" option a while ago.
>
> Unfortunately, the default is "-T 1"; we should modify libguestfs to
> pass "-T 0", whenever "-T" is recognized.
>
> http://mid.mail-archive.com/20220719192112.GO21552@redhat.com
>
> AFAICT, virt-v2v would immediately benefit from this (even without an
> --smp switch); see commit d2b64ecc6701 ("v2v: Set the number of vCPUs to
> same as host number of pCPUs.", 2020-12-01).
>
> Andrey, how do you feel about contributing the "-T 0" extension to
> libguestfs? :)
>
> In "daemon/selinux-relabel.c", the setfiles_has_option() function should
> be usable for detecting whether "-T" is supported in the appliance.
Yes this would be a good idea. Note that virt-v2v already enables smp
(see convert/convert.ml call to g#set_smp) so it could benefit
immediately. virt-builder & virt-customize let you set --smp on the
command line but default it to 1.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
_______________________________________________
Libguestfs mailing list
Libguestfs@redhat.com
https://listman.redhat.com/mailman/listinfo/libguestfs
