Re: [ovirt-users] gluster VM disk permissions

2016-05-24 Thread 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:

Re: [ovirt-users] gluster VM disk permissions

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

Re: [ovirt-users] gluster VM disk permissions

2016-05-23 Thread 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. --

Re: [ovirt-users] gluster VM disk permissions

2016-05-23 Thread 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.

Re: [ovirt-users] gluster VM disk permissions

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

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

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

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

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?

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

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

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

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:

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? > בתאריך

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

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

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.

Re: [ovirt-users] gluster VM disk permissions

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