Re: [ovirt-users] gluster VM disk permissions

[Richard W.M. Jones]

As it says in the error message:

> Try running qemu directly without libvirt using this environment variable:
> export LIBGUESTFS_BACKEND=direct

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] gluster VM disk permissions

[Bill James]

I just tried importing using the import script and got this error:

[root@ovirt1 prod ~]# import-to-ovirt.pl 
/mnt/tmp/puppetdb.j2noc.com.disk.xm 
/rhev/data-center/mnt/j2hqnap02:_vol_ovirt__inside__export_exportTemplates

libvirt needs authentication to connect to libvirt URI qemu:///system
(see also: http://libvirt.org/auth.html http://libvirt.org/uri.html)
Please enter your authentication name: vdsm@ovirt
Please enter your password:
could not create appliance through libvirt.

Try running qemu directly without libvirt using this environment variable:
export LIBGUESTFS_BACKEND=direct

Original error from libvirt: internal error: process exited while 
connecting to monitor: 2016-05-24T18:10:21.651694Z qemu-kvm: -drive 
file=/tmp/libguestfsWx9FbI/overlay1,if=none,id=drive-scsi0-0-0-0,format=qcow2,cache=unsafe: 
Could not open '/tmp/libguestfsWx9FbI/overlay1': Permission denied

 [code=1 domain=10] at /usr/local/bin/import-to-ovirt.pl line 233.


I believe this is the same error that prompted me to use "user = root" 
in qemu.conf, but sounds like there is a better resolution?





[root@ovirt1 prod qemu]# less guestfs-7ogk4gszrvsyv7j7.log
2016-05-24 18:10:21.617+: starting up libvirt version: 1.2.17, 
package: 13.el7_2.4 (CentOS BuildSystem , 
2016-03-31-16:56:26, worker1.bsys.centos.org), qemu version: 2.3.0 
(qemu-kvm-ev-2.3.0-31.el7_2.4.1)
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin 
QEMU_AUDIO_DRV=none TMPDIR=/var/tmp /usr/libexec/qemu-kvm -name 
guestfs-7ogk4gszrvsyv7j7 -S -machine 
pc-i440fx-rhel7.2.0,accel=kvm,usb=off -cpu host -m 500 -realtime 
mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 
ceeecdda-e44e-4227-990d-84261d0161aa -nographic -no-user-config 
-nodefaults -device sga -chardev 
socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-guestfs-7ogk4gszrvsyv7j7/monitor.sock,server,nowait 
-mon chardev=charmonitor,id=monitor,mode=control -rtc 
base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet 
-no-reboot -no-acpi -boot strict=on -kernel 
/var/tmp/.guestfs-0/appliance.d/kernel -initrd 
/var/tmp/.guestfs-0/appliance.d/initrd -append panic=1 console=ttyS0 
udevtimeout=6000 udev.event-timeout=6000 no_timer_check acpi=off 
printk.time=1 cgroup_disable=memory root=/dev/sdb selinux=0 TERM=screen 
-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device 
virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x2 -device 
virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 -drive 
file=/tmp/libguestfsWx9FbI/overlay1,if=none,id=drive-scsi0-0-0-0,format=qcow2,cache=unsafe 
-device 
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 
-drive 
file=/tmp/libguestfsWx9FbI/overlay2,if=none,id=drive-scsi0-0-1-0,format=qcow2,cache=unsafe 
-device 
scsi-hd,bus=scsi0.0,channel=0,scsi-id=1,lun=0,drive=drive-scsi0-0-1-0,id=scsi0-0-1-0 
-chardev socket,id=charserial0,path=/tmp/libguestfsWx9FbI/console.sock 
-device isa-serial,chardev=charserial0,id=serial0 -chardev 
socket,id=charchannel0,path=/tmp/libguestfsWx9FbI/guestfsd.sock -device 
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.libguestfs.channel.0 
-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on

Domain id=5 is tainted: custom-argv
Domain id=5 is tainted: host-cpu
2016-05-24T18:10:21.651694Z qemu-kvm: -drive 
file=/tmp/libguestfsWx9FbI/overlay1,if=none,id=drive-scsi0-0-0-0,format=qcow2,cache=unsafe: 
Could not open '/tmp/libguestfsWx9FbI/overlay1': Permission denied

2016-05-24 18:10:21.825+: shutting down



[root@ovirt1 prod ~]# ps -e -o 
euser,user,suser,fuser,egroup,rgroup,sgroup,fgroup,cmd | egrep 
'qemu-kvm'|head -2
qemu qemu qemu qemu qemu qemu qemu qemu 
/usr/libexec/qemu-kvm -name billj6-1.j2noc.com -S -machine 
pc-i440fx-rhel7.2.0,accel=kvm,usb=off -cpu SandyBridge -m 
size=2097152k,slots=16,maxmem=4294967296k -realtime mlock=off -smp 
1,maxcpus=16,sockets=16,cores=1,threads=1 -numa 
node,nodeid=0,cpus=0,mem=2048 -uuid 60ded316-aa18-4eda-9c52-16016d026e1a 
-smbios type=1,manufacturer=oVirt,product=oVirt 
Node,version=7-2.1511.el7.centos.2.10,serial=30343536-3138-584D-51





On 05/23/2016 09:17 AM, Richard W.M. Jones wrote:

On Mon, May 23, 2016 at 09:00:48AM -0700, Bill James wrote:

thank you very much for the reply.
My main question now is does it required to use "user = root" in
qemu.conf for the import script to work?

I haven't knowingly modified qemu.conf in my life, so likely the
answer is no.

Rich.




Cloud Services for Business www.j2.com
j2 | eFax | eVoice | FuseMail | Campaigner | KeepItSafe | Onebox


This email, its contents and attachments contain information from j2 Global, 
Inc. and/or its affiliates which may be privileged, confidential or otherwise 
protected from disclosure. The information is intended to be for the 
addressee(s) only. If you are not an addressee, any disclosure, copy, 
distribution, or use of the 

Re: [ovirt-users] gluster VM disk permissions

[Richard W.M. Jones]

On Mon, May 23, 2016 at 09:00:48AM -0700, Bill James wrote:
> thank you very much for the reply.
> My main question now is does it required to use "user = root" in
> qemu.conf for the import script to work?

I haven't knowingly modified qemu.conf in my life, so likely the
answer is no.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] gluster VM disk permissions

[Bill James]

thank you very much for the reply.
My main question now is does it required to use "user = root" in 
qemu.conf for the import script to work?
I know in my earlier testing I got a permissions error when doing import 
until I added the root user line.


I guess I'll take it out and give it a try.



On 05/21/2016 01:52 AM, Richard W.M. Jones wrote:

On Fri, May 20, 2016 at 02:53:02PM -0700, Bill James wrote:

maybe the other doc is old but it says:
"And a feature I intentionally removed in RHEL 7 was importing KVM → KVM"
which is what I am doing. raw disk KVM to ovirt.

Yes I can copy the disk image over the top of a ovirt disk image,
but the import script seemed cleaner.

Does virt-v2v try to convert the KVM image to KVM image or does it
just import it?

Virt-v2v will now refuse to do this at all (except if you "trick" it
as I did in my blog posting), but if we allowed it then it would make
all kinds of modifications inside the guest which you don't need and
have at least the potential to break things.

The import-to-ovirt.pl script is/was intended as a simple import
script which you should use instead in the case where guests already
run on KVM and therefore don't need driver etc conversion/
installation.

