7:31 p.m.
Hi,
I am having trouble configuring a virtual machine domain and its
corresponding xml definition to use a qcow2 delta disk. The delta disk
is backed by a qcow2 base disk. I am able to successfully start the
guest OS with the delta disk at the command line using qemu. However, I
am not able to start the guest OS using the libvirt tools including
virsh and virt-manager. I am hoping that someone knows how to configure
a virtual machine domain that works with a qcow2 delta disk, and have it
managed by the virt-family tools.
First, I create a delta and base disk from a raw image file with the
following commands:
qemu-img convert ubuntu910server64.img -O qcow2
ubuntu910server64_base.qcow2
qemu-img create -b ubuntu910server64_base.qcow2 -f qcow2
ubuntu910server64_delta.qcow2
Then, I can successfully start the guest OS on the command line with
qemu-system-x86_64 -m 256 -hda ubuntu910server64_delta.qcow2
My attempt to modify the virtual machine domain configuration fails.
Here are my steps:
-- Edit the configuration
# virsh edit ubuntu910server64
-- Replace some lines
<disk type='file' device='disk'>
- <source file='/var/lib/libvirt/images/ubuntu910server64.img'/>
- <target dev='vda' bus='virtio'/>
+ <source
file='/var/lib/libvirt/images/ubuntu910server64_delta.qcow2'/>
+ <target dev='hda' bus='ide'/>
</disk>
-- Attempt to start the machine
# virsh start ubuntu910server64
Connecting to uri: qemu:///system
error: Failed to start domain ubuntu910server64
error: internal error unable to start guest: qemu: could not open
disk image /var/lib/libvirt/images/ubuntu910server64_delta.qcow2
If I have posted this to the wrong forum, please direct me to the right
location.
Thanks!
-dave
9:57 a.m.
On Mon, Apr 19, 2010 at 5:31 PM, Wang David <David_Wang(a)prn.com> wrote:
- <target dev='vda' bus='virtio'/>
+ <target dev='hda' bus='ide'/>
Why are you changing this? Unless you've gone through extra steps to
configure your guest OS to use this different driver and location of the
boot disk, it's going to fail to boot. Perhaps try leaving this line
unchanged and see how that goes. From the VM's perspective, the
copy-on-write image (delta) is no different than the backing store.
.:. jeremy
1:01 p.m.
Hi Jeremy,
Thanks for responding, and for the suggestion.
I have tried several permutations of device type and bus (including vda/virtio), each of
which seem to work on non-delta images. The reason that I have given the example below
using (target dev='hda' bus='ide') is because it most closely matches the
working qemu command line:
qemu-system-x86_64 -m 256 -hda ubuntu910server64_delta.qcow2
This problem may be related to the way that virt-manager calls qemu. When I use virsh to
start a working non-delta image, the command line found from "ps" is the
following:
/usr/bin/kvm <options removed> -drive
file=/var/lib/libvirt/images/ubuntu910server64.img,if=virtio,index=0,boot=on <options
removed>
This seems to match the "qemu" man page documentation at line 139, where it
suggests that the -hda switch is an alias to the -drive option:
Instead of -hda, -hdb, -hdc, -hdd, you can use:
qemu -drive file=file,index=0,media=disk
Assuming that qemu/kvm is called with the same options for the delta disk, the options
should be correct.
I've attached a segment from the syslog, which shows an error at
qemudReadLogOutput:816
--------------------------------------------------------------------
Apr 19 17:27:36 virtualserver3 kernel: [14202.390685] type=1505 audit(1271723256.496:74):
operation="profile_load" pid=3144
name=libvirt-20030353-cdee-109a-1abb-dc4971d036c2
Apr 19 17:27:36 virtualserver3 kernel: [14202.400448] device vnet0 entered promiscuous
mode
Apr 19 17:27:36 virtualserver3 kernel: [14202.402668] br0: port 2(vnet0) entering learning
state
Apr 19 17:27:36 virtualserver3 kernel: [14202.411373] type=1503 audit(1271723256.513:75):
operation="open" pid=3147 parent=1
profile="libvirt-20030353-cdee-109a-1abb-dc4971d036c2"
requested_mask="r::" denied_mask="r::" fsuid=0 ouid=0
name="/data/virtual/var/lib/libvirt/images/ubuntu910server64.qcow2"
Apr 19 17:27:36 virtualserver3 kernel: [14202.516577] br0: port 2(vnet0) entering disabled
state
Apr 19 17:27:36 virtualserver3 kernel: [14202.544518] device vnet0 left promiscuous mode
Apr 19 17:27:36 virtualserver3 kernel: [14202.544522] br0: port 2(vnet0) entering disabled
state
Apr 19 17:27:36 virtualserver3 libvirtd: 17:27:36.718: error : qemudReadLogOutput:816 :
internal error Process exited while reading console log output
Apr 19 17:27:36 virtualserver3 libvirtd: 17:27:36.718: error : qemudWaitForMonitor:1103 :
internal error unable to start guest: qemu: could not open disk image
/var/lib/libvirt/images/ubuntu910server64_delta.qcow2#012
Apr 19 17:27:36 virtualserver3 kernel: [14202.728382] type=1505 audit(1271723256.834:76):
operation="profile_remove" pid=3149
name=libvirt-20030353-cdee-109a-1abb-dc4971d036c2 namespace=default
--------------------------------------------------------------------
Both the virtual host and guest machines are running Ubuntu 9.10 Server amd-64.
Has anyone have any success stories using delta images with virt-family tools?
Thanks!
-dave
________________________________________
From: jeremy avnet [mailto:brainsik@saucelabs.com]
Sent: Tuesday, April 20, 2010 7:58 AM
To: Wang David
Cc: libvirt-users(a)redhat.com
Subject: Re: [libvirt-users] Need help using libvirt with qcow2 delta and base images
On Mon, Apr 19, 2010 at 5:31 PM, Wang David <David_Wang(a)prn.com> wrote:
- <target dev='vda' bus='virtio'/>
+ <target dev='hda' bus='ide'/>
Why are you changing this? Unless you've gone through extra steps to configure your
guest OS to use this different driver and location of the boot disk, it's going to
fail to boot. Perhaps try leaving this line unchanged and see how that goes. From the
VM's perspective, the copy-on-write image (delta) is no different than the backing
store.
.:. jeremy
1:46 p.m.
On Tue, Apr 20, 2010 at 11:01 AM, Wang David <David_Wang(a)prn.com> wrote:
Apr 19 17:27:36 virtualserver3 kernel: [14202.411373] type=1503
audit(1271723256.513:75): operation="open" pid=3147 parent=1
profile="libvirt-20030353-cdee-109a-1abb-dc4971d036c2"
requested_mask="r::"
denied_mask="r::" fsuid=0 ouid=0
name="/data/virtual/var/lib/libvirt/images/ubuntu910server64.qcow2"
Apr 19 17:27:36 virtualserver3 libvirtd: 17:27:36.718: error :
qemudWaitForMonitor:1103 : internal error unable to start guest: qemu: could
not open disk image
/var/lib/libvirt/images/ubuntu910server64_delta.qcow2#012
These indicate that AppArmor is denying access to the backing store, thus,
your delta image will not work.
You're going to need add a rule
into /etc/apparmor.d/abstractions/libvirt-qemu so that the backing store can
be read. Something like:
/data/virtual/var/lib/libvirt/images/ubuntu910server64.qcow2 r,
or
/data/virtual/var/lib/libvirt/images/* r,
.:. jeremy
3:08 p.m.
Jeremy,
Thank you so much for resolving my problem ;) The AppArmor configuration fix worked. I
am sure that you have saved me many more days of research. It looks like I have to
research this AppArmor business.
Thanks!
-dave
________________________________________
From: jeremy avnet [mailto:brainsik@saucelabs.com]
Sent: Tuesday, April 20, 2010 11:46 AM
To: Wang David
Cc: libvirt-users(a)redhat.com
Subject: Re: [libvirt-users] Need help using libvirt with qcow2 delta and base images
On Tue, Apr 20, 2010 at 11:01 AM, Wang David <David_Wang(a)prn.com> wrote:
Apr 19 17:27:36 virtualserver3 kernel: [14202.411373] type=1503 audit(1271723256.513:75):
operation="open" pid=3147 parent=1
profile="libvirt-20030353-cdee-109a-1abb-dc4971d036c2"
requested_mask="r::" denied_mask="r::" fsuid=0 ouid=0
name="/data/virtual/var/lib/libvirt/images/ubuntu910server64.qcow2"
Apr 19 17:27:36 virtualserver3 libvirtd: 17:27:36.718: error : qemudWaitForMonitor:1103 :
internal error unable to start guest: qemu: could not open disk image
/var/lib/libvirt/images/ubuntu910server64_delta.qcow2#012
These indicate that AppArmor is denying access to the backing store, thus, your delta
image will not work.
You're going to need add a rule into /etc/apparmor.d/abstractions/libvirt-qemu so that
the backing store can be read. Something like:
/data/virtual/var/lib/libvirt/images/ubuntu910server64.qcow2 r,
or
/data/virtual/var/lib/libvirt/images/* r,
.:. jeremy
5365
days inactive
5365
days old
4 comments
2 participants
participants (2)
-
jeremy avnet -
Wang David