Re: [Libvir] RFC 'xen like scripts'
On Mon, 5 May 2008, Daniel P. Berrange wrote:
> So I pose a simple request: would anyone be able to create a
xen-like
> storage backend that in principle passes the URI to a script (that runs as
> a fork) this script sets for example an envirionment variable or text
> output, the code uses this envirionment variable as path to the storage
> area. And a great prototypable system has been created.
This kind of plugin functionality is delibrately not exposed in libvirt.
The XML configuration for a guest is intended to provide a description of
a guest with guarenteed semantics which is portable to any machine using
libvirt. If we were to enable arbitrary admin provided scripts on the
backend the semantics could not longer be guarenteed.
I agree on your argument, but this limitation in flexibility is a real
show stopper. If only it was a 'dev backend' it would be a great help.
Like we discussed before; our both intentions are to kill xend, but
prototyping in libvirt is currently SM.
> It could be a question by some: 'why doesn't he write a
simple
> implementation in C?' basically: I'll will do this, no worries about that
> one, but I would like to be able to prototype my programs first.
While I understand your desire to be able to prototype things quickly
I don't want to expose a generic scriptable plugin in the libvirt backend
BTW, if you want any hints / advise / help with making the iSCSI stuff work
on OpenSolaris let me know. I'm assuming the iSCSI admin tools on Linux are
rather differnent in calling conventions, but the general principles of
the Linux impl should still apply.
I'm not running it *on* Open Solaris (although I would like to do this),
I'm currently creating the tools to be able to talk to an arbritary
'storage backend' to 'create/clone/snapshot/destroy' and in our case:
'create/remove users'. Since this works for NetApp and ZFS now purely
remote based it is rather dynamic.
To implement the iSCSI connection to NetApp I would prefer to pass:
netapp://username/partition
I would prefer to let libvirt figure out where the lun can be found on the
system. (This involves connecting to the fileserver, fetching the LUN,
looking up the connection on the Linux side, reading the symlink).
The other way around would be to 'postprocess' my configurations before I
push them inside libvirt. But then I get another problem, migration.
In my humble opinion a scriptable way doesn't need to be something bad.
Like with Xen the URI can be parsed or not. Would a patch be accepted?
For the iscsi backend, like we have discussed before, just discovery needs
to be implemented. The problem with the NetApp implementation is that it
exports all 'luns' at the same time. Technically this can be done 'host
based', but still *far* from implementable in libvirt using the current
configuration.
Stefan