Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 874001

Summary: Unable to run VM on fedora 17
Product: [Retired] oVirt Reporter: Arik <ahadas>
Component: vdsmAssignee: Federico Simoncelli <fsimonce>
Status: CLOSED WONTFIX QA Contact: Haim <hateya>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 3.2CC: abaron, acathrow, bazulay, dyasny, fsimonce, iheim, mgoldboi, yeylon, ykaul
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard: virt
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-06-02 07:50:42 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
libvirt and vdsm log files none

Description Arik 2012-11-07 08:53:00 UTC
Created attachment 639911 [details]
libvirt and vdsm log files

Description of problem:
when trying to run VM on host with fedora 17, the operation fails and an error message that says that a lock can't be acquired because of lack of permissions appears in VDSM's log.
The VDSM service runs and its status is ok before making the run VM action.

Version-Release number of selected component (if applicable):
vdsm 4.10.0-12.fc17


How reproducible:
try to run vm on host with fedora 17 and vdsm 4.10.0-12
  
Actual results:
the operation fail.
in the webadmin it says:
Failed to run VM machine1 on Host bamba.
VM machine1 is down. Exit message: Failed to acquire lock: Permission denied.
VM machine1 was started by admin@internal (Host: bamba).


Expected results:
the VM run on the host

Additional info:
The log files for libvirt and VDSM are attached
the problem occurred on 2012-11-07 10:36:36

Comment 1 Federico Simoncelli 2012-11-07 09:39:49 UTC
What version of the engine are you running? You shouldn't be able to create V3 domains.

Comment 2 Arik 2012-11-07 09:51:58 UTC
The engine version is the latest upstream (3.2)
The domain version is V3 indeed.

It works on host with:
OS Version: RHEL - 6Server - 6.3.0.3.el6
VDSM Version: vdsm-4.9.6-36.0.el6_3

It doesn't work on host with:
OS Version: Fedora - 17 - 1
VDSM Version: vdsm-4.10.0-12.fc17

The cluster & Data Center compatibility version is 3.1

Comment 3 Federico Simoncelli 2012-11-07 10:07:25 UTC
(In reply to comment #2)
> The engine version is the latest upstream (3.2)
> The domain version is V3 indeed.
> 
> It works on host with:
> OS Version: RHEL - 6Server - 6.3.0.3.el6
> VDSM Version: vdsm-4.9.6-36.0.el6_3
> 
> It doesn't work on host with:
> OS Version: Fedora - 17 - 1
> VDSM Version: vdsm-4.10.0-12.fc17
> 
> The cluster & Data Center compatibility version is 3.1

That is correct, VDSM in fedora 17 comes from the ovirt 3.1 branch and it doesn't support domain V3 (it lacks of several patches that are instead in vdsm-4.9.6-36.0.el6_3).
If you run the upstream engine then you need the upstream vdsm too.

Comment 4 Itamar Heim 2012-11-07 10:59:34 UTC
isn't V3 a 3.2 DC level only in ovirt then?
vdsm in fedora 17 shouldn't report 3.2 cluster/DC capability.
so this shouldn't happen at all?

Comment 5 Federico Simoncelli 2012-11-07 12:39:46 UTC
(In reply to comment #4)
> isn't V3 a 3.2 DC level only in ovirt then?
> vdsm in fedora 17 shouldn't report 3.2 cluster/DC capability.
> so this shouldn't happen at all?

What you say is completely correct but at the moment maintaining this difference between upstream/downstream (V3 in 3.2 rather than 3.1) looks like some additional work that would prevent only few situations where users leave the tested/documented path and chose to go with upstream/unstable on their own.

Since ovirt 3.2 is near I wouldn't define this as a priority as both upstream and downstream would trigger the V3 upgrade for 3.2 DCs (and if there's any issue with that, it's the part that deserves to be fixed anyway).

Comment 6 Federico Simoncelli 2012-11-12 16:40:54 UTC
An initial wip has been posted to http://gerrit.ovirt.org/#/c/9197/ ([wip] core: move the storage domain V3 to DC 3.2).
The patch will probably require some additional iterations as I want to size the opportunity to unify the logic in one place.

Comment 7 Ayal Baron 2012-11-13 07:23:23 UTC
(In reply to comment #4)
> isn't V3 a 3.2 DC level only in ovirt then?

Doesn't have to be.
We release an updated vdsm to F17 that supports V3 and then it would just work.
fix for this bug would be to run yum update vdsm.

Comment 8 Itamar Heim 2013-06-02 07:50:42 UTC
Closing old bugs. If this issue is still relevant/important in current version, please re-open the bug.