Hi, Javier.

I have double checked, that the root has access to both disk.0 and to the base image from the hosting node. It is apparently not a problem. What could be the difference between the qcow2 images booting and the raw images booting from the access rights perspective? The raw images are starting fine.

Best,
Alex


-------- Original Message --------
Subject:        Re: [one-users] Problems with qcow2 images
Date:   Wed, 26 Jan 2011 15:41:51 +0100
From:   Alexander Fedulov <[email protected]>
To:     [email protected]


I have modified the nfs exports on my ON manager host by adding
no_root_squash:
    /srv/cloud      192.168.144.21(rw,no_root_squash)
    /srv/cloud      192.168.144.22(rw,no_root_squash)

- no changes, the same error:
    qemu: could not open disk image
/srv/cloud/one/var//41/images/disk.0: Permission denied

Permissions of the disk.0 before the failure seem to be fine:
    -rw-rw-rw- 1 oneadmin cloud 262144 2011-01-26 15:29 disk.0


During the deployment, before disk.0 was erased, I was able to access
the disk image from the executing host as root.
    root@brandy:/var/log/libvirt/qemu# qemu-img info
/srv/cloud/one/var/41/images/disk.0
    image: /srv/cloud/one/var/41/images/disk.0
    file format: qcow2
    ...

I am really stuck and hope for your help. Many  thanks in advance.

Yours sincerely,
Alexander


On 24.01.2011 15:00, Alexander Fedulov wrote:
 Here are permissions for the image and for the base image:
 -rw-r--r--  1 oneadmin cloud     262144 2011-01-20 19:23 qcow.img
 -rw-r--r--  1 oneadmin cloud 2147483648 2010-11-19 12:22 ubuntu10-04.img

 ...and for the folders (/srv/cloud/temp and up):

 drwxr-xr-x  3 oneadmin cloud       4096 2011-01-24 14:32 .
 drwxr-xr-x 12 oneadmin cloud       4096 2011-01-18 12:01 ..


 These are the permissions for disk.0 before it is deleted due to failure:
 -rw-rw-rw- 1 oneadmin cloud 262144 2011-01-24 14:45 disk.0

 Any thoughts?

 On 24.01.2011 12:10, Javier Fontan wrote:
 Is /srv/cloud/temp/ubuntu10-04/qcow.img readable by root? It needs to
 be readable by root in the execution node. Also check the permissions
 in for the directories where it is stored.

 tm_clone.sh should have changed permissions for
 "/srv/cloud/one/var//24/images/disk.0" check if that is correct. root
 is the user that is accessing these files but with NFS sharing you
 have to give the permissions for all or add no_root_squash to the
 exporting parameters.

 On Thu, Jan 20, 2011 at 8:17 PM, Alexander Fedulov
 <[email protected]>   wrote:
 I created a qcow2 image from a raw image like this:
 qemu-img create -f qcow2 -b ubuntu10-04.img qcow.img
 The DISC section of of my deployment descriptor looks like this:
 DISK   = [
   source   = "/srv/cloud/temp/ubuntu10-04/qcow.img",
   target   = "sda",
   readonly = "no" ,
   DRIVER = qcow2]
 I have edited the ~/lib/tm_commands/nfs/th_clone.sh file according
 to this
 https://support.opennebula.pro/entries/348847-using-qcow-images
 without the
 SSH part:

 *)
     log "Cloning $SRC_PATH"
     exec_and_log "qemu-img create -f qcow2 -o backing_file=$SRC_PATH
 $DST_PATH"
     ;;
 esac
 Unfortunately deployment fails and this is what I find in the one-*.log
 files in the /var/log/libvirt/qemu folder of a target host.

 LC_ALL=C
 PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin
 QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -enable-kvm -m 768
 -smp 1
 -name one-24 -uuid 9f3d9ed7-d17f-e6d1-d997-5fed5a84aa47 -chardev
 socket,id=monitor,path=/var/lib/libvirt/qemu/one-24.monitor,server,nowait

 -monitor chardev:monitor -no-acpi -boot c -drive
 file=/srv/cloud/one/var//24/images/disk.0,if=scsi,index=0,boot=on,format=qcow2

 -drive
 
file=/srv/cloud/one/var//24/images/disk.1,if=scsi,media=cdrom,index=2,format=raw

 -net nic,macaddr=02:00:c0:a8:90:22,vlan=0,name=nic.0 -net
 tap,fd=54,vlan=0,name=tap.0 -serial none -parallel none -usb -vnc
 0.0.0.0:20
 -k de -vga cirrus
 qemu: could not open disk image /srv/cloud/one/var//24/images/disk.0:
 Permission denied
 Deployment of raw images works fine. The version of ON is 2.0.1.

 I was wondering, whether there is some chmod operation that has to
 be added
 to the tm_clone.sh script or is the problem in something else?

 _______________________________________________
 Users mailing list
 [email protected]
 http://lists.opennebula.org/listinfo.cgi/users-opennebula.org




 _______________________________________________
 Users mailing list
 [email protected]
 http://lists.opennebula.org/listinfo.cgi/users-opennebula.org

_______________________________________________
Users mailing list
[email protected]
http://lists.opennebula.org/listinfo.cgi/users-opennebula.org

_______________________________________________
Users mailing list
[email protected]
http://lists.opennebula.org/listinfo.cgi/users-opennebula.org

Reply via email to