[ovirt-users] Hosted engine setup fails - system unreliable

2016-05-20 Thread Bill Bill 
I’ve tried over & over on fresh installs to setup the hosted engine VM however, 
each time, it fails. No clue as to what the problem is as it just says “this 
system is unreliable”.

///

Log output:

///

2016-05-21 01:42:42 DEBUG otopi.context context.dumpEnvironment:510 ENV 
OVEHOSTED_VM/nicUUID=str:'58a28a5e-5d0e-4ac3-835a-a1e9b0df6ae6'
2016-05-21 01:42:42 DEBUG otopi.context context.dumpEnvironment:510 ENV 
OVEHOSTED_VM/ovfArchive=unicode:'/usr/share/ovirt-engine-appliance/ovirt-engine-appliance-3.6-20160420.1.el7.centos.ova'
2016-05-21 01:42:42 DEBUG otopi.context context.dumpEnvironment:510 ENV 
OVEHOSTED_VM/subst=dict:'{'@CDROM@': '/tmp/tmpTyL8IW/seed.iso', '@SD_UUID@': 
'2455aa81-146f-4a6e-bd6c-c368fa1d10b8', '@CONSOLE_UUID@': 
'bef503b1-4224-4d82-8acd-8b03d21ae60b', '@NAME@': 'HostedEngine', '@BRIDGE@': 
'ovirtmgmt', '@CDROM_UUID@': '4f64e8ba-5253-4b9c-b1a7-bc550e22f097', 
'@MEM_SIZE@': 4096, '@NIC_UUID@': '58a28a5e-5d0e-4ac3-835a-a1e9b0df6ae6', 
'@BOOT_CDROM@': '', '@VCPUS@': '4', '@CPU_TYPE@': 'SandyBridge', '@VM_UUID@': 
'8cc30bbf-8f4b-4fce-ae4a-ffd476baf2b3', '@EMULATED_MACHINE@': 'pc', 
'@BOOT_PXE@': '', '@IMG_UUID@': '4148fb72-73f1-4d8f-8368-5b6e1ddb4e96', 
'@BOOT_DISK@': ',bootOrder:1', '@CONSOLE_TYPE@': 'vnc', '@MAC_ADDR@': 
'00:16:3e:41:21:db', '@SP_UUID@': '----', 
'@VOL_UUID@': '9c175329-7d1a-4b51-8218-8a2512305684'}'
2016-05-21 01:42:42 DEBUG otopi.context context.dumpEnvironment:510 ENV 
OVEHOSTED_VM/vmBoot=str:'disk'
2016-05-21 01:42:42 DEBUG otopi.context context.dumpEnvironment:510 ENV 
OVEHOSTED_VM/vmCDRom=NoneType:'None'
2016-05-21 01:42:42 DEBUG otopi.context context.dumpEnvironment:510 ENV 
OVEHOSTED_VM/vmMACAddr=str:'00:16:3e:41:21:db'
2016-05-21 01:42:42 DEBUG otopi.context context.dumpEnvironment:510 ENV 
OVEHOSTED_VM/vmMemSizeMB=int:'4096'
2016-05-21 01:42:42 DEBUG otopi.context context.dumpEnvironment:510 ENV 
OVEHOSTED_VM/vmUUID=str:'8cc30bbf-8f4b-4fce-ae4a-ffd476baf2b3'
2016-05-21 01:42:42 DEBUG otopi.context context.dumpEnvironment:510 ENV 
OVEHOSTED_VM/vmVCpus=str:'4'
2016-05-21 01:42:42 DEBUG otopi.context context.dumpEnvironment:510 ENV 
OVESETUP_CORE/offlinePackager=bool:'True'
2016-05-21 01:42:42 DEBUG otopi.context context.dumpEnvironment:510 ENV 
PACKAGER/dnfDisabledPlugins=list:'[]'
2016-05-21 01:42:42 DEBUG otopi.context context.dumpEnvironment:510 ENV 
PACKAGER/dnfExpireCache=bool:'True'
2016-05-21 01:42:42 DEBUG otopi.context context.dumpEnvironment:510 ENV 
PACKAGER/dnfRollback=bool:'True'
2016-05-21 01:42:42 DEBUG otopi.context context.dumpEnvironment:510 ENV 
PACKAGER/dnfpackagerEnabled=bool:'True'
2016-05-21 01:42:42 DEBUG otopi.context context.dumpEnvironment:510 ENV 
PACKAGER/keepAliveInterval=int:'30'
2016-05-21 01:42:42 DEBUG otopi.context context.dumpEnvironment:510 ENV 
PACKAGER/yumDisabledPlugins=list:'[]'
2016-05-21 01:42:42 DEBUG otopi.context context.dumpEnvironment:510 ENV 
PACKAGER/yumEnabledPlugins=list:'[]'
2016-05-21 01:42:42 DEBUG otopi.context context.dumpEnvironment:510 ENV 
PACKAGER/yumExpireCache=bool:'True'
2016-05-21 01:42:42 DEBUG otopi.context context.dumpEnvironment:510 ENV 
PACKAGER/yumRollback=bool:'True'
2016-05-21 01:42:42 DEBUG otopi.context context.dumpEnvironment:510 ENV 
PACKAGER/yumpackagerEnabled=bool:'False'
2016-05-21 01:42:42 DEBUG otopi.context context.dumpEnvironment:510 ENV 
SYSTEM/clockMaxGap=int:'5'
2016-05-21 01:42:42 DEBUG otopi.context context.dumpEnvironment:510 ENV 
SYSTEM/clockSet=bool:'False'
2016-05-21 01:42:42 DEBUG otopi.context context.dumpEnvironment:510 ENV 
SYSTEM/commandPath=str:'/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
2016-05-21 01:42:42 DEBUG otopi.context context.dumpEnvironment:510 ENV 
SYSTEM/reboot=bool:'False'
2016-05-21 01:42:42 DEBUG otopi.context context.dumpEnvironment:510 ENV 
SYSTEM/rebootAllow=bool:'True'
2016-05-21 01:42:42 DEBUG otopi.context context.dumpEnvironment:510 ENV 
SYSTEM/rebootDeferTime=int:'10'
2016-05-21 01:42:42 DEBUG otopi.context context.dumpEnvironment:514 ENVIRONMENT 
DUMP - END
2016-05-21 01:42:42 DEBUG otopi.context context._executeMethod:142 Stage 
pre-terminate METHOD otopi.plugins.otopi.dialog.cli.Plugin._pre_terminate
2016-05-21 01:42:42 DEBUG otopi.context context._executeMethod:148 condition 
False
2016-05-21 01:42:42 INFO otopi.context context.runSequence:427 Stage: 
Termination
2016-05-21 01:42:42 DEBUG otopi.context context.runSequence:431 STAGE terminate
2016-05-21 01:42:42 DEBUG otopi.context context._executeMethod:142 Stage 
terminate METHOD 
otopi.plugins.ovirt_hosted_engine_setup.core.misc.Plugin._terminate
2016-05-21 01:42:42 ERROR otopi.plugins.ovirt_hosted_engine_setup.core.misc 
misc._terminate:170 Hosted Engine deployment failed: this system is not 
reliable, please check the issue, fix and redeploy
2016-05-21 01:42:42 DEBUG otopi.plugins.otopi.dialog.human 
dialog.__logString:219 DIALOG:SEND Log file is located at

