Re: virDomainAttachDevice error during disk hotplug

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

 



On 08/16/2013 06:59 PM, Daniel P. Berrange wrote:
On Sat, Aug 10, 2013 at 05:38:20PM +0530, Deepak C Shetty wrote:
Hi All,
     I am trying to do a hotplug of a disk from VDSM (which uses
libvirt to get things done).
I hit the below error "operation failed: open disk image file
failed" comign from virDomainAttachDevice.
1) The qemu-img create  cmd I use (inside vdsm) to create the file
being hotplugged is

/usr/bin/qemu-img create -f qcow2 -F qcow2 -b /rhev/data-center/000065de-04b8-42e2-986c-2de664708be7/11112d24-4cda-4200-8f6d-a1d8362c70fd/images/22224c45-6504-4ea1-bd24-12340017dd32/3333017d-1278-4bfb-8129-62bded257399
/var/run/vdsm/3333017d-1278-4bfb-8129-62bded257399' (cwd
/var/run/vdsm)
So here you're using paths under /rhev or /var/run/vdsm.

Sorry, didn't get your Q here




2013-08-10 11:19:41.770+0000: 1103: debug :
virStorageFileGetMetadataRecurse:939 : path=/home/dpkshetty/libSM_disk/localstoragedomain/11112d24-4cda-4200-8f6d-a1d8362c70fd/images/22224c45-6504-4ea1-bd24-12340017dd32/3333017d-1278-4bfb-8129-62bded257399
This log suggests those paths are just symlinks into your home
directory.

Yes, and these are setup by vdsm which sets the entire path with proper vdsm.kvm perms. id 'qemu' is also part of 'kvm' group.



What permissions are set on /home/dpkshetty ?  By default $HOME permissions
will not allow any other user to access files under it. So you would have
to do  'chmod o+x /home/dpkshetty' to make this work

For instance...

[root@vdsm_tsm_int_f19 vdsm]# ls -l /| grep home
drwxr-xr-x.   3 root root  4096 Aug  8 19:53 home

[root@vdsm_tsm_int_f19 vdsm]# ls -l /home | grep dpk
drwx--x--x. 15 dpkshetty dpkshetty 4096 Aug  9 17:44 dpkshetty

[root@vdsm_tsm_int_f19 vdsm]# ls -l /home/dpkshetty | grep libSM
drwxr-xr-x. 16 dpkshetty dpkshetty 4096 Aug  9 18:36 libSM_disk

If perms weren't rite, qemu says "permission denied"... but this is diff, it says "failed to open disk image"
Atleast perms wise I feel i am fine here.

[root@vdsm_tsm_int_f19 vdsm]# su - qemu -s /bin/bash
-bash-4.2$ id
uid=107(qemu) gid=107(qemu) groups=107(qemu),36(kvm) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

-bash-4.2$ qemu-img info /var/run/vdsm/3333017d-1278-4bfb-8129-62bded257399
image: /var/run/vdsm/3333017d-1278-4bfb-8129-62bded257399
file format: qcow2
virtual size: 3.8G (4096000000 bytes)
disk size: 196K
cluster_size: 65536
backing file: /rhev/data-center/000065de-04b8-42e2-986c-2de664708be7/11112d24-4cda-4200-8f6d-a1d8362c70fd/images/22224c45-6504-4ea1-bd24-12340017dd32/3333017d-1278-4bfb-8129-62bded257399
backing file format: qcow2

-bash-4.2$ getenforce
Permissive



-bash-4.2$ ls -l /rhev/data-center/000065de-04b8-42e2-986c-2de664708be7/11112d24-4cda-4200-8f6d-a1d8362c70fd/images/22224c45-6504-4ea1-bd24-12340017dd32/3333017d-1278-4bfb-8129-62bded257399 -r--r-----. 1 vdsm kvm 197120 Aug 16 12:42 /rhev/data-center/000065de-04b8-42e2-986c-2de664708be7/11112d24-4cda-4200-8f6d-a1d8362c70fd/images/22224c45-6504-4ea1-bd24-12340017dd32/3333017d-1278-4bfb-8129-62bded257399

-bash-4.2$ qemu-img info /rhev/data-center/000065de-04b8-42e2-986c-2de664708be7/11112d24-4cda-4200-8f6d-a1d8362c70fd/images/22224c45-6504-4ea1-bd24-12340017dd32/3333017d-1278-4bfb-8129-62bded257399 image: /rhev/data-center/000065de-04b8-42e2-986c-2de664708be7/11112d24-4cda-4200-8f6d-a1d8362c70fd/images/22224c45-6504-4ea1-bd24-12340017dd32/3333017d-1278-4bfb-8129-62bded257399
file format: qcow2
virtual size: 3.8G (4096000000 bytes)
disk size: 136K
cluster_size: 65536



Daniel

--
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]