[libvirt] libvirt API/design questions

[Peter Krempa]

On Thu, Dec 12, 2019 at 11:13:02 +0000, Daniel Berrange wrote:
> On Wed, Dec 11, 2019 at 09:45:07AM -0500, Cole Robinson wrote:

[...]

> > * vhost-user-scsi and vhost-user-blk XML schema
> > https://www.redhat.com/archives/libvirt-users/2019-October/msg00018.html
> > 
> > Last proposal was using <hostdev> for this, which revisiting it now
> > makes more sense than <disk>, because it vhost-user-X doesn't seem to
> > use qemu's block layer at all. So vhost-user-scsi would be:
> > 
> >     <hostdev mode='subsystem' type='scsi_host'>
> >       <source protocol='vhostuser' type='unix'
> > path='/path/to/vhost-user-scsi.sock' mode='client'/>
> >     </hostdev>
> > 
> > vhost-user-blk maybe requires a new type='block' ? Otherwise it's
> > unclear how to differentiate between the two. Regardless it would be
> > nice to give the original patch author guidance here, they seemed
> > motivated to get this working
> 
> This is a really tricky question in general. It is basically saying
> whether we consider <disk> to refer to the guest visible device
> type or the QEMU visible backend type.
> 
> Originally these were always the same thing, but offloading to
> vhostuser has blurred the boundaries. I think in non-QEMU hypervisors
> where you don't have a split of frontend&backend in the config, you'd
> just have disks no matter what.
> 
> With network we've continued to use <interface> with vhost-user.
> 
> This makes me biased towards <disk>, at least for vhost-user-blk.

Alternatively we can make it more clear by properly using the <driver
name=''> attribute. If qemu is driving the backend we put 'qemu' in it,
but other values can apply.

This will also make sense e.g. when the qemu storage daemon will become
a thing to configure that interface without confusion.