On 4/17/24 11:20, Andrea Bolognani wrote:
On Wed, Mar 20, 2024 at 09:10:48AM -0700, Andrea Bolognani wrote:
On Wed, Mar 20, 2024 at 10:18:39AM -0400, Stefan Berger wrote:
On 3/20/24 08:23, Peter Krempa wrote:
Did you consider the case when the migration fails and the VM will be
restored to run on the source host again? In such case doin the
relabelling might break the source host.
Right. I seem to remember testing such scenarios. I had to put an exit() (or
something like it) into swtpm on the destination side to trigger the
fallback to the source side. The swtpm on the source side had closed file
access and wants to open them (lockfile) again and so the files needed to be
labeled correctly if the storage on the source side is
on the disk and exported via NFS from there (iirc). If the storage is
NFS-exported from a 3rd host it probably would not require the labels.
I didn't really consider the failure scenario, so thank you for
bringing that up.
I think it would be still fine. If the source has NFS storage, then
access will keep working regardless of what relabeling the
destination has been up to in the meantime. And if the source has
local storage, then the relabeling on the destination (via NFS) will
not actually have touched the SELinux labels.
The only concern I have is that, when going from local to NFS, labels
might have been restored on the source side. But I assume that
restoring only happens once the migration has been confirmed as
successful? I'll check.
Once again, as far as I can tell (please let me know if I'm wrong!)
there is no special casing when it comes to disks and other types of
persistent storage, so if this approach was problematic I would have
expected many issues to have been reported by now.
I've tested this to confirm. My trick to simulating a migration
failure was to add
<qemu:commandline>
<qemu:arg value='-machine'/>
<qemu:arg value='pc-i440fx-6.0'/>
</qemu:commandline>
to the migration XML, where the VM uses a different machine type in
its configuration. This results in something like
process exited while connecting to monitor: qemu-system-x86_64:
-device {"driver":"pcie-root-port","port":8,"chassis":1,"id":"pci.1",\
"bus":"pcie.0","multifunction":true,"addr":"0x1"}: Bus 'pcie.0' not found
which should be a decent enough proxy for the kind of "we went as far
as attempting to start the QEMU process on the destination host, then
things went sideways" failure that we'd experience as a consequence
of a permission error. Suggestions on how to improve the test
methodology are very much appreciated :)
Anyway, based on what I've seen I think I can confirm my initial
intuition as reported above. Things work the way you expect, in that
upon migration failure the VM keeps happily chugging along on the
source host.
If a file is labeled on the NFS server side then the current code
doesn't relabel the state file on server side when we have an outgoing
migration due to possible fall-back in case of error. With NFS at least
not supporting SElinux labels (and security xattrs) we are fine on the
server side if the fallback happens whatever was done with SELinux
labeling on the client side (gets EOPNOTSUPP) because the label will not
be changed on the server side. If there existed a shared filesystem that
supports SELinux labels and propagated them we'd be in trouble at least
for the fall-back scenario, right? I don't know whether any shared
filesystem would ever share security xattrs across the network, though,
so that this could become a problem.
_______________________________________________
Devel mailing list -- devel@xxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
