I do recognize that there is real need to provide password to iscsi (and rbd?) via the monitor. I myself do not use libvirt (it is just too much pain to be worth it to try to upgrade it out-of-step with your distribution) but I recognize that likely vast majority of users would use libvirt.
Once consensus is reached on "how to handle devices that need two-stage setup" and what it would look like I can volunteer to implement it. It would however be way out of scope of and bigger than a simple iscsi-local patch What about the idea about splitting .open() into two stages: .open() /* stage one, called before -S monitor is invoked */ .open_stage_2() /* called after -S finishes and when it starts to boot the guest CPU */ ? regards ronnie sahlberg On Fri, Dec 23, 2011 at 8:08 PM, Paolo Bonzini <pbonz...@redhat.com> wrote: > On 12/22/2011 09:51 PM, ronnie sahlberg wrote: >> >> 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're right. > > I see that the libvirt driver for rbd simply passes it on the command line. > I hope I'll be able to review the patch further today. > > Paolo