[libvirt] Re: [Patch v0.4] iSCSI Multi-IQN (Libvirt Support)

Shyam_Iyer at Dell.com Shyam_Iyer at Dell.com
Wed Nov 18 11:07:02 UTC 2009



> -----Original Message-----
> From: Daniel P. Berrange [mailto:berrange at redhat.com]
> Sent: Wednesday, November 18, 2009 4:12 PM
> To: Iyer, Shyam
> Cc: dallan at redhat.com; Bellad, Sudhir; libvir-list at redhat.com; Domsch,
> Matt; KM, Paniraja
> Subject: Re: [libvirt] Re: [Patch v0.4] iSCSI Multi-IQN (Libvirt
> Support)
> 
> On Wed, Nov 18, 2009 at 04:01:53PM +0530, Shyam_Iyer at Dell.com wrote:
> > > -----Original Message-----
> > > From: Daniel P. Berrange [mailto:berrange at redhat.com]
> > > Sent: Wednesday, November 18, 2009 3:50 PM
> > > To: Iyer, Shyam
> > > Cc: dallan at redhat.com; Bellad, Sudhir; libvir-list at redhat.com;
> Domsch,
> > > Matt; KM, Paniraja
> > > Subject: Re: [libvirt] Re: [Patch v0.4] iSCSI Multi-IQN (Libvirt
> > > Support)
> > >
> > > On Wed, Nov 18, 2009 at 01:53:50AM +0530, Shyam_Iyer at Dell.com
> wrote:
> > > > Iscsiadm's -I parameter takes iface name as the parameter value
> and
> > > not
> > > > the iqn name.
> > > >
> > > > So I believe this approach could be taken -
> > > >
> > > > 1) Get the iqn for the corresponding iface name using the
> following
> > > > command
> > > > #iscsiadm -m iface
> > > >
> > > > Example output:
> > > >
> > > > [root at localhost libvirt-0.7.1-15-org]# iscsiadm -m iface
> > > > default tcp,default,default,unknown
> > > > iser iser,default,default,unknown
> > > > bnx2i bnx2i,default,default,unknown
> > > > iface1 tcp,default,default,iqn.1994-05.com.fedora:iqnBellad
> > > > iface3 tcp,default,default,iqn.dell
> > > > iface0 tcp,unknown,unknown,iqn.1994-05.com.fedora:iqnSudhir
> > >
> > > Ah, so where does this mapping come from ? Does the administrator
> have
> > > to
> > > create the mapping between interfaces & iqns, or is this totally
> > > automatic
> > > somehow ?
> > >
> >
> > Today the iface file is created by by iscsi administrators using
> either
> > of the following methods
> >
> > 1) By hand by editing the iface parameters in
> > /var/lib/iscsi/ifaces/<iface_file>
> >
> >
> > Iface.iscsi_ifacename = <iface name>
> > Iface.net_ifacename = <default, eth0 etc>
> > Iface.hwaddress = <default, mac address etc>
> > Iface.transport_name = <tcp, bnx2i etc>
> > Iface.initiatorname = <iqn name>
> 
> This approach isn't really useful for us, since libvirt API is
intended
> to
> be usable remotely without any administrator login.
> 
> > 2) By using iscsiadm commands like the following
> > # iscsiadm -m iface -I <iface_name> -o new
> > # iscsiadm -m iface -I iface1 --op=update -n iface.initiatorname -v
> > <iqnname>
> 
> In that case, why don't we make libvirt automatically set things up
> this
> way whenever it sees the IQN in the XML file.
> 
> > We don't change the default initiatorname with libvirt/virt manager
> > today right ? So, we haven't added any apis to manage the iface file
> > name using libvirt as such.
> >
> > But if required by virt-manager(to create a single window of
> management)
> > the iface file could be constructed using libvirt apis that call the
> > iscsiadm commands detailed in method 2)
> 
> We don't need to add any new APIs for this - just automatically add
the
> mapping whenever logging into a target with a IQN that we don't
already
> know about
> 

How do we ensure that the iqn is not already known and libvirt is
creating the corresponding iface file for the first time? 
That would mean searching through the IFACES_DIR which has been opposed
in the thread...
I guess we should assume that the iqn entered into the xml has already
been checked for uniqueness ...
Is that a fair assumption?

To enable a user to make that unique choice virt-manager should be able
to show iface file configurations. We can go to that route later by
adding libvirt apis that show the already configured iface file
configurations to the user ...

Also, how do we go about creating unique iface filenames when
automatically creating them using libvirt ?







More information about the libvir-list mailing list