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

Re: [PATCH V6 1/2] libxl: Add support for Virtio disk configuration



On Wed, Dec 15, 2021 at 3:58 PM Juergen Gross <jgross@xxxxxxxx> 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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.