RE: [libvirt] Re: iSCSI Multi-IQN (Libvirt Support)
-----Original Message-----
From: Dave Allan [mailto:dallan@redhat.com]
Sent: Tuesday, October 27, 2009 2:57 AM
To: Iyer, Shyam
Cc: libvir-list(a)redhat.com; Bellad, Sudhir; Domsch, Matt; KM, Paniraja
Subject: Re: [libvirt] Re: iSCSI Multi-IQN (Libvirt Support)
<Snip>
Ok, you're proposing what I thought you were proposing. My
objection
to
what you want to do is that I think this sort of complexity is better
done in the client application than in libvirt. In other words, I
think
that *some code*, *somewhere* is going to have to loop through all the
sessions and create and delete each one and enumerate the LUs on each
session. I think we are only debating whether that loop should be in
the client application or in libvirt. Why do you think we should put
that complexity into libvirt?
Ok. I was looking at giving an api that will facilitate this for the
client easily but I see your point as well in the context of the present
design..
So, we will stick to the following paradigm-
1) No initiator iqn in the xml would mean use of the default initiator
iqn name
2) Initiator iqn provided would mean a unique session to be created
using the provided iqn name.
3) Single iSCSI session per pool
A few points though -
The virt-manager GUI will need more intelligence built around easy
manageability of pools.
1) More information on the pools.
2) Ability to group multiple pools.
2) Ability to delete multiple pools for easy administration.
* This would be useful in an environment where there may be tens of
arrays, hundred pools and a few more hundred LUNs.
* For the visual experience if we stick to the 1session per pool design
we would find multiple pools for the same target iqn and also pointing
to the same luns and filing up the GUI screen unnecessarily sometimes
...
Should this be discussed in the virt-manager lists also ?