[libvirt] [PATCH] Adding filesystem mount support for openVZ

Anton Protopopov aspsk2 at gmail.com
Wed Mar 18 15:23:48 UTC 2009


2009/3/12 Daniel P. Berrange <berrange at redhat.com>
>
>> On Wed, Mar 11, 2009 at 05:42:20PM +0100, Florian Vichot wrote:
>> > Hi everyone,
>> >
>> > This patch is to allow using the "mount" type in the "filesystem" tag
>> > for OpenVZ domains.
>> >
>> > Example:
>> > ...
>> >     <filesystem type='mount'>
>> >       <source dir='/path/to/filesystem/directory/' />
>> >       <target dir='/path/to/pivot/root/' />
>> >     </filesystem>
>> > ...
>> >
>> > This is my first patch to an external project, so don't spare me if I
>> > got things wrong :)
>> >
>> > Also, I'm curious for suggestions as to how I could allow for the target
>> > not to be specified in the XML. Because in this case OpenVZ just makes a
>> > temporary pivot root in "/var/lib/vz/root/" and that is probably
>> > sufficient for most people, who might not want to have to explicitly
>> > create a pivot root somewhere, just for mounting the filesystem while
>> > it's running.
>>
>> Actually the <target dir="...">  means something a little different. This
>> refers to the mount point *within* the container. So for the root
>> filesystem
>> of the container it will be   <target dir='/' />
>
> No, that patch does something different---it assumes that both <source dir>
> and <target dir>
> are paths within hardware node. If we denote <source dir> and <target dir>
> by the VE_PRIVATE
> and VE_ROOT correspondingly, we get the following picture.
>
> In OpenVZ there are VE_ROOT and VE_PRIVATE values for each container
> (they defined as VE_ROOT and VE_PRIVATE variables in container
> configuration file).
> The VE_PRIVATE defines the actual disposition of conatainer's
> root filesystem hierarchy. It can lie on it's own partition or be just a
> directory.
> When vzctl starts a container, it mounts a VE_PRIVATE "filesystem" to
> VE_ROOT
> mountpoint and then container starts to work in VE_ROOT chroot...
>
> So, yes, you are right - in this case we can always assume, that "target
> dir within container" is "/" :)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20090318/8281f71f/attachment-0001.htm>


More information about the libvir-list mailing list