On 08/04/2011 09:41 AM, Daniel P. Berrange wrote:
From: "Daniel P. Berrange"<berrange@xxxxxxxxxx>
A previous commit gave the LXC driver the ability to mount
block devices for the container filesystem. Through use of
the loopback device functionality, we can build on this to
support use of plain file images for LXC filesytems.
By setting the LO_FLAGS_AUTOCLEAR flag we can ensure that
the loop device automatically disappears when the container
dies / shuts down
* src/lxc/lxc_container.c: Raise error if we see a file
based filesystem, since it should have been turned into
a loopback device already
* src/lxc/lxc_controller.c: Rewrite any filesystems of
type=file, into type=block, by binding the file image
to a free loop device
Neat trick.
If I understand correctly, 'dumpxml' for an lxc domain using one of
these loopback files will have the live xml showing the loopback device
created, while the configured xml still shows the original file. But I
don't see anything that reverts type=block back into type=file when
doing a VIR_DOMAIN_XML_INACTIVE, other than the fact that live and
configured xml are stored in separate domain def objects.
I'm worried that you might be missing some changes to domain_conf.[hc]
to correctly manipulate actual vs. configured setup all within the
context of live xml. This is a similar problem to the recent <actual>
for networks - we must track which loopback block device was tied to the
the filesystem, in case libvirtd gets restarted before the lxc domain
goes away, but we also don't want to tie ourselves to that device when
the lxc domain reboots (rather, each boot should create a new loopback
device, opened on the original file).
On the other hand, VIR_DOMAIN_XML_INACTIVE normally means you will only
see the configured setup, and is only ever used on active configuration
by virDomain[Managed]Save, which are currently unsupported with lxc.
And the LO_FLAGS_AUTOCLEAR ends the loopback device as soon as the lxc
domain quits, which is a convenient way to handle a lot of cleanup.
So while I didn't find any coding bugs in this patch, I need some
reassurance that we are handling things correctly from the
VIR_DOMAIN_XML_INACTIVE aspect before I give an ack.
--
Eric Blake eblake@xxxxxxxxxx +1-801-349-2682
Libvirt virtualization library http://libvirt.org
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list