Re: RFC 'xen like scripts'

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

 



On Mon, May 05, 2008 at 11:39:44PM +0200, Stefan de Konink wrote:
> On Mon, 5 May 2008, Daniel P. Berrange wrote:
> > > 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 ?
> 
> Short answer:
> 
> NetApp puts *all* iSCSI luns on one connection.
> 
> Add 'automatic' lunnumbering and no explicit exported comments
> in Vendor names etc. to the scenario and you see my ballpark.
> 
> 
> So to make it more simple:
> 
> OpenSolaris		NetApp
> All Luns exported	Per hostgroup export of all assigned luns
> Maintains 'use'		Doesn't know if a specifc lun is used
> Uses an identifier	Uses one iSCSI identifier, needs rescanning
> 			lun can be fetched from 'configuration interface'
> 
> 
> Due to the reason all LUNs are exported over one connection, a
> rescan before usage a rescan is always required. LUN numbering is not
> stable, nor they can be found at the client side.

So where does the information mapping netapp pathnames to the the LUNs
come from ? If LUNs can change when re-scanning what happens to LUNs
already in use for other guests ? It doesn't sound usable if LUNs that
are in use get renumbered at rescan.

AFAICT this is basically just suggesting an alternate naming scheme for
storage volumes, instead of 'lun-XXX' where XXX is the number, you want
a name that's independant of LUN numbering. So the key question is where
does the information for the persistent names come from  ?

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

--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]