As Nir said in the other reply, oVirt 4.0 has native import
functionality and the import script is not needed at all for KVM ->
oVirt imports.

Virt-v2v should only be used for foreign hypervisor imports, such as
VMware, Xen or Hyper-V to oVirt.

Rich.




Cloud Services for Business www.j2.com
j2 | eFax | eVoice | FuseMail | Campaigner | KeepItSafe | Onebox


This email, its contents and attachments contain information from j2 Global, 
Inc. and/or its affiliates which may be privileged, confidential or otherwise 
protected from disclosure. The information is intended to be for the 
addressee(s) only. If you are not an addressee, any disclosure, copy, 
distribution, or use of the contents of this message is prohibited. If you have 
received this email in error please notify the sender by reply e-mail and 
delete the original message and any copies. (c) 2015 j2 Global, Inc. All rights 
reserved. eFax, eVoice, Campaigner, FuseMail, KeepItSafe, and Onebox are 
registered trademarks of j2 Global, Inc. and its affiliates.
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] gluster VM disk permissions

[Richard W.M. Jones]

On Fri, May 20, 2016 at 02:53:02PM -0700, Bill James wrote:
> maybe the other doc is old but it says:
> "And a feature I intentionally removed in RHEL 7 was importing KVM → KVM"
> which is what I am doing. raw disk KVM to ovirt.
> 
> Yes I can copy the disk image over the top of a ovirt disk image,
> but the import script seemed cleaner.
> 
> Does virt-v2v try to convert the KVM image to KVM image or does it
> just import it?

Virt-v2v will now refuse to do this at all (except if you "trick" it
as I did in my blog posting), but if we allowed it then it would make
all kinds of modifications inside the guest which you don't need and
have at least the potential to break things.

The import-to-ovirt.pl script is/was intended as a simple import
script which you should use instead in the case where guests already
run on KVM and therefore don't need driver etc conversion/
installation.

As Nir said in the other reply, oVirt 4.0 has native import
functionality and the import script is not needed at all for KVM ->
oVirt imports.

Virt-v2v should only be used for foreign hypervisor imports, such as
VMware, Xen or Hyper-V to oVirt.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] gluster VM disk permissions

[Nir Soffer]

On Sat, May 21, 2016 at 12:53 AM, Bill James  wrote:
> maybe the other doc is old but it says:
> "And a feature I intentionally removed in RHEL 7 was importing KVM → KVM"
> which is what I am doing. raw disk KVM to ovirt.
>
> Yes I can copy the disk image over the top of a ovirt disk image, but the
> import script seemed cleaner.
>
> Does virt-v2v try to convert the KVM image to KVM image or does it just
> import it?

ovirt-4.0 beta released 2 days ago support this.

One issue, a new package is needed which is not required yet by vdsm,
you will have to install it manually from here:
https://github.com/oVirt/ovirt-imageio/archive/master.zip

To install the package, do:

cd ovirt-imageio/common
make rpm
yum install dist/ovirt-imageio-common-0.1-1.noarch.rpm

This issue will be resolved soon.

Nir

