Re: [Libvir] RFC 'xen like scripts'
On Mon, May 05, 2008 at 10:50:25PM +0200, Stefan de Konink wrote:
On Mon, 5 May 2008, Daniel P. Berrange wrote:
> > 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).
So you're wanting to pass this URL directly to the domain config, rather
than the storage pool ? If so, then I'd suggest a different approach
which is to extend the domain XML so it can refer to a libvirt managed
storage volume explicitly
Instead of doing
<disk type="block">
<source dev="/dev/sdf"/>
</disk>
Refering to the storage pool and volume name (which are independant of
the disk path)
<disk type="vol">
<source pool="somepool" vol="somelun"/>
</disk>
When starting the VM, libvirt can turn the pool + volume name into a
path.
The other way around would be to 'postprocess' my
configurations before I
push them inside libvirt. But then I get another problem, migration.
Migration is one of the reasons for having a clear description of the
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?
The problem with the Xen approach to storage is that there is no definition
of the semantics of the URIs, other than the fact that the URI scheme maps
to an arbitrary shell script. The semantics of the configuration are very
important for apps to be able to interpret.
The Xen scripts only setup the storage at the time the VM starts, so
there is no way to validate apriori that the configuration is actually
meaningful. With an iSCSI hotplug script there's not even any connection
existing until the VM starts.
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.
I'm struggling to understand where there's needs to be a netapp specific
impl of the iSCSI backend. Either netapp complies with iSCSI spec or it
doesn't. The iSCSI backend is inteded to work with any compliant server.
Or are you trying to use to netapp specific functionality that isn't
actually part of its iSCSI support ?
Dan.
--
|: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|