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

Re: [libvirt] xml format for openvz driver

On Tue, Jul 22, 2008 at 05:21:41PM +0400, Evgeniy Sokolov wrote:

  Hi Evgeniy

I made review of domain XML format for driver in libvirt.
And I have several questions and additions.

For tag domain:
need to add "vmid" or "id" - currenly tag "name" is used for ID.
OpenVZ has mandatory parameter ID, but it also support optional
parameter "name", which is not implemented for openvz driver now. I plan
to support of "name" in future.

  Hum ...
the id is usually added as @id in the domain - assuming it is running.
The decision to go for the numerical id for the <name> value was that
it was supposed to be permanent and no extra high level naming scheme
would appear.
IIRC the 'id' name was the one of the subdirectory for the OpenVZ container.
How is the new name support added on top of that ? Unless the directory
names can now be allocated as name I don't see how the mapping is done.

If the new external name is as good as the old id then just replace the
id with the external name in <name> otherwise i wonder what the value
of this new naming scheme is and would ignore it

For tag domain/os:
need to add "ostemplate"
desirable "config"

For tag domain/devices/disk:
need to add "diskspace"
desirable "diskinodes" - it is optional because of "disknodes" are over
very rarely.

  Hum, could you describe those new fields a bit more ?
It is disk quota for container. OpenVZ mount /vz/root/<ID> into VM as /.
It can be changed on running container (increase/decrease).
diskinodes is quota for inodes.

Inside VM:
[root fedora-minimal /]# df
Filesystem           1K-blocks      Used Available Use% Mounted on
simfs                  1048576     96424    952152  10% /
[root fedora-minimal /]# df -i
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
simfs                 200000    6813  193187    4% /

For tag domain/devices/interface:
How to describe, if want to add ip addresses for routing network?


in general in libvirt the networking capabilities are not described per domain but as a separate set of networks with their own definitions.
Maybe the OpenVZ driver would have to dynamically add/remove them
as domain are instanciated. It would be good to see how the LXC containers
plans things too, if we need to extend the model, they should be kept as
compatible as possible.

Also, OpenVZ may move network adapter to VM (for example, eth1), adapter
 becomes inaccessible on harware node. How to describe it? Is it
ethernet type?

Hum, i don't know how i would express that in libvirt

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