Hi,

In the Xen / QEMU drivers we just stick this as an 'id' attribute on the top level <domain> - it looks reasonable to follow the same scheme for OpenVZ

Sure, 'id' is good enough.

...

<onboot>true</onboot>

Is this attribute refering to whether the guest auto-starts at boot time ? If so we recently introduced an explicit API for querying and changing this separately from the XML

int virDomainGetAutostart (virDomainPtr domain, int *autostart); int virDomainSetAutostart (virDomainPtr domain, int autostart);

These APIs can be implmented per-driver

Yeah, you are right it does refers to auto-start at boot up time. Then, I'll better ignore it in the XML def and implement the API stub in the openVZ driver.

...

<template>vps.basic</template> <os template='slackware-10.2-i386-minimal'/>

I'm not very familiar with way OpenVZ deals with OS installs / virtual disk images. Could you explain a little how these map into underling OpenVZ implementation - and what they end up doing on disk ?

OpenVZ is single kernel and multiple roof file sytems architecture. Every VM has its root fs somewhere on the host, for example: /vz/private/101 -> 101's root fs (containing bin,etc,usr,tmp,var,... ) /vz/private/102 -> 102's root fs (containing bin,etc,usr,tmp,var,... ) /vz/private/103 -> ...... These root file systems can be based on any Linux distro. The VM's root fs is usually quickly created by untaring what is called a template cache during VM creation time. A template cache is nothing but a tar of a particular distro's root fs. There are these various template caches available covering many popular Linux distros. While creating a VM(or VPS, in OpenVZ jargon), one needs to the name of the template cache that will be used to create the VM root file system. There is a designated place where these template caches, basically tar files, are kept. There is no disk image concept.

...

<network> <hostname>openvzhost</hostname> <ip address='192.168.1.101' netmask='255.255.255.0' defgw='192.168.1.1' /> <nameserver>192.168.1.1</nameserver> <nameserver>202.56.250.5</nameserver> </network>

For networking we need to figure out an XML format that more closely maps to the existing network formats seen by Xen / QEMU drivers. Reading the docs, the default networking config seems to map all OpenVZ guests onto a 'venet0' bridge device which certainly has a common feel to Xen / QEMU. It sounds like it is possible to do either manual or DHCP style address configuration too. I think we need to express networking in a form closer to something like

<devices> <interface type='bridge'> <hostname>openvzhost</hostname> <ip address='192.168.1.101' netmask='255.255.255.0' gateway='192.168.1.1' /> <nameserver>192.168.1.1</nameserver> <nameserver>202.56.250.5</nameserver> </interface> </devices>

You've probably guessed, that as a general rule we try to figure out XML syntax that works in the same way across all backend drivers. Of course OpenVZ has some unique concepts of its own which is fine, but other areas like networking does share some level of common semantics so where possible we should take advantage of the commonality.

Yeah, that was my aim too. Not to be too different from the existing XML defs. This should not be an issue at all. -- Shuveb Hussain. I blog at http://binarykarma.org Spread the Karma.

Hi, [snip]

There are things a bit surprising: - vpsid: I assume it's an identifier for that domain, not as permanent as the UUID but which should be sufficient to designate a running domain, right ? If yes make it an id attribute in the top element domain as in the example at http://libvirt.org/format.html

I think I'll stick to 'id' as suggested by Daniel.

- profile: what is this ? shouldn't the associated informations actually be in the XML and not in some kind of config files (libvirt is being extended to be network aware, referencing a remote description would be a problem)

I had eariler posted a question on the list asking if a daemon is needed to implement the backend. But Daniel answered saying it is OK not have a daemon. So, I'm implementing OpenVZ support without one. How do we make it network aware if there is no daemon? Is this kinda becoming a requirement for Libvirt? In that case, I'll make it the backend a daemon. It is easier to change it now when it is simple. Every OpenVZ VM has a configuration file. This is created from a base config file. There are 2 well known base config files in OpenVZ currently one being normal and the other "lite". During VM creation, the base config file is simply copied and VM specific changes are appended to it. Actually speaking, these are VM properties and can be part of the XML def. But these are also very low level properties specific to OpenVZ. The Libvirt OpenVZ driver does not depend on the OpenVZ utilities(binaries), but some OpenVZ helper scripts, yes. Like the one that creates a VM by untaring the template cache, copying the profile file, etc. It is necessary that OpenVZ tools be installed for the driver to work properly, though nothing is needed at compile time.

- os: that's probably one place where OpenVZ may be quite different from Xen and QEmu, still what does the string 'slackware-10.2-i386-minimal' mean ? Is that a pointer to a file ? If yes shouldn't the associated content be in the XML instead

OpenVZ supports only Linux. This item must reflect which distro the user wants. Or are there better ideas?

For the networking <network> looks more like what Mark did in the last week, I would rather keep the same interfaces, however I'm suprized that you're not listing any device in the format, not even one for the network interface.

I'll follow what Daniel has suggested here. Thanks! -- Shuveb Hussain. I blog at http://binarykarma.org Spread the Karma.

Hi,

...

...

- os: that's probably one place where OpenVZ may be quite different from Xen and QEmu, still what does the string 'slackware-10.2-i386-minimal' mean ? Is that a pointer to a file ? If yes shouldn't the associated content be in the XML instead

