Can you try to set storage.owner-uid and storage.owner-gid to
libvirt-qemu? To do that you have to stop volume.
hi samuli, hi all
I tried setting storage.owner-uid and storage.owner-gid to
libvirt-qemu, as suggested, but with the same effect,
during livemigration the ownership of the imagefile changes from libvirt-qemu/kvm to root/root
root@pong[/5]:~ # gluster volume info glfs_atom01
Volume Name: glfs_atom01
Type: Replicate
Volume ID: f28f0f62-37b3-4b10-8e86-9b373f4c0e75
Status: Started
Number of Bricks: 1 x 2 = 2
Transport-type: tcp
Bricks:
Brick1: 172.24.1.11:/ecopool/fs_atom01
Brick2: 172.24.1.13:/ecopool/fs_atom01
Options Reconfigured:
storage.owner-gid: 104
storage.owner-uid: 107
network.remote-dio: enable
this is tree -pfungiA <path to where my images live> : atom01 is running
[-rw------- libvirt- kvm ] /srv/vms/mnt_atom01/atom01.img
[drwxr-xr-x libvirt- kvm ] /srv/vms/mnt_atom02
[-rw------- root root ] /srv/vms/mnt_atom02/atom02.img
[drwxr-xr-x libvirt- kvm ] /srv/vms/mnt_atom03
Now I migrate through "VirtualMachineManager" and watching tree
I see the permission changing to:
[drwxr-xr-x libvirt- kvm ] /srv/vms/mnt_atom01
[-rw------- root root ] /srv/vms/mnt_atom01/atom01.img
[drwxr-xr-x libvirt- kvm ] /srv/vms/mnt_atom02
[-rw------- root root ] /srv/vms/mnt_atom02/atom02.img
From inside the atom01 (the VM) the filesystem becomes readonly.
But in contrast to
http://epboven.home.xs4all.nl/gluster-migrate.htmlI can still read all file, can checksum them, just no write access
from outside the image file behaves as Paul described,
as long as the machine is running I can't read the file
root@pong[/5]:~ # virsh list
Id Name State
----------------------------------------------------
6 atom01 running
root@pong[/5]:~ # l /srv/vms/mnt_atom01/atom01.img
-rw------- 1 root root 10G Jan 24 10:20 /srv/vms/mnt_atom01/atom01.img
root@pong[/5]:~ # file /srv/vms/mnt_atom01/atom01.img
/srv/vms/mnt_atom01/atom01.img: writable, regular file, no read permission
root@pong[/5]:~ # md5sum /srv/vms/mnt_atom01/atom01.img
md5sum: /srv/vms/mnt_atom01/atom01.img: Permission denied
root@pong[/5]:~ # virsh destroy atom01
Domain atom01 destroyed
root@pong[/5]:~ # l /srv/vms/mnt_atom01/atom01.img
-rw------- 1 root root 10G Jan 24 10:20 /srv/vms/mnt_atom01/atom01.img
root@pong[/5]:~ # file /srv/vms/mnt_atom01/atom01.img
/srv/vms/mnt_atom01/atom01.img: x86 boot sector; partition 1: ID=0x83, starthead 1, startsector 63, 16777165 sectors; partition 2: ID=0xf, starthead 254, startsector 16777228, 1677718 sectors, code offset 0x63
root@pong[/5]:~ # md5sum /srv/vms/mnt_atom01/atom01.img
9d048558deb46fef7b24e8895711c554 /srv/vms/mnt_atom01/atom01.img
root@pong[/5]:~ #
But interestingly the source of the migration can access the file after migration completed
like so: start atom01 on host "ping", migrate it to "pong"
root@pong[/8]:~ # file /srv/vms/mnt_atom01/atom01.img
/srv/vms/mnt_atom01/atom01.img: writable, regular file, no read permission
root@ping[/5]:~ # file /srv/vms/mnt_atom01/atom01.img
/srv/vms/mnt_atom01/atom01.img: x86 boot sector; partition 1: ID=0x83, starthead 1, startsector 63, 16777165 sectors; partition 2: ID=0xf, starthead 254, startsector 16777228, 1677718 sectors, code offset 0x63
100% reproducible
Regards
Bernhard
_______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-users
