[Gluster-users] gluster and kvm livemigration

[Bernhard Glomm]

samuli wrote: 
> > 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 at pong[/5]:~ # gluster volume info glfs_atom01 Volume Name: glfs_atom01Type: ReplicateVolume ID: f28f0f62-37b3-4b10-8e86-9b373f4c0e75Status: StartedNumber of Bricks: 1 x 2 = 2Transport-type: tcpBricks:Brick1: 172.24.1.11:/ecopool/fs_atom01Brick2: 172.24.1.13:/ecopool/fs_atom01Options Reconfigured:storage.owner-gid: 104storage.owner-uid: 107network.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 treeI 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 tohttp://epboven.home.xs4all.nl/gluster-migrate.html
I can still read all file, can checksum them, just no write accessfrom outside the image file behaves as Paul described,as long as the machine is running I can't read the file
root at pong[/5]:~ # virsh list
 Id    Name                           State

----------------------------------------------------

 6     atom01                         running



root at 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 at pong[/5]:~ # file /srv/vms/mnt_atom01/atom01.img

/srv/vms/mnt_atom01/atom01.img: writable, regular file, no read permission

root at pong[/5]:~ # md5sum /srv/vms/mnt_atom01/atom01.img

md5sum: /srv/vms/mnt_atom01/atom01.img: Permission denied

root at pong[/5]:~ # virsh destroy atom01

Domain atom01 destroyed



root at 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 at 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 at pong[/5]:~ # md5sum /srv/vms/mnt_atom01/atom01.img

9d048558deb46fef7b24e8895711c554  /srv/vms/mnt_atom01/atom01.img
root at pong[/5]:~ # 

But interestingly the source of the migration can access the file after migration completedlike so: start atom01 on host "ping", migrate it to "pong"
root at pong[/8]:~ # file /srv/vms/mnt_atom01/atom01.img/srv/vms/mnt_atom01/atom01.img: writable, regular file, no read permission root at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20140124/ce61acec/attachment.html>