OpenVZ supports only Linux. This item must reflect which distro the user wants. Or are there better ideas?

Is that distro a path on the main OS, a config file ?

Not a config file. It is the name of a template cache(just a tar file containing a root fs). This is uncompressed to create the VM's new root fs. Usually OpenVZ users will download several template caches, one for each Linux distro. While creating a VM, the name of the distro needs to be passed to the creation function. A ".tar.gz" is then appended to the template name and that file is looked for at a predesignated location. If it is found, it is untared to create the new VM's root fs. Else -1. :-) -- Shuveb Hussain. I blog at http://binarykarma.org Spread the Karma.

Hi,

- os: that's probably one place where OpenVZ may be quite different from Xen and QEmu, still what does the string 'slackware-10.2-i386-minimal' mean ? Is that a pointer to a file ? If yes shouldn't the associated content be in the XML instead

Under OpenVZ, there is no choice for the user as far as the OS is concerned. He has to live with Linux and Linux alone :-) So, in OpenVZ I think there is not need to specify '<os>' at all. When we are talking about a template, we are actually talking about what becomes the file system for the VM, so we should probably have something like this: <disk> <template>fedora-core6-i386-minimal</template> </disk> Also, it is possible to specify VM level and VM user/grp level disk quotas for VMs in number of 1K blocks. These can also go under the 'disk' tag. But I think I will discuss this later. <disk> <template>fedora-core6-i386-minimal</template> <quota level='vm'>102400</quota> <quote level='user' username='root'>102400</quota> </disk> Regards, -- Shuveb Hussain. I blog at http://binarykarma.org Spread the Karma.

Hi Dan,

Looking at the kind of information you need to represent for a guest filesystem I think we might be better off inventing a new tag here instead of using <disk>. The <disk> tag is really about exposing some file / device as a virtual disk to the guest OS. OpenVZ doesn't have any formal concept of virtual disks - it is really a just dealing in terms of a filesystem. Having the info under <disk> doesn't help any applications like virt-install / virt-manager because the contents of the <disk> element bears no resemblance to that used for Xen / QEMU.

So I think this is a really a fundamental modelling difference for VM based virtualization, vs container based virtualization and thus we should invent a new tag here.

I've not got a good name yet, so I'll just suggest:

<filesystem> <template>fedora-core6-i386-minimal</template> <quota level='vm'>102400</quota> <quote level='user' username='root'>102400</quota> </filesystem>

Other ideas instead of 'filesystem' could be 'image', 'root', or 'container'

I think 'filesystem' is a good choice for the tag if 'disk' is a bad one. The discussion has been good and has given me an idea about what the XML def must look like for OpenVZ without being too different from the base XML format. I'll go work on the parser now. -- Shuveb Hussain. When you lose, be patient. When you achieve, be even more patient. EasyVZ: http://easyvz.sourceforge.net Blog: http://binarykarma.org

Hi Rich,

I think again we're entering into territory where virt-manager and other clients need to "just know" about the XML format and other quirks of the particular libvirt driver. That's not a high-level virtualisation API.

I have been thinking about that. OpenVZ is definitely very different from Xen or Qemu, which emulate whole machines. OpenVZ is just a container. There are so many tunable parameters for OpenVZ. Some of them are: * Max number of files that a VM can open * Max number of sockets * Max number of mmaped() pages * Guarunteed minimum CPU units * Maximum CPU units There are many other parameters. Please have a look at EasyVZ, an OpenVZ management GUI that I wrote. The screenshots are here: http://easyvz.sourceforge.net This will give you an idea of the tunable items that need to be presented to the user by any libvirt client for OpenVZ hosts. With the current scheme, this does not look possible. I also believe that the reason many people choose OpenVZ is because they can guarantee some amount of CPU power and memory to VMs and customers like it that way. These options must be provided by any client that manages OpenVZ based guests. I do not think that these options will hold any meaning when it comes to other VMs. So, how we go about keeping libvirt high level and still address these issues will be very interesting indeed.

Long email in preparation on this subject ... I won't spoil your anticipation.

Expecting this one soon :-) Regards, -- Shuveb Hussain. When you lose, be patient. When you achieve, be even more patient. EasyVZ: http://easyvz.sourceforge.net Blog: http://binarykarma.org

Hi,

Did you have any code to support OpenVZ that I can look at? I was looking at how OpenVZ concepts map to libvirt concepts, and don't want to duplicate your efforts.

Work has slowed down recently, but I have the very basic stuff up. Listing of VMs works and VM creation support is partially done. I'm resuming work on this now. Its partially an issue with the OpenVZ tools licensing - the tools are under the GPL and I have to duplicate all the code by re-writing. I have writen to the OpenVZ team and there seems to be some discussion on this topic. One of the SWsoft developers mentioned about a re-write of the tools - possibly taking care of the licensing issues. If this happens soon, it will be very nice.

(BTW, you can send me code in private if it's embarrassing / half-finished :-)

Ah, I will mail code to you in private if need be. :-) -- Shuveb Hussain. When you lose, be patient. When you achieve, be even more patient. EasyVZ: http://easyvz.sourceforge.net Blog: http://binarykarma.org