>
>
>
>
>
> On 5/20/16 2:44 PM, Nir Soffer wrote:
>>
>> On Fri, May 20, 2016 at 11:48 PM, Bill James  wrote:
>>>
>>> I had added user = "root" because we use the import-to-ovirt.pl to move
>>> Vms
>>> from our old virtual platform to ovirt.
>>> My understanding was that was required for the to work.
>>> Is that not true or is the import script not worth the headaches caused?
>>>
>>> (https://rwmj.wordpress.com/2015/09/18/importing-kvm-guests-to-ovirt-or-rhev/)
>>
>> I don't know anything about this solution, adding Richard to add more
>> info.
>>
>> If you run 3.6, you can use v2v to import from other systems.
>> Adding Shahar to add into on v2v.
>>
>> Nir
>>
>>> [root@ovirt3 prod 4c4bfdf7-bc70-41b2-ab58-710ff8e850bf]# grep ^user
>>> /etc/libvirt/qemu.conf
>>> user = "root"
>>>
>>> I'm assuming that's what sets the qemu user.
>>>
>>>
>>>
>>> When I first tried using that script without setting "user = root" it
>>> didn't
>>> work.
>>>
>>>
>>>
>>>
>>> On 5/20/16 1:16 PM, Nir Soffer wrote:

 On Fri, May 20, 2016 at 10:41 PM, Bill James  wrote:
>
> attached output from one host. others look similar.

 Your qemu runs as *root*:

   root root root root qemu qemu qemu qemu /usr/libexec/qemu-kvm

 Here is the output from normal installation:

   qemu qemu qemu qemu qemu qemu qemu
 qemu /usr/libexec/qemu-kvm

 I guess that gluster is configure with "option root-squashing on" so you
 practically run as "nobody", and you are not in the kvm group.

 Running qemu as root is also a security risk, if there is a security bug
 in qemu
 a vm can use it to compromise your host or other vms.

 Maybe you can configure gluster to treat root as vdsm using

   option translate-uid 0=36

 See

 http://www.gluster.org/community/documentation/index.php/Translators/features

 But a better solution is to run qemu as qemu.

 Adding Sahina to advise about gluster configuration.

 Nir

>
>
> On 5/20/16 11:47 AM, Nir Soffer wrote:
>
> On Fri, May 20, 2016 at 9:25 PM, Bill James  wrote:
>>
>> yes
>>
>> [root@ovirt2 prod .shard]# sestatus
>> SELinux status: disabled
>>
>> [root@ovirt3 prod ~]# sestatus
>> SELinux status: disabled
>
>
> Can  you share output of:
>
> ps -e -o euser,user,suser,fuser,egroup,rgroup,sgroup,fgroup,cmd | egrep
> 'qemu|libvirt'
> ps auxe | egrep 'qemu|libvirt'
>
>>
>>
>>
>> On 5/20/16 11:13 AM, Nir Soffer wrote:
>>
>> On Fri, May 20, 2016 at 9:02 PM, Bill James  wrote:
>>>
>>> [root@ovirt1 prod ~]# sestatus
>>> SELinux status: disabled
>>
>>
>> Same on ovirt2?
>>
>>>
>>>
>>>
>>> On 5/20/16 10:49 AM, Nir Soffer wrote:
>>>
>>> This smells like selinux issues, did yoi try with permissive mode?
>>>
>>> בתאריך 20 במאי 2016 7:59 אחה״צ,‏ "Bill James" 
>>> כתב:

 Nobody has any ideas or thoughts on how to troubleshoot?

 why does qemu group work but not kvm when qemu is part of kvm group?

 [root@ovirt1 prod vdsm]# grep qemu /etc/group
 cdrom:x:11:qemu
 kvm:x:36:qemu,sanlock
 qemu:x:107:vdsm,sanlock


 On 5/18/16 3:47 PM, Bill James wrote:
>
> another data point.
> Changing just owner to qemu doesn't help.
> Changing just group to qemu does. VM starts fine after that.
>
>
>
> On 05/18/2016 11:49 AM, Bill James wrote:
>>
>> Some added info. This issue seems to be just like this bug:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1052114
>>
>> I have verified that chown qemu:qemu of disk image also fixes the
>> startup issue.
>> I'm using raw, not qcow images.
>>
>>
>> [root@ovirt2 prod 

Re: [ovirt-users] gluster VM disk permissions

[Bill James]

maybe the other doc is old but it says:
"And a feature I intentionally removed in RHEL 7 was importing KVM → KVM"
which is what I am doing. raw disk KVM to ovirt.

Yes I can copy the disk image over the top of a ovirt disk image, but 
the import script seemed cleaner.


Does virt-v2v try to convert the KVM image to KVM image or does it just 
import it?





On 5/20/16 2:44 PM, Nir Soffer wrote:

On Fri, May 20, 2016 at 11:48 PM, Bill James  wrote:

I had added user = "root" because we use the import-to-ovirt.pl to move Vms
from our old virtual platform to ovirt.
My understanding was that was required for the to work.
Is that not true or is the import script not worth the headaches caused?
(https://rwmj.wordpress.com/2015/09/18/importing-kvm-guests-to-ovirt-or-rhev/)

I don't know anything about this solution, adding Richard to add more info.

If you run 3.6, you can use v2v to import from other systems.
Adding Shahar to add into on v2v.

Nir


[root@ovirt3 prod 4c4bfdf7-bc70-41b2-ab58-710ff8e850bf]# grep ^user
/etc/libvirt/qemu.conf
user = "root"

I'm assuming that's what sets the qemu user.



When I first tried using that script without setting "user = root" it didn't
work.




On 5/20/16 1:16 PM, Nir Soffer wrote:

On Fri, May 20, 2016 at 10:41 PM, Bill James  wrote:

attached output from one host. others look similar.

Your qemu runs as *root*:

  root root root root qemu qemu qemu qemu /usr/libexec/qemu-kvm

Here is the output from normal installation:

  qemu qemu qemu qemu qemu qemu qemu
qemu /usr/libexec/qemu-kvm

I guess that gluster is configure with "option root-squashing on" so you
practically run as "nobody", and you are not in the kvm group.

Running qemu as root is also a security risk, if there is a security bug
in qemu
a vm can use it to compromise your host or other vms.

Maybe you can configure gluster to treat root as vdsm using

  option translate-uid 0=36

See
http://www.gluster.org/community/documentation/index.php/Translators/features

But a better solution is to run qemu as qemu.

Adding Sahina to advise about gluster configuration.

Nir




On 5/20/16 11:47 AM, Nir Soffer wrote:

On Fri, May 20, 2016 at 9:25 PM, Bill James  wrote:

yes

[root@ovirt2 prod .shard]# sestatus
SELinux status: disabled

[root@ovirt3 prod ~]# sestatus
SELinux status: disabled


Can  you share output of:

ps -e -o euser,user,suser,fuser,egroup,rgroup,sgroup,fgroup,cmd | egrep
'qemu|libvirt'
ps auxe | egrep 'qemu|libvirt'





On 5/20/16 11:13 AM, Nir Soffer wrote:

On Fri, May 20, 2016 at 9:02 PM, Bill James  wrote:

[root@ovirt1 prod ~]# sestatus
SELinux status: disabled


Same on ovirt2?





On 5/20/16 10:49 AM, Nir Soffer wrote:

This smells like selinux issues, did yoi try with permissive mode?

בתאריך 20 במאי 2016 7:59 אחה״צ,‏ "Bill James"  כתב:

Nobody has any ideas or thoughts on how to troubleshoot?

why does qemu group work but not kvm when qemu is part of kvm group?

[root@ovirt1 prod vdsm]# grep qemu /etc/group
cdrom:x:11:qemu
kvm:x:36:qemu,sanlock
qemu:x:107:vdsm,sanlock


On 5/18/16 3:47 PM, Bill James wrote:

another data point.
Changing just owner to qemu doesn't help.
Changing just group to qemu does. VM starts fine after that.



On 05/18/2016 11:49 AM, Bill James wrote:

Some added info. This issue seems to be just like this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1052114

I have verified that chown qemu:qemu of disk image also fixes the
startup issue.
I'm using raw, not qcow images.


[root@ovirt2 prod a7af2477-4a19-4f01-9de1-c939c99e53ad]# qemu-img
info 253f9615-f111-45ca-bdce-cbc9e70406df
image: 253f9615-f111-45ca-bdce-cbc9e70406df
file format: raw
virtual size: 20G (21474836480 bytes)
disk size: 1.9G
[root@ovirt2 prod a7af2477-4a19-4f01-9de1-c939c99e53ad]# ls -l
253f9615-f111-45ca-bdce-cbc9e70406df
-rw-rw 1 qemu qemu 21474836480 May 18 11:38
253f9615-f111-45ca-bdce-cbc9e70406df

(default perms = vdsm:kvm)

qemu-img-ev-2.3.0-31.el7_2.4.1.x86_64
qemu-kvm-ev-2.3.0-31.el7_2.4.1.x86_64
libvirt-daemon-1.2.17-13.el7_2.4.x86_64


Ideas??


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


This email, its contents and attachments contain information from j2
Global, Inc. and/or its affiliates which may be privileged, confidential or
otherwise protected from disclosure. The information is intended to be for
the addressee(s) only. If you are not an addressee, any disclosure, copy,
distribution, or use of the contents of this message is prohibited. If you
have received this email in error please notify the sender by reply e-mail
and delete the original message and any copies. © 2015 j2 Global, Inc. All
rights reserved. eFax ®, eVoice ®, Campaigner ®, FuseMail ®, KeepItSafe ®
and Onebox ® are ! registere d trademarks of j2 

Re: [ovirt-users] gluster VM disk permissions

[Nir Soffer]

On Fri, May 20, 2016 at 11:48 PM, Bill James  wrote:
> I had added user = "root" because we use the import-to-ovirt.pl to move Vms
> from our old virtual platform to ovirt.
> My understanding was that was required for the to work.
> Is that not true or is the import script not worth the headaches caused?
> (https://rwmj.wordpress.com/2015/09/18/importing-kvm-guests-to-ovirt-or-rhev/)

I don't know anything about this solution, adding Richard to add more info.

If you run 3.6, you can use v2v to import from other systems.
Adding Shahar to add into on v2v.

Nir

> [root@ovirt3 prod 4c4bfdf7-bc70-41b2-ab58-710ff8e850bf]# grep ^user
> /etc/libvirt/qemu.conf
> user = "root"
>
> I'm assuming that's what sets the qemu user.
>
>
>
> When I first tried using that script without setting "user = root" it didn't
> work.
>
>
>
>
> On 5/20/16 1:16 PM, Nir Soffer wrote:
>>
>> On Fri, May 20, 2016 at 10:41 PM, Bill James  wrote:
>>>
>>> attached output from one host. others look similar.
>>
>> Your qemu runs as *root*:
>>
>>  root root root root qemu qemu qemu qemu /usr/libexec/qemu-kvm
>>
>> Here is the output from normal installation:
>>
>>  qemu qemu qemu qemu qemu qemu qemu
>> qemu /usr/libexec/qemu-kvm
>>
>> I guess that gluster is configure with "option root-squashing on" so you
>> practically run as "nobody", and you are not in the kvm group.
>>
>> Running qemu as root is also a security risk, if there is a security bug
>> in qemu
>> a vm can use it to compromise your host or other vms.
>>
>> Maybe you can configure gluster to treat root as vdsm using
>>
>>  option translate-uid 0=36
>>
>> See
>> http://www.gluster.org/community/documentation/index.php/Translators/features
>>
>> But a better solution is to run qemu as qemu.
>>
>> Adding Sahina to advise about gluster configuration.
>>
>> Nir
>>
>>>
>>>
>>>
>>> On 5/20/16 11:47 AM, Nir Soffer wrote:
>>>
>>> On Fri, May 20, 2016 at 9:25 PM, Bill James  wrote:

 yes

 [root@ovirt2 prod .shard]# sestatus
 SELinux status: disabled

 [root@ovirt3 prod ~]# sestatus
 SELinux status: disabled
>>>
>>>
>>> Can  you share output of:
>>>
>>> ps -e -o euser,user,suser,fuser,egroup,rgroup,sgroup,fgroup,cmd | egrep
>>> 'qemu|libvirt'
>>> ps auxe | egrep 'qemu|libvirt'
>>>




 On 5/20/16 11:13 AM, Nir Soffer wrote:

 On Fri, May 20, 2016 at 9:02 PM, Bill James  wrote:
>
> [root@ovirt1 prod ~]# sestatus
> SELinux status: disabled


 Same on ovirt2?

>
>
>
>
> On 5/20/16 10:49 AM, Nir Soffer wrote:
>
> This smells like selinux issues, did yoi try with permissive mode?
>
> בתאריך 20 במאי 2016 7:59 אחה״צ,‏ "Bill James"  כתב:
>>
>> Nobody has any ideas or thoughts on how to troubleshoot?
>>
>> why does qemu group work but not kvm when qemu is part of kvm group?
>>
>> [root@ovirt1 prod vdsm]# grep qemu /etc/group
>> cdrom:x:11:qemu
>> kvm:x:36:qemu,sanlock
>> qemu:x:107:vdsm,sanlock
>>
>>
>> On 5/18/16 3:47 PM, Bill James wrote:
>>>
>>> another data point.
>>> Changing just owner to qemu doesn't help.
>>> Changing just group to qemu does. VM starts fine after that.
>>>
>>>
>>>
>>> On 05/18/2016 11:49 AM, Bill James wrote:

 Some added info. This issue seems to be just like this bug:
 https://bugzilla.redhat.com/show_bug.cgi?id=1052114

 I have verified that chown qemu:qemu of disk image also fixes the
 startup issue.
 I'm using raw, not qcow images.


 [root@ovirt2 prod a7af2477-4a19-4f01-9de1-c939c99e53ad]# qemu-img
 info 253f9615-f111-45ca-bdce-cbc9e70406df
 image: 253f9615-f111-45ca-bdce-cbc9e70406df
 file format: raw
 virtual size: 20G (21474836480 bytes)
 disk size: 1.9G
 [root@ovirt2 prod a7af2477-4a19-4f01-9de1-c939c99e53ad]# ls -l
 253f9615-f111-45ca-bdce-cbc9e70406df
 -rw-rw 1 qemu qemu 21474836480 May 18 11:38
 253f9615-f111-45ca-bdce-cbc9e70406df

 (default perms = vdsm:kvm)

 qemu-img-ev-2.3.0-31.el7_2.4.1.x86_64
 qemu-kvm-ev-2.3.0-31.el7_2.4.1.x86_64
 libvirt-daemon-1.2.17-13.el7_2.4.x86_64


 Ideas??

>> ___
>> Users mailing list
>> Users@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>
>
> This email, its contents and attachments contain information from j2
> Global, Inc. and/or its affiliates which may be privileged, confidential 
> or
> otherwise protected from disclosure. The information is intended to be for
> the addressee(s) only. If you are not an 

Re: [ovirt-users] gluster VM disk permissions

[Bill James]

I had added user = "root" because we use the import-to-ovirt.pl to move 
Vms from our old virtual platform to ovirt.

My understanding was that was required for the to work.
Is that not true or is the import script not worth the headaches caused?
(https://rwmj.wordpress.com/2015/09/18/importing-kvm-guests-to-ovirt-or-rhev/)


[root@ovirt3 prod 4c4bfdf7-bc70-41b2-ab58-710ff8e850bf]# grep ^user 
/etc/libvirt/qemu.conf

user = "root"

I'm assuming that's what sets the qemu user.



When I first tried using that script without setting "user = root" it 
didn't work.




On 5/20/16 1:16 PM, Nir Soffer wrote:

On Fri, May 20, 2016 at 10:41 PM, Bill James  wrote:

attached output from one host. others look similar.

Your qemu runs as *root*:

 root root root root qemu qemu qemu qemu /usr/libexec/qemu-kvm

Here is the output from normal installation:

 qemu qemu qemu qemu qemu qemu qemu
qemu /usr/libexec/qemu-kvm

I guess that gluster is configure with "option root-squashing on" so you
practically run as "nobody", and you are not in the kvm group.

Running qemu as root is also a security risk, if there is a security bug in qemu
a vm can use it to compromise your host or other vms.

Maybe you can configure gluster to treat root as vdsm using

 option translate-uid 0=36

See 
http://www.gluster.org/community/documentation/index.php/Translators/features

But a better solution is to run qemu as qemu.

Adding Sahina to advise about gluster configuration.

Nir





On 5/20/16 11:47 AM, Nir Soffer wrote:

On Fri, May 20, 2016 at 9:25 PM, Bill James  wrote:

yes

[root@ovirt2 prod .shard]# sestatus
SELinux status: disabled

[root@ovirt3 prod ~]# sestatus
SELinux status: disabled


Can  you share output of:

ps -e -o euser,user,suser,fuser,egroup,rgroup,sgroup,fgroup,cmd | egrep 
'qemu|libvirt'
ps auxe | egrep 'qemu|libvirt'






On 5/20/16 11:13 AM, Nir Soffer wrote:

On Fri, May 20, 2016 at 9:02 PM, Bill James  wrote:

[root@ovirt1 prod ~]# sestatus
SELinux status: disabled


Same on ovirt2?






On 5/20/16 10:49 AM, Nir Soffer wrote:

This smells like selinux issues, did yoi try with permissive mode?

בתאריך 20 במאי 2016 7:59 אחה״צ,‏ "Bill James"  כתב:

Nobody has any ideas or thoughts on how to troubleshoot?

why does qemu group work but not kvm when qemu is part of kvm group?

[root@ovirt1 prod vdsm]# grep qemu /etc/group
cdrom:x:11:qemu
kvm:x:36:qemu,sanlock
qemu:x:107:vdsm,sanlock


On 5/18/16 3:47 PM, Bill James wrote:

another data point.
Changing just owner to qemu doesn't help.
Changing just group to qemu does. VM starts fine after that.



On 05/18/2016 11:49 AM, Bill James wrote:

Some added info. This issue seems to be just like this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1052114

I have verified that chown qemu:qemu of disk image also fixes the startup issue.
I'm using raw, not qcow images.


[root@ovirt2 prod a7af2477-4a19-4f01-9de1-c939c99e53ad]# qemu-img info 
253f9615-f111-45ca-bdce-cbc9e70406df
image: 253f9615-f111-45ca-bdce-cbc9e70406df
file format: raw
virtual size: 20G (21474836480 bytes)
disk size: 1.9G
[root@ovirt2 prod a7af2477-4a19-4f01-9de1-c939c99e53ad]# ls -l 
253f9615-f111-45ca-bdce-cbc9e70406df
-rw-rw 1 qemu qemu 21474836480 May 18 11:38 
253f9615-f111-45ca-bdce-cbc9e70406df

(default perms = vdsm:kvm)

qemu-img-ev-2.3.0-31.el7_2.4.1.x86_64
qemu-kvm-ev-2.3.0-31.el7_2.4.1.x86_64
libvirt-daemon-1.2.17-13.el7_2.4.x86_64


Ideas??


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


This email, its contents and attachments contain information from j2 Global, 
Inc. and/or its affiliates which may be privileged, confidential or otherwise 
protected from disclosure. The information is intended to be for the 
addressee(s) only. If you are not an addressee, any disclosure, copy, 
distribution, or use of the contents of this message is prohibited. If you have 
received this email in error please notify the sender by reply e-mail and 
delete the original message and any copies. © 2015 j2 Global, Inc. All rights 
reserved. eFax ®, eVoice ®, Campaigner ®, FuseMail ®, KeepItSafe ® and Onebox ® 
are ! registere d trademarks of j2 Global, Inc. and its affiliates.



This email, its contents and attachments contain information from j2 Global, 
Inc. and/or its affiliates which may be privileged, confidential or otherwise 
protected from disclosure. The information is intended to be for the 
addressee(s) only. If you are not an addressee, any disclosure, copy, 
distribution, or use of the contents of this message is prohibited. If you have 
received this email in error please notify the sender by reply e-mail and 
delete the original message and any copies. © 2015 j2 Global, Inc. All rights 
reserved. eFax ®, eVoice ®, Campaigner ®, FuseMail ®, KeepItSafe 

Re: [ovirt-users] gluster VM disk permissions

[Nir Soffer]

On Fri, May 20, 2016 at 10:41 PM, Bill James  wrote:
>
> attached output from one host. others look similar.

Your qemu runs as *root*:

root root root root qemu qemu qemu qemu /usr/libexec/qemu-kvm

Here is the output from normal installation:

qemu qemu qemu qemu qemu qemu qemu
qemu /usr/libexec/qemu-kvm

I guess that gluster is configure with "option root-squashing on" so you
practically run as "nobody", and you are not in the kvm group.

Running qemu as root is also a security risk, if there is a security bug in qemu
a vm can use it to compromise your host or other vms.

Maybe you can configure gluster to treat root as vdsm using

option translate-uid 0=36

See 
http://www.gluster.org/community/documentation/index.php/Translators/features

But a better solution is to run qemu as qemu.

Adding Sahina to advise about gluster configuration.

Nir

>
>
>
>
> On 5/20/16 11:47 AM, Nir Soffer wrote:
>
> On Fri, May 20, 2016 at 9:25 PM, Bill James  wrote:
>>
>> yes
>>
>> [root@ovirt2 prod .shard]# sestatus
>> SELinux status: disabled
>>
>> [root@ovirt3 prod ~]# sestatus
>> SELinux status: disabled
>
>
> Can  you share output of:
>
> ps -e -o euser,user,suser,fuser,egroup,rgroup,sgroup,fgroup,cmd | egrep 
> 'qemu|libvirt'
> ps auxe | egrep 'qemu|libvirt'
>
>>
>>
>>
>>
>>
>> On 5/20/16 11:13 AM, Nir Soffer wrote:
>>
>> On Fri, May 20, 2016 at 9:02 PM, Bill James  wrote:
>>>
>>> [root@ovirt1 prod ~]# sestatus
>>> SELinux status: disabled
>>
>>
>> Same on ovirt2?
>>
>>>
>>>
>>>
>>>
>>>
>>> On 5/20/16 10:49 AM, Nir Soffer wrote:
>>>
>>> This smells like selinux issues, did yoi try with permissive mode?
>>>
>>> בתאריך 20 במאי 2016 7:59 אחה״צ,‏ "Bill James"  כתב:

 Nobody has any ideas or thoughts on how to troubleshoot?

 why does qemu group work but not kvm when qemu is part of kvm group?

 [root@ovirt1 prod vdsm]# grep qemu /etc/group
 cdrom:x:11:qemu
 kvm:x:36:qemu,sanlock
 qemu:x:107:vdsm,sanlock


 On 5/18/16 3:47 PM, Bill James wrote:
>
> another data point.
> Changing just owner to qemu doesn't help.
> Changing just group to qemu does. VM starts fine after that.
>
>
>
> On 05/18/2016 11:49 AM, Bill James wrote:
>>
>> Some added info. This issue seems to be just like this bug:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1052114
>>
>> I have verified that chown qemu:qemu of disk image also fixes the 
>> startup issue.
>> I'm using raw, not qcow images.
>>
>>
>> [root@ovirt2 prod a7af2477-4a19-4f01-9de1-c939c99e53ad]# qemu-img info 
>> 253f9615-f111-45ca-bdce-cbc9e70406df
>> image: 253f9615-f111-45ca-bdce-cbc9e70406df
>> file format: raw
>> virtual size: 20G (21474836480 bytes)
>> disk size: 1.9G
>> [root@ovirt2 prod a7af2477-4a19-4f01-9de1-c939c99e53ad]# ls -l 
>> 253f9615-f111-45ca-bdce-cbc9e70406df
>> -rw-rw 1 qemu qemu 21474836480 May 18 11:38 
>> 253f9615-f111-45ca-bdce-cbc9e70406df
>>
>> (default perms = vdsm:kvm)
>>
>> qemu-img-ev-2.3.0-31.el7_2.4.1.x86_64
>> qemu-kvm-ev-2.3.0-31.el7_2.4.1.x86_64
>> libvirt-daemon-1.2.17-13.el7_2.4.x86_64
>>
>>
>> Ideas??
>>
>

 ___
 Users mailing list
 Users@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/users
>>>
>>>
>>> This email, its contents and attachments contain information from j2 
>>> Global, Inc. and/or its affiliates which may be privileged, confidential or 
>>> otherwise protected from disclosure. The information is intended to be for 
>>> the addressee(s) only. If you are not an addressee, any disclosure, copy, 
>>> distribution, or use of the contents of this message is prohibited. If you 
>>> have received this email in error please notify the sender by reply e-mail 
>>> and delete the original message and any copies. © 2015 j2 Global, Inc. All 
>>> rights reserved. eFax ®, eVoice ®, Campaigner ®, FuseMail ®, KeepItSafe ® 
>>> and Onebox ® are ! registere d trademarks of j2 Global, Inc. and its 
>>> affiliates.
>>
>>
>>
>> This email, its contents and attachments contain information from j2 Global, 
>> Inc. and/or its affiliates which may be privileged, confidential or 
>> otherwise protected from disclosure. The information is intended to be for 
>> the addressee(s) only. If you are not an addressee, any disclosure, copy, 
>> distribution, or use of the contents of this message is prohibited. If you 
>> have received this email in error please notify the sender by reply e-mail 
>> and delete the original message and any copies. © 2015 j2 Global, Inc. All 
>> rights reserved. eFax ®, eVoice ®, Campaigner ®, FuseMail ®, KeepItSafe ® 
>> and Onebox ® are ! registere d trademarks of j2 Global, Inc. and its 
>> affiliates.
>
>
>

Re: [ovirt-users] gluster VM disk permissions

[Bill James]

attached output from one host. others look similar.



On 5/20/16 11:47 AM, Nir Soffer wrote:
On Fri, May 20, 2016 at 9:25 PM, Bill James > wrote:


yes

[root@ovirt2 prod .shard]# sestatus
SELinux status: disabled

[root@ovirt3 prod ~]# sestatus
SELinux status: disabled


Can  you share output of:

ps -e -o euser,user,suser,fuser,egroup,rgroup,sgroup,fgroup,cmd | 
egrep 'qemu|libvirt'

ps auxe | egrep 'qemu|libvirt'





On 5/20/16 11:13 AM, Nir Soffer wrote:

On Fri, May 20, 2016 at 9:02 PM, Bill James > wrote:

[root@ovirt1 prod ~]# sestatus
SELinux status: disabled


Same on ovirt2?





On 5/20/16 10:49 AM, Nir Soffer wrote:


This smells like selinux issues, did yoi try with permissive
mode?

בתאריך 20 במאי 2016 7:59 אחה״צ,‏ "Bill James"
> כתב:

Nobody has any ideas or thoughts on how to troubleshoot?

why does qemu group work but not kvm when qemu is part
of kvm group?

[root@ovirt1 prod vdsm]# grep qemu /etc/group
cdrom:x:11:qemu
kvm:x:36:qemu,sanlock
qemu:x:107:vdsm,sanlock


On 5/18/16 3:47 PM, Bill James wrote:

another data point.
Changing just owner to qemu doesn't help.
Changing just group to qemu does. VM starts fine
after that.



On 05/18/2016 11:49 AM, Bill James wrote:

Some added info. This issue seems to be just
like this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1052114

I have verified that chown qemu:qemu of disk
image also fixes the startup issue.
I'm using raw, not qcow images.


[root@ovirt2 prod
a7af2477-4a19-4f01-9de1-c939c99e53ad]# qemu-img
info 253f9615-f111-45ca-bdce-cbc9e70406df
image: 253f9615-f111-45ca-bdce-cbc9e70406df
file format: raw
virtual size: 20G (21474836480 bytes)
disk size: 1.9G
[root@ovirt2 prod
a7af2477-4a19-4f01-9de1-c939c99e53ad]# ls -l
253f9615-f111-45ca-bdce-cbc9e70406df
-rw-rw 1 qemu qemu 21474836480 May 18 11:38
253f9615-f111-45ca-bdce-cbc9e70406df

(default perms = vdsm:kvm)

qemu-img-ev-2.3.0-31.el7_2.4.1.x86_64
qemu-kvm-ev-2.3.0-31.el7_2.4.1.x86_64
libvirt-daemon-1.2.17-13.el7_2.4.x86_64


Ideas??



___
Users mailing list
Users@ovirt.org 
http://lists.ovirt.org/mailman/listinfo/users



www.j2.com



This email, its contents and attachments contain information
from j2 Global, Inc

.
and/or its affiliates which may be privileged, confidential
or otherwise protected from disclosure. The information is
intended to be for the addressee(s) only. If you are not an
addressee, any disclosure, copy, distribution, or use of the
contents of this message is prohibited. If you have received
this email in error please notify the sender by reply e-mail
and delete the original message and any copies. © 2015 j2
Global, Inc . All rights reserved. eFax ®
, eVoice ® ,
Campaigner ® , FuseMail ®
, KeepItSafe ®
 and Onebox ®
 are ! registere d trademarks of j2
Global, Inc . and its affiliates.




www.j2.com



This email, its contents and attachments contain information from
j2 Global, Inc

.
and/or its affiliates which may be privileged, confidential or
otherwise protected from disclosure. The information is intended
to be for the addressee(s) only. If you are not an addressee, any
disclosure, copy, distribution, or use of the contents of this
message is prohibited. If you have received this email in error
please notify the sender by reply 

Re: [ovirt-users] gluster VM disk permissions

[Nir Soffer]

On Fri, May 20, 2016 at 9:25 PM, Bill James  wrote:

> yes
>
> [root@ovirt2 prod .shard]# sestatus
> SELinux status: disabled
>
> [root@ovirt3 prod ~]# sestatus
> SELinux status: disabled
>

Can  you share output of:

ps -e -o euser,user,suser,fuser,egroup,rgroup,sgroup,fgroup,cmd | egrep
'qemu|libvirt'
ps auxe | egrep 'qemu|libvirt'


>
>
>
>
> On 5/20/16 11:13 AM, Nir Soffer wrote:
>
> On Fri, May 20, 2016 at 9:02 PM, Bill James  wrote:
>
>> [root@ovirt1 prod ~]# sestatus
>> SELinux status: disabled
>>
>
> Same on ovirt2?
>
>
>>
>>
>>
>>
>> On 5/20/16 10:49 AM, Nir Soffer wrote:
>>
>> This smells like selinux issues, did yoi try with permissive mode?
>> בתאריך 20 במאי 2016 7:59 אחה״צ,‏ "Bill James" < 
>> bill.ja...@j2.com> כתב:
>>
>>> Nobody has any ideas or thoughts on how to troubleshoot?
>>>
>>> why does qemu group work but not kvm when qemu is part of kvm group?
>>>
>>> [root@ovirt1 prod vdsm]# grep qemu /etc/group
>>> cdrom:x:11:qemu
>>> kvm:x:36:qemu,sanlock
>>> qemu:x:107:vdsm,sanlock
>>>
>>>
>>> On 5/18/16 3:47 PM, Bill James wrote:
>>>
 another data point.
 Changing just owner to qemu doesn't help.
 Changing just group to qemu does. VM starts fine after that.



 On 05/18/2016 11:49 AM, Bill James wrote:

> Some added info. This issue seems to be just like this bug:
> https://bugzilla.redhat.com/show_bug.cgi?id=1052114
>
> I have verified that chown qemu:qemu of disk image also fixes the
> startup issue.
> I'm using raw, not qcow images.
>
>
> [root@ovirt2 prod a7af2477-4a19-4f01-9de1-c939c99e53ad]# qemu-img
> info 253f9615-f111-45ca-bdce-cbc9e70406df
> image: 253f9615-f111-45ca-bdce-cbc9e70406df
> file format: raw
> virtual size: 20G (21474836480 bytes)
> disk size: 1.9G
> [root@ovirt2 prod a7af2477-4a19-4f01-9de1-c939c99e53ad]# ls -l
> 253f9615-f111-45ca-bdce-cbc9e70406df
> -rw-rw 1 qemu qemu 21474836480 May 18 11:38
> 253f9615-f111-45ca-bdce-cbc9e70406df
>
> (default perms = vdsm:kvm)
>
> qemu-img-ev-2.3.0-31.el7_2.4.1.x86_64
> qemu-kvm-ev-2.3.0-31.el7_2.4.1.x86_64
> libvirt-daemon-1.2.17-13.el7_2.4.x86_64
>
>
> Ideas??
>
>

>>> ___
>>> Users mailing list
>>> Users@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/users
>>>
>>
>> [image: www.j2.com]
>> 
>>
>> This email, its contents and attachments contain information from j2
>> Global, Inc
>> .
>> and/or its affiliates which may be privileged, confidential or otherwise
>> protected from disclosure. The information is intended to be for the
>> addressee(s) only. If you are not an addressee, any disclosure, copy,
>> distribution, or use of the contents of this message is prohibited. If you
>> have received this email in error please notify the sender by reply e-mail
>> and delete the original message and any copies. © 2015 j2 Global, Inc
>> . All rights reserved. eFax ® ,
>> eVoice ® , Campaigner ®
>> , FuseMail ® , 
>> KeepItSafe
>> ®  and Onebox ®  are
>> ! registere d trademarks of j2 Global, Inc . and its
>> affiliates.
>>
>
>
> [image: www.j2.com]
> 
>
> This email, its contents and attachments contain information from j2
> Global, Inc
> .
> and/or its affiliates which may be privileged, confidential or otherwise
> protected from disclosure. The information is intended to be for the
> addressee(s) only. If you are not an addressee, any disclosure, copy,
> distribution, or use of the contents of this message is prohibited. If you
> have received this email in error please notify the sender by reply e-mail
> and delete the original message and any copies. © 2015 j2 Global, Inc
> . All rights reserved. eFax ® , 
> eVoice
> ® , Campaigner ® , 
> FuseMail
> ® , KeepItSafe ® 
> and Onebox ®  are ! registere d trademarks of j2
> Global, Inc . and its affiliates.
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] gluster VM disk permissions

[Bill James]

yes

[root@ovirt2 prod .shard]# sestatus
SELinux status: disabled

[root@ovirt3 prod ~]# sestatus
SELinux status: disabled



On 5/20/16 11:13 AM, Nir Soffer wrote:
On Fri, May 20, 2016 at 9:02 PM, Bill James > wrote:


[root@ovirt1 prod ~]# sestatus
SELinux status: disabled


Same on ovirt2?





On 5/20/16 10:49 AM, Nir Soffer wrote:


This smells like selinux issues, did yoi try with permissive mode?

בתאריך 20 במאי 2016 7:59 אחה״צ,‏ "Bill James" > כתב:

Nobody has any ideas or thoughts on how to troubleshoot?

why does qemu group work but not kvm when qemu is part of kvm
group?

[root@ovirt1 prod vdsm]# grep qemu /etc/group
cdrom:x:11:qemu
kvm:x:36:qemu,sanlock
qemu:x:107:vdsm,sanlock


On 5/18/16 3:47 PM, Bill James wrote:

another data point.
Changing just owner to qemu doesn't help.
Changing just group to qemu does. VM starts fine after that.



On 05/18/2016 11:49 AM, Bill James wrote:

Some added info. This issue seems to be just like
this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1052114

I have verified that chown qemu:qemu of disk image
also fixes the startup issue.
I'm using raw, not qcow images.


[root@ovirt2 prod
a7af2477-4a19-4f01-9de1-c939c99e53ad]# qemu-img info
253f9615-f111-45ca-bdce-cbc9e70406df
image: 253f9615-f111-45ca-bdce-cbc9e70406df
file format: raw
virtual size: 20G (21474836480 bytes)
disk size: 1.9G
[root@ovirt2 prod
a7af2477-4a19-4f01-9de1-c939c99e53ad]# ls -l
253f9615-f111-45ca-bdce-cbc9e70406df
-rw-rw 1 qemu qemu 21474836480 May 18 11:38
253f9615-f111-45ca-bdce-cbc9e70406df

(default perms = vdsm:kvm)

qemu-img-ev-2.3.0-31.el7_2.4.1.x86_64
qemu-kvm-ev-2.3.0-31.el7_2.4.1.x86_64
libvirt-daemon-1.2.17-13.el7_2.4.x86_64


Ideas??



___
Users mailing list
Users@ovirt.org 
http://lists.ovirt.org/mailman/listinfo/users



www.j2.com



This email, its contents and attachments contain information from
j2 Global, Inc

.
and/or its affiliates which may be privileged, confidential or
otherwise protected from disclosure. The information is intended
to be for the addressee(s) only. If you are not an addressee, any
disclosure, copy, distribution, or use of the contents of this
message is prohibited. If you have received this email in error
please notify the sender by reply e-mail and delete the original
message and any copies. © 2015 j2 Global, Inc
. All rights reserved. eFax ®
, eVoice ® ,
Campaigner ® , FuseMail ®
, KeepItSafe ®
 and Onebox ® 
are ! registere d trademarks of j2 Global, Inc
. and its affiliates.





Cloud Services for Business www.j2.com
j2 | eFax | eVoice | FuseMail | Campaigner | KeepItSafe | Onebox


This email, its contents and attachments contain information from j2 Global, 
Inc. and/or its affiliates which may be privileged, confidential or otherwise 
protected from disclosure. The information is intended to be for the 
addressee(s) only. If you are not an addressee, any disclosure, copy, 
distribution, or use of the contents of this message is prohibited. If you have 
received this email in error please notify the sender by reply e-mail and 
delete the original message and any copies. (c) 2015 j2 Global, Inc. All rights 
reserved. eFax, eVoice, Campaigner, FuseMail, KeepItSafe, and Onebox are 
registered trademarks of j2 Global, Inc. and its affiliates.
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] gluster VM disk permissions

[Nir Soffer]

On Fri, May 20, 2016 at 9:02 PM, Bill James  wrote:

> [root@ovirt1 prod ~]# sestatus
> SELinux status: disabled
>

Same on ovirt2?


>
>
>
>
> On 5/20/16 10:49 AM, Nir Soffer wrote:
>
> This smells like selinux issues, did yoi try with permissive mode?
> בתאריך 20 במאי 2016 7:59 אחה״צ,‏ "Bill James"  כתב:
>
>> Nobody has any ideas or thoughts on how to troubleshoot?
>>
>> why does qemu group work but not kvm when qemu is part of kvm group?
>>
>> [root@ovirt1 prod vdsm]# grep qemu /etc/group
>> cdrom:x:11:qemu
>> kvm:x:36:qemu,sanlock
>> qemu:x:107:vdsm,sanlock
>>
>>
>> On 5/18/16 3:47 PM, Bill James wrote:
>>
>>> another data point.
>>> Changing just owner to qemu doesn't help.
>>> Changing just group to qemu does. VM starts fine after that.
>>>
>>>
>>>
>>> On 05/18/2016 11:49 AM, Bill James wrote:
>>>
 Some added info. This issue seems to be just like this bug:
 https://bugzilla.redhat.com/show_bug.cgi?id=1052114

 I have verified that chown qemu:qemu of disk image also fixes the
 startup issue.
 I'm using raw, not qcow images.


 [root@ovirt2 prod a7af2477-4a19-4f01-9de1-c939c99e53ad]# qemu-img info
 253f9615-f111-45ca-bdce-cbc9e70406df
 image: 253f9615-f111-45ca-bdce-cbc9e70406df
 file format: raw
 virtual size: 20G (21474836480 bytes)
 disk size: 1.9G
 [root@ovirt2 prod a7af2477-4a19-4f01-9de1-c939c99e53ad]# ls -l
 253f9615-f111-45ca-bdce-cbc9e70406df
 -rw-rw 1 qemu qemu 21474836480 May 18 11:38
 253f9615-f111-45ca-bdce-cbc9e70406df

 (default perms = vdsm:kvm)

 qemu-img-ev-2.3.0-31.el7_2.4.1.x86_64
 qemu-kvm-ev-2.3.0-31.el7_2.4.1.x86_64
 libvirt-daemon-1.2.17-13.el7_2.4.x86_64


 Ideas??


>>>
>> ___
>> Users mailing list
>> Users@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
>
> [image: www.j2.com]
> 
>
> This email, its contents and attachments contain information from j2
> Global, Inc
> .
> and/or its affiliates which may be privileged, confidential or otherwise
> protected from disclosure. The information is intended to be for the
> addressee(s) only. If you are not an addressee, any disclosure, copy,
> distribution, or use of the contents of this message is prohibited. If you
> have received this email in error please notify the sender by reply e-mail
> and delete the original message and any copies. © 2015 j2 Global, Inc
> . All rights reserved. eFax ® , 
> eVoice
> ® , Campaigner ® , 
> FuseMail
> ® , KeepItSafe ® 
> and Onebox ®  are ! registere d trademarks of j2
> Global, Inc . and its affiliates.
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] gluster VM disk permissions

[Bill James]

[root@ovirt1 prod ~]# sestatus
SELinux status: disabled



On 5/20/16 10:49 AM, Nir Soffer wrote:


This smells like selinux issues, did yoi try with permissive mode?

בתאריך 20 במאי 2016 7:59 אחה״צ,‏ "Bill James" > כתב:


Nobody has any ideas or thoughts on how to troubleshoot?

why does qemu group work but not kvm when qemu is part of kvm group?

[root@ovirt1 prod vdsm]# grep qemu /etc/group
cdrom:x:11:qemu
kvm:x:36:qemu,sanlock
qemu:x:107:vdsm,sanlock


On 5/18/16 3:47 PM, Bill James wrote:

another data point.
Changing just owner to qemu doesn't help.
Changing just group to qemu does. VM starts fine after that.



On 05/18/2016 11:49 AM, Bill James wrote:

Some added info. This issue seems to be just like this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1052114

I have verified that chown qemu:qemu of disk image also
fixes the startup issue.
I'm using raw, not qcow images.


[root@ovirt2 prod a7af2477-4a19-4f01-9de1-c939c99e53ad]#
qemu-img info 253f9615-f111-45ca-bdce-cbc9e70406df
image: 253f9615-f111-45ca-bdce-cbc9e70406df
file format: raw
virtual size: 20G (21474836480 bytes)
disk size: 1.9G
[root@ovirt2 prod a7af2477-4a19-4f01-9de1-c939c99e53ad]#
ls -l 253f9615-f111-45ca-bdce-cbc9e70406df
-rw-rw 1 qemu qemu 21474836480 May 18 11:38
253f9615-f111-45ca-bdce-cbc9e70406df

(default perms = vdsm:kvm)

qemu-img-ev-2.3.0-31.el7_2.4.1.x86_64
qemu-kvm-ev-2.3.0-31.el7_2.4.1.x86_64
libvirt-daemon-1.2.17-13.el7_2.4.x86_64


Ideas??



___
Users mailing list
Users@ovirt.org 
http://lists.ovirt.org/mailman/listinfo/users




Cloud Services for Business www.j2.com
j2 | eFax | eVoice | FuseMail | Campaigner | KeepItSafe | Onebox


This email, its contents and attachments contain information from j2 Global, 
Inc. and/or its affiliates which may be privileged, confidential or otherwise 
protected from disclosure. The information is intended to be for the 
addressee(s) only. If you are not an addressee, any disclosure, copy, 
distribution, or use of the contents of this message is prohibited. If you have 
received this email in error please notify the sender by reply e-mail and 
delete the original message and any copies. (c) 2015 j2 Global, Inc. All rights 
reserved. eFax, eVoice, Campaigner, FuseMail, KeepItSafe, and Onebox are 
registered trademarks of j2 Global, Inc. and its affiliates.
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] gluster VM disk permissions

[Nir Soffer]

This smells like selinux issues, did yoi try with permissive mode?
בתאריך 20 במאי 2016 7:59 אחה״צ,‏ "Bill James"  כתב:

> Nobody has any ideas or thoughts on how to troubleshoot?
>
> why does qemu group work but not kvm when qemu is part of kvm group?
>
> [root@ovirt1 prod vdsm]# grep qemu /etc/group
> cdrom:x:11:qemu
> kvm:x:36:qemu,sanlock
> qemu:x:107:vdsm,sanlock
>
>
> On 5/18/16 3:47 PM, Bill James wrote:
>
>> another data point.
>> Changing just owner to qemu doesn't help.
>> Changing just group to qemu does. VM starts fine after that.
>>
>>
>>
>> On 05/18/2016 11:49 AM, Bill James wrote:
>>
>>> Some added info. This issue seems to be just like this bug:
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1052114
>>>
>>> I have verified that chown qemu:qemu of disk image also fixes the
>>> startup issue.
>>> I'm using raw, not qcow images.
>>>
>>>
>>> [root@ovirt2 prod a7af2477-4a19-4f01-9de1-c939c99e53ad]# qemu-img info
>>> 253f9615-f111-45ca-bdce-cbc9e70406df
>>> image: 253f9615-f111-45ca-bdce-cbc9e70406df
>>> file format: raw
>>> virtual size: 20G (21474836480 bytes)
>>> disk size: 1.9G
>>> [root@ovirt2 prod a7af2477-4a19-4f01-9de1-c939c99e53ad]# ls -l
>>> 253f9615-f111-45ca-bdce-cbc9e70406df
>>> -rw-rw 1 qemu qemu 21474836480 May 18 11:38
>>> 253f9615-f111-45ca-bdce-cbc9e70406df
>>>
>>> (default perms = vdsm:kvm)
>>>
>>> qemu-img-ev-2.3.0-31.el7_2.4.1.x86_64
>>> qemu-kvm-ev-2.3.0-31.el7_2.4.1.x86_64
>>> libvirt-daemon-1.2.17-13.el7_2.4.x86_64
>>>
>>>
>>> Ideas??
>>>
>>>
>>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] gluster VM disk permissions

