Bug 523009

Summary: Cannot create domain with LVM storage
Product: [Fedora] Fedora Reporter: Geert Jansen <gjansen>
Component: libvirtAssignee: Daniel Veillard <veillard>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: high    
Version: rawhideCC: berrange, bugzilla, clalance, crobinso, itamar, markmc, veillard, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-09-14 07:44:05 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Geert Jansen 2009-09-13 06:12:12 EDT
Description of problem:

Creating a new domain with storage on an LVM volume is not possible. Virt-manager is reporting the following error passed onto it by libvirt and qemu:

qemu: could not open disk image /dev/vg_master/vm_rhevm

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:

1. Using virt-manager, create a new domain using LVM storage

Actual results:

The error above.

Expected results:

The domain should be created.
Additional info:

I did some debugging and the problem appears that the directory /dev/vg_master has the permissions of root:root 750 and with qemu running as qemu:qemu this will now allow access. I assume, but have not checked, that the directory /dev/vg_master is created by vgscan. Once i change the mode of the directory, i can create a domain with this volume without problem.

However, at each reboot, the permissions on /dev/vg_master are reset again. So we need some kind of permanent fix. As libvirt is already changing device ownerships before running qemu, it should probably just include this directory too.
Comment 1 Mark McLoughlin 2009-09-14 07:44:05 EDT
Thanks for the report and sorry for the pain in debugging it

It's a known issue, we're waiting since June for lvm2 to switch to using udev so that this can be fixed

*** This bug has been marked as a duplicate of bug 507397 ***