On Thu, 2011-09-15 at 13:58 +0200, Paolo Bonzini wrote: > On 09/15/2011 01:42 PM, Dor Laor wrote: > >> > >> However, iSCSI is a complex protocol and a complex suite of tools. With > >> a simpler set of tools such as qemu-nbd/nbd, you can for example tunnel > >> data over the libvirt connection. Possibly with encryption. Also, with > >> iSCSI you're tied to raw, while qemu-nbd lets you use qcow2. > > > > My main motivation for external iScsi is to provide qemu operations w/ > > non shared storage. Things like streaming an image w/o shared storage or > > block live migration can be done where the src host exposes iscsi target > > and the destination is the initiator. In case of qcow2, every snapshot > > in the chain should be exposed as a separate LUN. The idea is to ignore > > the data in the guest image and treat it as opaque. > > Then you need an iSCSI *target* that understands qcow2, like qemu-nbd > but for iSCSI... that's exactly the thing you were worried about > implementing. Not really , this is just part of the target configuration. For each file in the chain we create a lun in the target that is backed by the file and we number the luns in chronological order (base is lun 1) . you can look at a tgtd configuration here http://wiki.qemu.org/Features/LiveBlockMigration#Example_single_base_master_image. Orit
> > (Of course you could use qemu-nbd and expose /dev/nbd* via iSCSI, but it > starts looking like an exercise in adding layers of indirections! :)). > > Paolo >