Starting VMs on qcow2 format with base images in level three fails
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
libvirt (Ubuntu) |
Invalid
|
Medium
|
Unassigned |
Bug Description
Also, for some reason the ownership of the base images changes.
To recreate the problem:
/tmp $ kvm-img create -f qcow2 level1.img 10G
Formatting 'level1.img', fmt=qcow2 size=10737418240 encryption=off cluster_size=0
/tmp $ kvm-img create -f qcow2 -b level1.img level2.img
Formatting 'level2.img', fmt=qcow2 size=10737418240 backing_
/tmp $ kvm-img create -f qcow2 -b level2.img level3.img
Formatting 'level3.img', fmt=qcow2 size=10737418240 backing_
/tmp $ grep -E '(<name>)|(<source file)' vm.xml
<name>
<source file='/
<source file='/
/tmp $ virsh define vm.xml
Domain TestVM defined from vm.xml
/tmp $ virsh start TestVM
error: Failed to start domain TestVM
error: internal error process exited while connecting to monitor: char device redirected to /dev/pts/6
qemu: could not open disk image /tmp/level3.img: Permission denied
/tmp $ ls -l *.img
-rw-r--r-- 1 robert robert 262144 2011-01-01 20:37 level1.img
-rw-r--r-- 1 libvirt-qemu kvm 262144 2011-01-01 20:37 level2.img
-rw-r--r-- 1 root root 262144 2011-01-01 20:37 level3.img
/tmp $
If you change the source file in the VM definition to 'level2.img' then the VM starts fine.
This worked perfectly in Ubuntu 10.04.
ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: libvirt-bin 0.8.3-1ubuntu14
ProcVersionSign
Uname: Linux 2.6.35-24-generic x86_64
NonfreeKernelMo
Architecture: amd64
Date: Sat Jan 1 20:32:01 2011
InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release amd64 (20100429)
ProcEnviron:
PATH=(custom, user)
LANG=en_DK.utf8
SHELL=/bin/bash
SourcePackage: libvirt
information type: | Public → Public Security |
Thank you for taking the time to file this report and helping to make Ubuntu better.
The information in the description shows that level3.img is owned by root:root, and that the reason for not being able to use level3.img was due to permission being denied. Could you chown libvirt-qemu:kvm /tmp/level*.img, and try again?
Note: since libvirt chowns the files before using them, it actually seems more likely that level2.img or level1.img would be the problem. I can devise one or two sequence of events and experiments which would cause one of the base image files to be inaccessible to libvirt. That might be a real bug worth bringing up upstream.