[Users] Newly created VM will not start. Bad permissions on its virtual disk.
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?
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.
On Mon, Feb 27, 2012 at 5:08 PM, Dan Kenigsberg <danken@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.
participants (2)
-
Dan Kenigsberg -
Terry Phelps