Re: [Qemu-devel] [PATCH] iSCSI: add configuration variables for iSCSI

[ronnie sahlberg]

Hi,

You mean using the '-S' mode and setting the key after qemu has
initialized all devices but before it actually starts booting the
guest?
That would not be easy and would probably require some intrusive in
qemu itself that might affect other device types, so I am unsure.

The difference between qcow2 and iscsi and the problem is that .open()
is called for all devices before the monitor is started, so .open() is
called before we would have a chance to even hand the password to
qemu.

For qcow2 this is not a problem since even if the file is password
protected the file header is not, so you can still open the file and
read the header (to discover it is password protected) without knowing
the password.
So qcow2 can still open the file and do all the sanity checks it needs
without yet knowing the password.
You only need the password at a much later at the stage when you want
to actually start doing I/O to the device.


iSCSI is different because the username/password is not really
associated with the LUN or doing I/O, the password is required to
connect to the iscsi target itself, so without the password we can not
even connect to the target, much less run REPORTLUNS or TESTUNITREADY
to check if the LUN even exists. We cant even check if the target iqn
name even exists at all without the password.


So to pass the password similarly to how qcow2 does it, I see three
options, neither of which are especially attractive :

1, Change iscsi_open() to become a NOOP, dont even try to connect to
the target until the CPU is started (and -S has passed the password)
and do the connect on first i/o  instead of .open()
This would mean that if the target or the LUN does not even exist at
all, we wont get an early failure where QEMU would fail to start due
to "the device does not exist", instead the error would be postponed
until much later and cause qemu to error out on first i/o.
This looks like a horrible kludge.

2, Change -S so that it is called before qemu calls any of the .open()
functions for block devices.
I am not sure what impact this would have and if -S users would be
"surprised" if the monitor is open but the block devices have not yet
been scanned.
This looks difficult to easily integrate with the command line parsing anyway.
This too sounds like a horrible kludge.

3, Add a new block device method   .open_post_start() which is just
like .open()  but invoked after the CPU has been started.
So .open() is called like today before -S monitor is started, then the
new .open_post_start() would be called once -S has started the CPU
with the 'c' command.
In this case for iscsi, .open() could be changed to just create a
context for the device and establish the TCP connection to the target
but it would not log in to the target.
.open_post_start() which could be called for all block devices once
the CPU has been started would then use the context and connection
from .open()
and perform the actual login and discover the LUN.

3 would still be a little bit ugly since a whole set of error
conditions such as "target iqn does not exist", "lun does not exist",
"wrong type of LUN", "incorrect password" ...  would not be detected
until once the guest CPU is actually started.
Would be less ugly than options 1,2 though.


But even with something like option 3, to make it possible to use -S
to provide the password, this is mainly for addressing the case when
running via libvirt ? I still want to provide a mechanism for setting
the password directly in a configuration file for users that run qemu
directly from the command line and are not using -S.


comments ?


regards
ronnie sahlberg


On Mon, Dec 19, 2011 at 12:48 AM, Paolo Bonzini <address@hidden> wrote:
> On 12/18/2011 05:48 AM, Ronnie Sahlberg wrote:
>>
>> This patch adds configuration variables for iSCSI to set
>> initiator-name to use when logging in to the target,
>> which type of header-digest to negotiate with the target
>> and username and password for CHAP authentication.
>>
>> This allows specifying a initiator-name either from the command line
>> -iscsi initiator-name=iqn.2004-01.com.example:test
>> or from a configuration file included with -readconfig
>> [iscsi]
>>   initiator-name = iqn.2004-01.com.example:test
>>   header-digest = CRC32C|CRC32C-NONE|NONE-CRC32C|NONE
>>   user = CHAP username
>>   password = CHAP password
>
>
> header digest and user look like they should be options to the block driver.
>  For the password you can reuse the system used by qcow2 perhaps?
>
> Paolo