On Tue, Jul 22, 2008 at 08:41:36PM +0400, Evgeniy Sokolov wrote:
For tag domain/os:
need to add "ostemplate"
desirable "config"
Can you explain exactly what the semantics of the two desired attributes
are used for ?
"config" is name of sample config for container. It contains many
parameters
http://wiki.openvz.org/UBC_parameters_table
It is desirable because of many customers like to use config.
The problem including a 'config' parameter is that this data becomes
totally opaque to the management app. Given a piece of XML describing
a domain, including a "config=xxxx' parameter, there's no way for the
app to find out what the underlying resources settings are.
Can we add to XML some parameters that is in config file? It is because
of OpenVZ has no one parameter "memory". It consist of many different
parameters which can be configured separately:
kernel memory, application memory, etc
I suppose it will be not generic.
How can we desing XML to tune more memory limits?
For the filesystem stuff, for LXC we've got a section under <devices>
whcih looks like
<filesystem type="mount">
<source dir='/some/path'/>
<target dir='/'/>
</filessytem>
Which says 'make /some/path be the root filesystem, using a bind mount'.
I could imagine representing the idea of a template with a slight
variation like
<filesystem type="template">
<source name="template name"/>
<target dir='/'/>
</filesystem>
Yes, we can. But template name is not property of file system.
Well, actually I'd argue that it is. The "source" element refers
to the resource in the host OS that forms the source of the
filesystem. So for a root filesystem instantiated from a template,
I think template name is the most applicable.
Sounds good from such point of view.
Tag "target" is useless for OpenVZ.
For tag domain/devices/interface:
How to describe, if want to add ip addresses for routing network?
We'll probably want todo something based on <interface type='ethernet'
which is a generic catch all config.
Does OpenVZ support bridging, or NAT for containers ?
bridging is supported.
NAT can be configured via iptables.
If it supports bridging that is sufficient. The libvirt networking
APIs, allow us to implement NAT for any VM in terms of the generic
bridge support. Basically libvirt creates a bridge device 'virbr0'
and sets up NAT rules for that device. A guest VM simply needs to
be connected to virbr0, and then NAT automagically works for it.
Do I correctly undertand? For NAT we shoud use tag "interface" with type
"bridge" and
<target dev="virbr0" />
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list