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

[Juergen Gross <jgross@xxxxxxxx>]

On 24.06.22 14:45, George Dunlap wrote:
> On Wed, Dec 15, 2021 at 3:58 PM Juergen Gross <jgross@xxxxxxxx 
> <mailto: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"?
The idea was to allow an unspecified external component to be used. It
would only need information available in Xenstore and "do the right thing".

This allows to have custom backends without having to modify (lib)xl or
the config syntax in case a new one is being added.

In case Xenstore isn't enough for the needed information of a new backend,
a more specific backendtype would be needed.

> 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.
Really? Today "virtio" + "phy" isn't used anywhere, as it currently makes no
sense. Just because "phy" has been used for blkback, it doesn't mean that
this needs to stay this way. With the new scheme, "xen+phy" means blkback,
while "virtio+phy" is yet undefined. Identifying "phy" with a "physical device",
it would make sense to use "virtio+phy" for vhost, as vhost-block is the
equivalent to blkback in the virtio world.


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature