10:50 p.m.
I have a newly installed ovirt engine, and node. I created a new VM, gave
it a virtual disk, and a network, attached my one ISO that I have out
there, and tried to start it. It failed. The admin portal error messages
say:
2012-Feb-27, 15:40:10
Failed to run VM oel-test (User: admin@internal).
2012-Feb-27, 15:40:10
Failed to run VM oel-test on Host oravm2.
2012-Feb-27, 15:40:10
VM oel-test is down. Exit message unable to open disk path
/rhev/data-center/f465251e-
5679-11e1-ba81-97917332892e/24b70dff-549e-46a6-a863-3a158aa6e9a3/images/c07482cb-818f-47b7-97d1-1409909408bb/e1e57887-e660-4191-87a0-5eac7a44f2d7:
Permission denied.
2012-Feb-27, 15:40:08
VM oel-test was started by admin@internal (Host: oravm2).
When I go to the node, and check, the permissions do indeed look bad.
vdsm:kvm owns everything down through
/rhev/data-center/f465251e-5679-11e1-ba81-97917332892e/24b70dff-549e-46a6-a863-3a158aa6e9a3,
but below that, it looks bad. Here is a "ls -l" of that last directory:
# ls -l
total 8
drwxr-xr-x. 2 4294967294 4294967294 4096 Feb 23 16:22 dom_md
drwxr-xr-x. 3 4294967294 4294967294 4096 Feb 27 16:22 images
And then the owner and group of everything below 'images' is bad, too.
Can some help me determine what happened? And how to fix it?
12:08 a.m.
On Mon, Feb 27, 2012 at 03:50:32PM -0500, Terry Phelps wrote:
I have a newly installed ovirt engine, and node. I created a new VM,
gave
it a virtual disk, and a network, attached my one ISO that I have out
there, and tried to start it. It failed. The admin portal error messages
say:
2012-Feb-27, 15:40:10
Failed to run VM oel-test (User: admin@internal).
2012-Feb-27, 15:40:10
Failed to run VM oel-test on Host oravm2.
2012-Feb-27, 15:40:10
VM oel-test is down. Exit message unable to open disk path
/rhev/data-center/f465251e-
5679-11e1-ba81-97917332892e/24b70dff-549e-46a6-a863-3a158aa6e9a3/images/c07482cb-818f-47b7-97d1-1409909408bb/e1e57887-e660-4191-87a0-5eac7a44f2d7:
Permission denied.
2012-Feb-27, 15:40:08
VM oel-test was started by admin@internal (Host: oravm2).
When I go to the node, and check, the permissions do indeed look bad.
vdsm:kvm owns everything down through
/rhev/data-center/f465251e-5679-11e1-ba81-97917332892e/24b70dff-549e-46a6-a863-3a158aa6e9a3,
but below that, it looks bad. Here is a "ls -l" of that last directory:
# ls -l
total 8
drwxr-xr-x. 2 4294967294 4294967294 4096 Feb 23 16:22 dom_md
drwxr-xr-x. 3 4294967294 4294967294 4096 Feb 27 16:22 images
And then the owner and group of everything below 'images' is bad, too.
Can some help me determine what happened? And how to fix it?
I've never seen a filed owned by uid -2 before! I suppose you are using nfs.
what are the mount options (look for the relevant line in the output of
`mount`)? which is your server, and how was it configured?
The script in
http://gerrit.ovirt.org/gitweb?p=vdsm.git;a=blob;f=contrib/nfs-check.py
may help diagnose few nfs-related problems. Once we understand what's wrong with
you setup, we should probabaly update this script.
Dan.
12:22 a.m.
On Mon, Feb 27, 2012 at 5:08 PM, Dan Kenigsberg <danken(a)redhat.com> wrote:
On Mon, Feb 27, 2012 at 03:50:32PM -0500, Terry Phelps wrote:
> I have a newly installed ovirt engine, and node. I created a new VM, gave
> it a virtual disk, and a network, attached my one ISO that I have out
> there, and tried to start it. It failed. The admin portal error messages
> say:
>
> 2012-Feb-27, 15:40:10
> Failed to run VM oel-test (User: admin@internal).
>
> 2012-Feb-27, 15:40:10
> Failed to run VM oel-test on Host oravm2.
>
> 2012-Feb-27, 15:40:10
> VM oel-test is down. Exit message unable to open disk path
> /rhev/data-center/f465251e-
>
5679-11e1-ba81-97917332892e/24b70dff-549e-46a6-a863-3a158aa6e9a3/images/c07482cb-818f-47b7-97d1-1409909408bb/e1e57887-e660-4191-87a0-5eac7a44f2d7:
> Permission denied.
>
> 2012-Feb-27, 15:40:08
> VM oel-test was started by admin@internal (Host: oravm2).
>
>
> When I go to the node, and check, the permissions do indeed look bad.
> vdsm:kvm owns everything down through
>
/rhev/data-center/f465251e-5679-11e1-ba81-97917332892e/24b70dff-549e-46a6-a863-3a158aa6e9a3,
> but below that, it looks bad. Here is a "ls -l" of that last directory:
>
> # ls -l
> total 8
> drwxr-xr-x. 2 4294967294 4294967294 4096 Feb 23 16:22 dom_md
> drwxr-xr-x. 3 4294967294 4294967294 4096 Feb 27 16:22 images
>
> And then the owner and group of everything below 'images' is bad, too.
>
> Can some help me determine what happened? And how to fix it?
I've never seen a filed owned by uid -2 before! I suppose you are using
nfs.
what are the mount options (look for the relevant line in the output of
`mount`)? which is your server, and how was it configured?
The script in
http://gerrit.ovirt.org/gitweb?p=vdsm.git;a=blob;f=contrib/nfs-check.py
may help diagnose few nfs-related problems. Once we understand what's
wrong with
you setup, we should probabaly update this script.
Dan.
First, of all, I didn't manually do any mounting or other manipulations on
the node, or the ovirt-engine machine, I believe. I followed the
documentation in the "oVirt 3.0 Installation Guide".
Second, I just noticed that the virtual disk was created in the "export
domain", and not the "data domain". I don't think that's as it
should be. I
created it through the oVirt admin portal, though, and I didn't see any
options during the VM creation about placement of the disk.
Okay, how is it mounted? Here are the mount options of all three domains
exported from the ovirt-engine machine:
mount|grep domain
oravm3.acbl.net:/datadomain/ on
/rhev/data-center/mnt/oravm3.acbl.net:_datadomain
type nfs4
(rw,relatime,vers=4,rsize=524288,wsize=524288,namlen=255,soft,nosharecache,proto=tcp,port=0,timeo=600,retrans=6,sec=sys,clientaddr=172.16.2.52,minorversion=0,local_lock=none,addr=192.168.118.10)
oravm3.acbl.net:/exportdomain/ on
/rhev/data-center/mnt/oravm3.acbl.net:_exportdomain
type nfs4
(rw,relatime,vers=4,rsize=524288,wsize=524288,namlen=255,soft,nosharecache,proto=tcp,port=0,timeo=600,retrans=6,sec=sys,clientaddr=172.16.2.52,minorversion=0,local_lock=none,addr=192.168.118.10)
oravm3.acbl.net:/isodomain/ on /rhev/data-center/mnt/oravm3.acbl.net:_isodomain
type nfs4
(rw,relatime,vers=4,rsize=524288,wsize=524288,namlen=255,soft,nosharecache,proto=tcp,port=0,timeo=600,retrans=6,sec=sys,clientaddr=172.16.2.52,minorversion=0,local_lock=none,addr=192.168.118.10)
I do notice that they all say "nfs4", and I've seen some postings about
"dont' use nfs4". Maybe that's relevant.
I have run your nfs-check.py script before, last week, when we (the mailing
list and I) were trying to deternine why an uploaded ISO file didn't appear
in the admin portal, even though it clearly WAS there, and had good owner,
group, and permissions. This script was failing to umount the NFS share
after it did its tests.
4664
days inactive
4664
days old
2 comments
2 participants
participants (2)
-
Dan Kenigsberg -
Terry Phelps