Re: [one-users] Question on /var/lib/remotes/tm/shared/clone script

2014-12-30 Thread Daniel Dehennin
Steven C Timm t...@fnal.gov writes:

 [root@cloudworker1359 libvirt]# grep -v ^# qemu.conf | grep .

 dynamic_ownership = 0

You must set “user” and “group” to “oneadmin” like described in the
documentation[1].

This way the qemu process run as oneadmin and has write access to the images.

Regards.


Footnotes: 
[1]  
http://docs.opennebula.org/4.10/design_and_installation/quick_starts/qs_ubuntu_kvm.html#configure-qemu

-- 
Daniel Dehennin
Récupérer ma clef GPG: gpg --recv-keys 0xCC1E9E5B7A6FE2DF
Fingerprint: 3E69 014E 5C23 50E8 9ED6  2AAD CC1E 9E5B 7A6F E2DF


signature.asc
Description: PGP signature
___
Users mailing list
Users@lists.opennebula.org
http://lists.opennebula.org/listinfo.cgi/users-opennebula.org


Re: [one-users] Question on /var/lib/remotes/tm/shared/clone script

2014-12-30 Thread Steven Timm

This trick does work to start the particular VM in question
in this particular use case of shared repo and cloning.

I think we didn't make this change in our ONE3.2 installation because
we had other reasons why we needed the qemu user to run KVM
in other transfer mode situations.  Will have to look at all the
other use cases we have to make sure we don't break anything else.

Steve Timm




On Tue, 30 Dec 2014, Daniel Dehennin wrote:


Steven C Timm t...@fnal.gov writes:


[root@cloudworker1359 libvirt]# grep -v ^# qemu.conf | grep .

dynamic_ownership = 0


You must set “user” and “group” to “oneadmin” like described in the
documentation[1].

This way the qemu process run as oneadmin and has write access to the images.

Regards.


Footnotes:
[1]  
http://docs.opennebula.org/4.10/design_and_installation/quick_starts/qs_ubuntu_kvm.html#configure-qemu

--
Daniel Dehennin
Récupérer ma clef GPG: gpg --recv-keys 0xCC1E9E5B7A6FE2DF
Fingerprint: 3E69 014E 5C23 50E8 9ED6  2AAD CC1E 9E5B 7A6F E2DF



--
Steven C. Timm, Ph.D  (630) 840-8525
t...@fnal.gov  http://home.fnal.gov/~timm/
Office:  Wilson Hall room 804
Fermilab Scientific Computing Division,
Scientific Computing Facilities Quadrant.,
Experimental Computing Facilities Dept.,
Project Lead for Virtual Facility Project.

___
Users mailing list
Users@lists.opennebula.org
http://lists.opennebula.org/listinfo.cgi/users-opennebula.org


[one-users] Question on /var/lib/remotes/tm/shared/clone script

2014-12-29 Thread Steven C Timm
We have noticed this problem recently in OpenNebula 4.6 and 4.8 recently.  We 
also
had to make a similar patch in OpenNebula 3.2

Our use case:
we have a SHARED image datastore


DATASTORE 102 INFORMATION

ID : 102

NAME   : cloud_images

USER   : oneadmin

GROUP  : oneadmin

CLUSTER: cloudworker

TYPE   : IMAGE

DS_MAD : fs

TM_MAD : shared

BASE PATH  : /var/lib/one/datastores/102

DISK_TYPE  : FILE


-


We have a non-shared SYSTEM data store (local to each of 250-some nodes)


[root@fclheadgpvm01 shared]# onedatastore show 100

DATASTORE 100 INFORMATION

ID : 100

NAME   : localnode

USER   : oneadmin

GROUP  : oneadmin

CLUSTER: cloudworker

TYPE   : SYSTEM

DS_MAD : -

TM_MAD : ssh

BASE PATH  : /var/lib/one/datastores/100/100

DISK_TYPE  : FILE



When we launch a VM the tm/shared/clone procedure is invoked


[root@cloudworker1359 1]# ls -lrt

total 2390660

-rw-r--r-- 1 oneadmin oneadmin 2447638528 Dec 29 20:52 disk.0

-rw-r--r-- 1 oneadmin oneadmin 389120 Dec 29 20:52 disk.1

lrwxrwxrwx 1 oneadmin oneadmin 36 Dec 29 20:52 disk.1.iso - 
/var/lib/one/datastores/100/1/disk.1

-rw-r--r-- 1 oneadmin oneadmin922 Dec 29 20:52 deployment.0


It clones disk.0 to the appropriate directory in the local system datastore

but we get a permission denied when we try to launch the VM.


The fix, is to hack the clone script to chmod the file to 664 and then the VM 
will launch.


--

The relevant configurations, we think:


Non-default settings in qemu.conf


[root@cloudworker1359 libvirt]# grep -v ^# qemu.conf | grep .

dynamic_ownership = 0


Non-default settings in libvirtd.conf:


[root@cloudworker1359 libvirt]# grep -v ^# libvirtd.conf | grep .

unix_sock_group = libvirtd

unix_sock_ro_perms = 0777

unix_sock_rw_perms = 0770

auth_unix_ro = none

auth_unix_rw = none

log_level = 2

log_outputs = 2:syslog:libvirtd

host_uuid = a68ca77f-dab0-5873-be6f-2216635204d1


[root@cloudworker1359 libvirt]# grep qemu /etc/passwd

qemu:x:107:107:qemu user:/:/sbin/nologin

[root@cloudworker1359 libvirt]# grep libvirt /etc/passwd

[root@cloudworker1359 libvirt]# grep qemu /etc/passwd

qemu:x:107:107:qemu user:/:/sbin/nologin

[root@cloudworker1359 libvirt]# grep oneadmin /etc/passwd

oneadmin:x:44897:10040::/var/lib/one:/bin/bash

[root@cloudworker1359 libvirt]# grep qemu /etc/group

disk:x:6:qemu

kvm:x:36:qemu

qemu:x:107:

oneadmin:x:10040:qemu





Three questions:


1) why can the VM not be launched with the default permissions

2) are there any system configurations I can fix to make it launch?

3) If I have to continue patching the tm/shared/clone script is there any way to

   push it out to the other nodes?  one host sync doesn't appear to change 
the remotes.


Steve Timm





___
Users mailing list
Users@lists.opennebula.org
http://lists.opennebula.org/listinfo.cgi/users-opennebula.org