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. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
