Re: [Qemu-devel] [Qemu-block] [PATCH] tcmu: Introduce qemu-tcmu utility

[Yaowei Bai]

> > > * The first priority should be adding an in-process iscsi target that
> > >   can be managed with QMP, similar to the built-in NBD server.
> > 
> > Well, people used to manage iscsi targets through targetcli, a command
> > line utility. Our intention is, with targetcli and qemu-tcmu, user can
> > create/remove targets and backstores totally in just one place, so you
> > don't need to create targets in targetcli and then turn to configure
> > backstores in qemu-tcmu with QMP or command line, it's convenient.  So
> > we decide to implement QMP in the future release but it's definitely
> > in our plan.
> 
> I think QMP needs to come first to result in a clean design, because the
> command line tool should only be a wrapper around the QMP code.

Yeah, i agree this makes more sense from this point. Ok, i'll try to
implement it in v2 as your suggestion. Thanks.

> But anyway, I still think the change I had in mind is necessary. Maybe
> you can see the difference best in an example. Your documentation says
> to use this:
> 
>     # qemu-tcmu
>     # targetcli /backstores/user:qemu create qemulun 1G 
> @address@hidden/root/test.file

Let's call this one case1.

> 
> I think it should work more like this:
> 
>     # qemu-tcmu -blockdev 
> driver=file,filename=/root/test.file,node-name=my_file \
>                 -export my_export,node=my_file
>     # targetcli /backstores/user:qemu create qemulun 1G my_export

And this one case2.

> 
> In fact, something like this is probably required if we want to export
> existing block nodes (that may be in use by a guest) from a running QEMU
> instance. In this case, you don't want to open a new image file, but
> export the already opened image file.

I think the main difference between these two cases is just how the 
configuration
of exported image file is passed to qemu-tcmu. Case1 uses cfgstr while case2
uses command line. Case2 still needs one way to check whether the passed-in
image file was opened, right? If so, case1 should also be able to use the same
way to check that after extracting cfgstr. 

Actually we thought about qemu-tcmu working like case2, but felt is's quite less
flexible. With case2, e.g. when we want to export another new image file with
one qemu-tcmu already running, we have to run another qemu-tcmu with
the configuration of the new image file in commandline, or through QMP of the
running qemu-tcmu, and then configure it with targetcli. So anyway,
there's one more step for case2 to export a new image file. While for case1 
you just need to run qemu-tcmu once and all other operations will be done
within targetcli, which is more friendly to users i think.

So i think qemu-tcmu's quite different from qemu-nbd at this point. We can
export a image file by NBD protocol just with qemu-nbd itself. While for
qemu-tcmu we still need targetcli to complete other ISCSI target
configurations to export a image file. So moving the configuration of image
file from cmdline to targetcli should be reasonable in my opinion.

> 
> (Also, can we somehow get rid of the 1G in the command line? qemu-tcmu
> knows how big the image is and can provide this value.)

Currently this size option is mandatory in targetcli, not all tools are
so smart as QEMU. But maybe we could change it optional in the future.