On Tue, Mar 13, 2007 at 10:57:23PM +0530, Shuveb Hussain wrote: 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 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 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 ? 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. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

On Tue, Mar 13, 2007 at 10:57:23PM +0530, Shuveb Hussain wrote: Hi, Excellent news ! as fixed in second mail In general I expect we will need to do some exchanges over the format, first to try to get as much as possible something similar to the existing XML instances for the other engines like Xen and QEmu, and second to understand the ways in which OpenVZ is sufficiently different that it requires a change in markup. 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 - 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) - 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 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. So as-is the format is really too different from what I would expect, also the XML must be sufficient to fully describe a domain instance, so this will probably require some discussion to find out what is really needed in it :-) Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

On Wed, Mar 14, 2007 at 12:20:06AM +0530, Shuveb Hussain wrote: I would expect the daemon to work by using the internal libvirt driver model, and not tied to the specifics of the virtualization engine. So hopefully no daemon is needed specifically for OpenVZ but it's better have has much of the informations exposed in the XML rather than referencing files whose content is not available remotely. Okay, I guess in a first time referencing the 2 default modes by name should be sufficient, but we need to see what would make sense to be exposed. We already have an open <features> set used for Xen fully virtualized guests, and things like <emulator> in the devices section, so we have placeholders for relatively low level and specific settings. Is that distro a path on the main OS, a config file ? okay, Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

On Wed, Mar 14, 2007 at 08:38:51AM +0530, Shuveb Hussain wrote: Okay, then it really cannot be extended at that level any further than a bare string, thanks for the informations :-) Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

On Wed, Mar 14, 2007 at 12:32:36AM +0530, Shuveb Hussain wrote: 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' Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

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. Long email in preparation on this subject ... I won't spoil your anticipation. Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 "[Negative numbers] darken the very whole doctrines of the equations and make dark of the things which are in their nature excessively obvious and simple" (Francis Maseres FRS, mathematician, 1759)

Shuveb Hussain wrote: 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. (BTW, you can send me code in private if it's embarrassing / half-finished :-) Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903