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.