qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] This patch adds a new block driver : iSCSI


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] [PATCH] This patch adds a new block driver : iSCSI
Date: Thu, 13 Oct 2011 11:55:57 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

On Thu, Oct 13, 2011 at 11:01:49AM +0100, Daniel P. Berrange wrote:
> On Thu, Oct 13, 2011 at 08:46:54PM +1100, ronnie sahlberg wrote:
> > Previous version of the patch received very positive feedback and
> > several expressed seeing positive value of a built-in initiator.
> > I updated patch from feedback 3 weeks ago and Stefan kindly reviewed it.
> > 
> > 
> > Is there some other problem with the patch I am not aware of that I
> > should address?
> > 
> > I have been trying to push this patch in different versions since
> > December last year.
> > There is obviously a problem here I am not aware of.
> > Please advice what the problem is and I will try to rectify it.
> > 
> > 
> > Please advice on how I can move forward. I feel a bit at roads end
> > here. Please help.
> 
> I can't comment much on the code, but I'm supportive of QEMU gaining
> this feature, because it addresses a number of use cases not satisfied
> by using iSCSI via the host OS's block layer.
> 
> 
> > >>> You can specify devices using a iscsi url of the form :
> > >>> iscsi://[<username>[:<password>@]]<host>[:<port]/<target-iqn-name>/<lun>
> > >>> When using authentication, the password can optionally be set with
> > >>> LIBISCSI_CHAP_PASSWORD="password" to avoid it showing up in the process 
> > >>> list
> 
> I'm not a fan of sending passwords via command line args, or
> environment variables.  Env variables *can* be exposed via
> the process list, albeit not to unprivileged users. More
> critically, env variables will end up in logfiles like
> /var/log/libvirt/qemu/$GUESTNAME.log, and in data reported
> to distro bug trackers, via tools like sosreport which
> capture /proc/$PID/environ and aforementioned logfiles.
> 
> We have a similar requirement for specifying passwords with
> the Ceph/RBD driver, and also for the curl/HTTP block drivers.
> We have a monitor command for providing decryption passwords for
> QCow2 disks. We could either reuse that for connection passwords,
> or perhaps slightly better would be to have a separate command
> for connection passwords.

NB, I didn't mean to suggest that this issue should block merging
of this iSCSI driver. The problem with passwords already exists for
Ceph & Curl drivers, and I believe the Ceph developers are already
working on a patch for QEMU which should be able to apply to all
these network block devs

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|



reply via email to

[Prev in Thread] Current Thread [Next in Thread]