On Wed, Dec 15, 2021 at 3:58 PM Juergen Gross <[email protected]> wrote:

> On 15.12.21 16:02, Oleksandr wrote:


> In practice we are having something like the "protocol" already today:
> the disk device name is encoding that ("xvd*" is a Xen PV disk, while
> "sd*" is an emulated SCSI disk, which happens to be presented to the
> guest as "xvd*", too). And this is an additional information not
> related to the backendtype.
>
> So we have basically the following configuration items, which are
> orthogonal to each other (some combinations might not make sense,
> but in theory most would be possible):
>
> 1. protocol: emulated (not PV), Xen (like today), virtio
>
> 2. backendtype: phy (blkback), qdisk (qemu), other (e.g. a daemon)
>
> 3. format: raw, qcow, qcow2, vhd, qed
>
> The combination virtio+phy would be equivalent to vhost, BTW. And
> virtio+other might even use vhost-user, depending on the daemon.
>

Sorry to fly in here 7 months after the fact to quibble about something,
but since we're baking something into an external interface, I think it's
worth making sure we get it exactly right.

It seems to me that the current way that "backendtype" is used is to tell
libxl how to set up the connection.  For "phy", it talks to the dom0
blkback driver, and hands it a file or some other physical device.  For
qdisk, it talks to the QEMU which is already associated with the domain:
either the qdisk process started up when the PV/H domain was created, or
the emulator started up when the HVM guest was created.  (Correct me if
I've made a mistake here.)

Given that, "other" is just wrong.  The toolstack needs to know
*specifically* how to drive the thing that's going to be providing the
protocol.  I'm not sure what you're expecting to use in this case, but
presumably if we're adding a third thing (in addition to blkback and QEMU),
then at some point we're going to be adding a fourth thing, and a fifth
thing as well.  What do we call them?  "Other other" and "other other
other"?

If we're planning on having a general interface for these daemons that are
going to be be virtio providers, we should come up with a specific name for
them as a class, and use that for the name.

Furthermore, "virtio+phy == vhost" is just wrong: phy means that libxl is
using blkback, and blkback can't speak the virtio protocol.  If we want to
use vhost (or something like it), then it will need its own separate
backendtype.

 -George

Reply via email to