[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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 :|


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]