[Libvir] [RFC]OpenVZ XML def
veillard at redhat.com
Tue Mar 13 21:15:28 UTC 2007
On Wed, Mar 14, 2007 at 12:20:06AM +0530, Shuveb Hussain wrote:
> > 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.
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.
> 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.
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.
> > - 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 ?
> > 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
> I'll follow what Daniel has suggested here.
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
More information about the libvir-list