Re: [ovirt-users] gluster VM disk permissions

2016-05-20 Thread 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

2016-05-20 Thread 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

2016-05-20 Thread 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

2016-05-20 Thread 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

2016-05-20 Thread 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

2016-05-20 Thread 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

2016-05-20 Thread 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

2016-05-20 Thread 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

2016-05-20 Thread 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

2016-05-20 Thread 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

2016-05-20 Thread 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

2016-05-20 Thread 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] [ovirt-devel] RFC - dropping ISO domain creation from engine-setup

2016-05-20 Thread Sandro Bonazzola 
On Fri, May 20, 2016 at 1:44 PM, Barak Korren  wrote:

> It seems to me we still need a way to provide the WTG ISOs. Maybe
> include an option in engine to upload them to the an ISO domain the
> user creates?
> Or perhaps find a way to make them available for use without defining
> an explicit ISO domain?
>

Here the issue is different.
when running engine-setup the WGT iso is injected while the iso domain is
not yet active.
At engine setup done, you'll have the engine, the inactive iso domain and
the iso within it but only if you create the iso domain with engine-setup.

If you run engine-setup, create your own iso domain, and then on upgrade
you run again engine-setup, WGT is not uploaded there.

So the existing WGT upload mechanism already is limited to only those
installations born with iso domain creation on the same host.

Since we have iso-uploader and we'll have in 4.1 the ISO uploaded from web
ui, I really think this mechanism can be dropped since it covers only what
it seems to be a corner case.