[Bill James]

Nobody has any ideas or thoughts on how to troubleshoot?

why does qemu group work but not kvm when qemu is part of kvm group?

[root@ovirt1 prod vdsm]# grep qemu /etc/group
cdrom:x:11:qemu
kvm:x:36:qemu,sanlock
qemu:x:107:vdsm,sanlock


On 5/18/16 3:47 PM, Bill James wrote:

another data point.
Changing just owner to qemu doesn't help.
Changing just group to qemu does. VM starts fine after that.



On 05/18/2016 11:49 AM, Bill James wrote:

Some added info. This issue seems to be just like this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1052114

I have verified that chown qemu:qemu of disk image also fixes the 
startup issue.

I'm using raw, not qcow images.


[root@ovirt2 prod a7af2477-4a19-4f01-9de1-c939c99e53ad]# qemu-img 
info 253f9615-f111-45ca-bdce-cbc9e70406df

image: 253f9615-f111-45ca-bdce-cbc9e70406df
file format: raw
virtual size: 20G (21474836480 bytes)
disk size: 1.9G
[root@ovirt2 prod a7af2477-4a19-4f01-9de1-c939c99e53ad]# ls -l 
253f9615-f111-45ca-bdce-cbc9e70406df
-rw-rw 1 qemu qemu 21474836480 May 18 11:38 
253f9615-f111-45ca-bdce-cbc9e70406df


