On Tue, Jul 22, 2008 at 05:21:41PM +0400, Evgeniy Sokolov wrote:
Hello!
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?
http://libvirt.org/formatdomain.html#elementsNICS
and
http://libvirt.org/formatnetwork.html#examplesRoute
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
Daniel
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list