[libvirt] xml format for openvz driver

[Evgeniy Sokolov]

>> Hello!
>>
>> 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.
>>
>> 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.

> If I'm understanding previous OpenVZ discussions correctly, the template
> is basically a master tar.gz archive, which is unpacked to form the 
> container's 'root filesystem' ?  But where does 'config' fit into this.
Yes, you template is "ostemplate". It is pre created template of container.
Usually, template correspond to OS name
centos-4-i386
debian-3.1-ia64
gentoo-20060317-amd64
etc
> 
> 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.
> 
>> For tag domain/devices/disk:
>> need to add "diskspace"
>> desirable "diskinodes" - it is optional because of "disknodes" are over
>> very rarely.
> 
> Does OpenVZ actually attach disks to containers ? I thought it was 
> just filesystem level virtualization, not actual block devices in
> the guest ?  
It is filesystem level virtualization.
> Anyway, this seems like quota management to me, so
> perhaps adding a 
> 
>     <quota type="size" max="10000"/>
> 
> And
> 
>     <quota type="inodes" max="100"/>
Good idea. To add into "filesystem" tag.
> 
>> 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.
> 
>> 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?
> 
> The latter case is basically hardware device assignment. This isn't
> something we currently have a way to represent in libvirt, but we
> certainly need something. I don't think it belongs in the <interface>
> tag though - for device passthrough we want something more generic,
> allowing specification of devices based on subsystem, or class.
> 
> eg Based on subsystem naming, to pass through PCI network card
> with PCI device number 00:1d.2
> 
>     <host subsystem='pci' dev='00:1d.2'/>
> 
> Or based on class specific naming
> 
>    <host class='network' dev='eth1'/>
This case is more match for OpenVZ network assignment.
> 
> 
> Daniel