(default perms = vdsm:kvm)

qemu-img-ev-2.3.0-31.el7_2.4.1.x86_64
qemu-kvm-ev-2.3.0-31.el7_2.4.1.x86_64
libvirt-daemon-1.2.17-13.el7_2.4.x86_64


Ideas??





___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] gluster VM disk permissions

[Bill James]

another data point.
Changing just owner to qemu doesn't help.
Changing just group to qemu does. VM starts fine after that.



On 05/18/2016 11:49 AM, Bill James wrote:

Some added info. This issue seems to be just like this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1052114

I have verified that chown qemu:qemu of disk image also fixes the 
startup issue.

I'm using raw, not qcow images.


[root@ovirt2 prod a7af2477-4a19-4f01-9de1-c939c99e53ad]# qemu-img info 
253f9615-f111-45ca-bdce-cbc9e70406df

image: 253f9615-f111-45ca-bdce-cbc9e70406df
file format: raw
virtual size: 20G (21474836480 bytes)
disk size: 1.9G
[root@ovirt2 prod a7af2477-4a19-4f01-9de1-c939c99e53ad]# ls -l 
253f9615-f111-45ca-bdce-cbc9e70406df
-rw-rw 1 qemu qemu 21474836480 May 18 11:38 
253f9615-f111-45ca-bdce-cbc9e70406df


(default perms = vdsm:kvm)

qemu-img-ev-2.3.0-31.el7_2.4.1.x86_64
qemu-kvm-ev-2.3.0-31.el7_2.4.1.x86_64
libvirt-daemon-1.2.17-13.el7_2.4.x86_64


Ideas??



___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users