[Users] ovirt VM start fails - Perm Denied error

[Dan Kenigsberg]

On Wed, Feb 15, 2012 at 02:50:26PM +0530, Deepak C Shetty wrote:
> On 02/15/2012 01:27 PM, Dan Kenigsberg wrote:
> >On Wed, Feb 15, 2012 at 12:13:39PM +0530, Deepak C Shetty wrote:
> >>On 02/14/2012 02:55 PM, Dan Kenigsberg wrote:
> >>>On Tue, Feb 14, 2012 at 10:36:39AM +0530, Deepak C Shetty wrote:
> >>>>On 02/13/2012 03:16 PM, Dan Kenigsberg wrote:
> >>>>>On Sun, Feb 12, 2012 at 11:58:05PM +0530, Deepak C Shetty wrote:
> >>>>>>Hi,
> >>>>>>    I have tried this multiple times and i hit the same error.
> >>>>>>
> >>>>>>I have 3 storage domains  created (iso, data and export) all
> >>>>>>connected to the DC with DC status as Up and
> >>>>>>1 host with status as Up and the same (only) host acting as SPM.
> >>>>>>
> >>>>>>I used the engine-iso-uploader utility to upload my .iso to the iso domain.
> >>>>>>Created a new VM and attached a vdisk of type sparse (thin-prov) and
> >>>>>>click on "Run Once",
> >>>>>>where i select "Attach CD" and select my .iso, and change boot order
> >>>>>>to boot from CD, then disk.
> >>>>>>
> >>>>>>But i get this error...
> >>>>>>
> >>>>>>VM first-ovirt-vm is down. Exit message internal error process
> >>>>>>exited while connecting to monitor: qemu-kvm: -drive file=/rhev/data-center/4087fea7-b54a-4318-8d5c-828eff8846f4/35f880f8-bd0c-4063-b171-2ddaa59e1212/images/11111111-1111-1111-1111-111111111111/Fedora-16-x86_64-DVD.iso,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw:
> >>>>>>could not open disk image /rhev/data-center/4087fea7-b54a-4318-8d5c-828eff8846f4/35f880f8-bd0c-4063-b171-2ddaa59e1212/images/11111111-1111-1111-1111-111111111111/Fedora-16-x86_64-DVD.iso:
> >>>>>>Permission denied .
> >>>>>>
> >>>>>>I am unable to figure out why.. bcos the user.group perms for the
> >>>>>>.iso are fine.
> >>>>>>In fact i logged into the system serving the nfs share and added 0777 perms
> >>>>>>still i get the same error. Here is the snip of how the perms for
> >>>>>>.iso look like...
> >>>>>>
> >>>>>>ll /tmp/iso1-domain/35f880f8-bd0c-4063-b171-2ddaa59e1212/images/11111111-1111-1111-1111-111111111111/Fedora-16-x86_64-DVD.iso
> >>>>>>-rwxr-xr-x. 1 vdsm kvm 3757047808 Feb 13 04:24 /tmp/iso1-domain/35f880f8-bd0c-4063-b171-2ddaa59e1212/images/11111111-1111-1111-1111-111111111111/Fedora-16-x86_64-DVD.iso
> >>>>>would you try `ls -lZ` ? Does your /var/log/audit/audit.log shows an
> >>>>>selinux problem? What's `getenforce`? And `getsebool virt_use_nfs`?
> >>>>Hi Dan,
> >>>>     Thanks for the hint, after setting virt_use_nfs, it worked for me.
> >>>>Strangely VDSM should have set it, not sure why it didn't.
> >>>I suppose this is related to the fact that your `semanage` hangs. Please
> >>>help us understand why.
> >>>
> >>Hello Dan,
> >>     This is what strace dumped, when i attached to the semanage process.
> >>Note that i am only pasting the last few lines.. as the dump was large...
> >>Let me know if you need to entire dump...
> >I'd better know if strace seems to be advancing anywhere. Is there a
> >blocking system call? For how long did you wait? (I guess I should have
> >asked for `strace -t`)
> >
> You are rite, i did not wait enuf for it to finish may be.
> This time i did.. it took ~ 2.5 mins to finish the semanage cmd.
> 
> I started with -t this time, so here is the time gap (wait) that i see...
> 20:12:20 close(5)                       = 0
> 20:12:20
> open("/etc/selinux/targeted/modules/tmp/netfilter_contexts",
> O_WRONLY|O_CREAT|O_TRUNC, 0600) = 5
> 20:12:20 write(5, "", 0)                = 0
> >20:12:20 close(5)                       = 0
> >20:15:19 open("/etc/selinux/targeted/modules/tmp/commit_num",
> O_RDONLY) = 5
> 20:15:19 read(5,
> "4\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0",
> 32) = 32
> 20:15:19 close(5)                       = 0
> 
> I marked the gap with > .. let me know if you need the entire dump ?

hmm, I wish I'd asked you to use -ff, to see if there's a subthread
doing something fishy. Is something interesting written to
/var/log/audit /var/log/message at this time?

Anyway, I'm not sure that this list has the expertise to properly debug
an SELinux problem on your machine. It seems that it merits opening a
bug on policycoreutils-python - if you can identify why it takes so
long.

Dan.