[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Libvir] [RFC] Add Container support to libvirt



Balbir,

I'd appreciate any links...

How will this configuration be persisted across reboots? Specifically, once a configuration is set up for a container, who is responsible for storing this configuration? Will a libvirt driver need to store it somewhere in it's configuration file(s) or will it be stored somewhere else by a resource management facility such that it can associated it with a container after a reboot?

Balbir Singh wrote:
* Daniel P. Berrange <berrange redhat com> [2008-01-15 15:52:13]:

On Tue, Jan 15, 2008 at 12:26:43AM -0800, Dave Leskovec wrote:
Greetings,

Following up on the XML format for the Linux Container support I proposed... I've made the following recommended changes:
* Changed mount tags
* Changed nameserver tag to be consistent with gateway
* Moved cpushare and memory tags outside container tag

This is the updated format:
<domain type='linuxcontainer'>
  <name>Container123</name>
  <uuid>8dfd44b31e76d8d335150a2d98211ea0</uuid>
  <container>
      <filesystem>
          <mount>
              <source dir="/home/user/lxc_files/etc/"/>
              <target dir="/etc/"/>
          </mount>
          <mount>
              <source dir="/home/user/lxc_files/var/"/>
              <target dir="/var/"/>
          </mount>
      </filesystem>
Comparing this to the Linux-VServer XML that Daniel posted, you're both
pretty much representing the same concepts so we need to make a decision
about which format to use for  filesystem mounts.

OpenVZ also provides a /domain/container/filesystem tag, though it
uses a concept of filesystem templates auto-cloned per container
rather than explicit mounts. I think I'd like to see

       <filesystem type="mount">
               <source dir="/home/user/lxc_files/etc/"/>
               <target dir="/etc/"/>
       </filesystem>

For the existing OpenVZ XML, we can augment their <filesystem> tag with
an attribute  type="template".

      <application>/usr/sbin/container_init</application>
      <network hostname='browndog'>
          <ip address="192.168.1.110" netmask="255.255.255.0"/>
              <gateway address="192.168.1.1"/>
              <nameserver address="192.168.1.1"/nameserver>
          </ip>
      </network>
Again this is pretty similar to needs of VServer / OpenVZ. In the existing
OpenVZ XML, the gateway and nameserver tags are immediately within the
<network> tag, rather than nested inside the <ip> tag. Aside from that it
looks to be a consistent set of information.

  </container>
  <cpushare>40</cpushare>
As Daniel points out, we've thus far explicitly excluded tuning info from
the XML. Not that I have any suggestion on where else to put it at this
time. This is a minor thing though, easily implemented once we come to a
decision.

At some point, we'll need resource management extensions to libvirt.
vserver and openVZ both use them and it will also be useful for
containers and kvm/qemu as well. I think we'll need a resource
management feature extension to the XML format.

Currently resource management is provided through control groups (I
can send out links if desired). Ideally once configured the control
groups should be persistent (visible across reboots, so we need to
save state).

Thoughts?

  <memory>65536</memory>
  <devices>
      <console tty='/dev/pts/4'/>
  </devices>
</domain>

Does this look ok now?  All comments and questions are welcome.
Pretty close.

Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
--
Libvir-list mailing list
Libvir-list redhat com
https://www.redhat.com/mailman/listinfo/libvir-list


--
Best Regards,
Dave Leskovec
IBM Linux Technology Center
Open Virtualization


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]