Re: Checking the expected behavior on dynamic image file ownership when live migrating

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

 



On Mon, Jul 01, 2019 at 05:26:45PM +0200, Christian Ehrhardt wrote:
> Hi,
> today I was debugging an issue that I found with qemu 4.0 and ended up
> puzzled about file ownership. I'm almost EOD now, but wanted to reach
> out here for a sanity check before I debug further. The case
> sumamrized is this:
> 
> 1. start guest
>   1.1 image files are changed to libvirt-qemu:kvm (which matches
> Ubuntus user/group config)
> 2. live migrate the guest to a different node
>   2.1 image files go back to root:root which they initially had (ok)
> 3. migrate guest back to the original node
>   x. image files stay root:root and are not changed back to libvirt-qemu:kvm
> 
> That is odd/unexpected, but it seems the same applies to older
> versions and there it was never a problem so far.

This sounds odd - I see no reason why the first migration should
behave differently from the second migration, as libvirt makes
no distinction & has no knowledge of previous migrations.

Could the two hosts be configured differently in some way. For
example is the disk image on ext4 on one host, but nfs on the
other host ? With shared filesystems, we'd generally expect
the disk to be exposed on a shared filesystem on both hosts.

We do take special action if we see an NFS filesystem, as we
cannot reset file ownership on the migration source, as that
would impact the migration dest too.

> In my case I stumbled over it because the newer qemu --copy-storage-*
> options now want to re-open the file at some point and that fails
> with:
> error: internal error: unable to execute QEMU command 'drive-mirror':
> Could not reopen file: Permission denied
> 
> If I e.g. shut down and start the guest on the source node (which
> fixes up the ownership at runtime) then migration with copy-storage
> works fine again.
> 
> I'm mostly looking for hints if this is a known issue or being worked
> on to not waste time tomorrow.
> So hints are welcome.
> 
> -- 
> Christian Ehrhardt
> Software Engineer, Ubuntu Server
> Canonical Ltd
> 
> --
> libvir-list mailing list
> libvir-list@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/libvir-list

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[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