>
> On 20 May 2016 at 14:32, Sandro Bonazzola  wrote:
> > Hi,
> > I'd like to get comments on removing ISO domain creation from
> engine-setup.
> >
> > ISO domain creation was included in 3.2 for allowing to finish the setup
> > with ISO domain ready to serve Windows Guest Tools which is injected into
> > the iso domain if the rpm is installed.
> > The NFS share was created *(rw) in 3.2.
> > In later releases we first restricted access, then asked the user to
> provide
> > access policy during setup and now we moved the default to not create the
> > ISO domain.
> >
> > We have several issues with iso domain creation:
> >
> > Bug 1302745 - [engine-setup] creation of iso domain path is not rolled
> back,
> > a next attempt leaves an empty domain
> >
> > Bug 1332813 - Hosted engine should not allow iso domain to be configured
> in
> > the RHEV-M VM
> >
> > Having ISO domain within hosted engine leads to really bad issues and
> we're
> > streamlining the hosted engine installation with NGN, cockpit and
> appliance
> > so HE will be the most easy way to have oVirt installed making ISO domain
> > not useful and even dangerous in engine-setup.
> >
> > For this reason the bug has ben changed in: Deprecate the ISO domain
> setup
> > on the RHEV-M machine (hide it in 4.0)
> > Meaning that using answer file you'll be able to create it anyway in 4.0
> but
> > the question won't be exposed in interactive setup.
> >
> > Any concern about this change? Any comment?
> > Thanks,
> >
> >
> > --
> > Sandro Bonazzola
> > Better technology. Faster innovation. Powered by community collaboration.
> > See how it works at redhat.com
> >
> > ___
> > Devel mailing list
> > de...@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
>
>
>
> --
> Barak Korren
> bkor...@redhat.com
> RHEV-CI Team
>



-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] [ovirt-devel] RFC - dropping ISO domain creation from engine-setup

2016-05-20 Thread Barak Korren 
It seems to me we still need a way to provide the WTG ISOs. Maybe
include an option in engine to upload them to the an ISO domain the
user creates?
Or perhaps find a way to make them available for use without defining
an explicit ISO domain?

On 20 May 2016 at 14:32, Sandro Bonazzola  wrote:
> Hi,
> I'd like to get comments on removing ISO domain creation from engine-setup.
>
> ISO domain creation was included in 3.2 for allowing to finish the setup
> with ISO domain ready to serve Windows Guest Tools which is injected into
> the iso domain if the rpm is installed.
> The NFS share was created *(rw) in 3.2.
> In later releases we first restricted access, then asked the user to provide
> access policy during setup and now we moved the default to not create the
> ISO domain.
>
> We have several issues with iso domain creation:
>
> Bug 1302745 - [engine-setup] creation of iso domain path is not rolled back,
> a next attempt leaves an empty domain
>
> Bug 1332813 - Hosted engine should not allow iso domain to be configured in
> the RHEV-M VM
>
> Having ISO domain within hosted engine leads to really bad issues and we're
> streamlining the hosted engine installation with NGN, cockpit and appliance
> so HE will be the most easy way to have oVirt installed making ISO domain
> not useful and even dangerous in engine-setup.
>
> For this reason the bug has ben changed in: Deprecate the ISO domain setup
> on the RHEV-M machine (hide it in 4.0)
> Meaning that using answer file you'll be able to create it anyway in 4.0 but
> the question won't be exposed in interactive setup.
>
> Any concern about this change? Any comment?
> Thanks,
>
>
> --
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
>
> ___
> Devel mailing list
> de...@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel



-- 
Barak Korren
bkor...@redhat.com
RHEV-CI Team
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] RFC - dropping ISO domain creation from engine-setup

2016-05-20 Thread Sandro Bonazzola 
Hi,
I'd like to get comments on removing ISO domain creation from engine-setup.

ISO domain creation was included in 3.2 for allowing to finish the setup
with ISO domain ready to serve Windows Guest Tools which is injected into
the iso domain if the rpm is installed.
The NFS share was created *(rw) in 3.2.
In later releases we first restricted access, then asked the user to
provide access policy during setup and now we moved the default to not
create the ISO domain.

We have several issues with iso domain creation:

Bug 1302745  -
[engine-setup]
creation of iso domain path is not rolled back, a next attempt leaves an
empty domain

Bug 1332813  - Hosted
engine should not allow iso domain to be configured in the RHEV-M VM

Having ISO domain within hosted engine leads to really bad issues and we're
streamlining the hosted engine installation with NGN, cockpit and appliance
so HE will be the most easy way to have oVirt installed making ISO domain
not useful and even dangerous in engine-setup.

For this reason the bug has ben changed in: Deprecate the ISO domain setup
on the RHEV-M machine (hide it in 4.0)
Meaning that using answer file you'll be able to create it anyway in 4.0
but the question won't be exposed in interactive setup.

Any concern about this change? Any comment?
Thanks,


-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users