[virt-tools-list] vhostmd - virtio channel support

[Trapp, Michael]

On 17.05.18, 14:23, "Daniel P. Berrangé" <berrange at redhat.com> wrote:
> On Thu, May 17, 2018 at 12:13:58PM +0000, Trapp, Michael wrote:
> > Hi
> >
> > I would like to add virtio based communication to vhostmd.
> >
> > The current vhostmd implementation writes the metric data of all VMs and
> the host to a single file. This file is mapped as a disk to all VMs and due to that
> every VM can see all VMs and also has access to the whole data set of all
> VMs.
> > >From security perspective this could be more restrictive and a ‘per  VM’
> view on the data would help to improve the situation a bit.
> >
> >
> > So far I have implemented the virtio channel based communication
> between VMs and vhostmd and tested the feature in a local setup.
> >
> > Let's start with the relevant VM config:
> > <domain type='kvm'>
> >   <name>vm_015</name>
> >   <uuid>cf335144-567d-11e7-000f-0000594d2d82</uuid>
> > ...
> >     <channel type='unix'>
> >       <source mode='bind' path='/var/lib/libvirt/qemu/channels/cf335144-
> 567d-11e7-000f-0000594d2d82'/>
> 
> Ewww, that is a global namespace you're using there - you can't assume
> this is the only channel using this directory. It needs to include the
> channel target name in the path as a prefix, as well a unique per-VM
> identifier of some kind
> 
> >       <target type='virtio' name='vhostmd'/>
> 
> We'd generally recomend reverse domain name for channel names, along
> with
> a version number in case protocol needs to change. eg perhaps
> 
>    "org.github.vhostmd.1"
Okay, I've changed the expected channel name to 'org.github.vhostmd.1.<UUID>'

> >       <address type='virtio-serial' controller='0' bus='0' port='1'/>
> >     </channel>
> >
> > Based on that, the VM can access the virtio channel on /dev/vport1p1
> 
> Again, this mustn't assume there's only one channel - there are symlinks
> created in the guest based on the target name that should be used.
Inside the guest:
    ls -l /dev/virtio-ports/vhostmd 
    lrwxrwxrwx. 1 root root 11 18. Mai 18:11 /dev/virtio-ports/vhostmd -> ../vport0p1
The /dev/vportXpY is already accessible via symlink and there is no need to change anything in the vhostmd code on the host side.
That seems to be a configuration/documentation task ...

> The main troublespot with virtio channel is that the guest sees a EOF
> across live migration, so the protocol needs to be able to resynchronize
Correct, but this does not affect the vhostmd on the host. Currently clients on the guest do not support 'virtio channel' and have to be fixed but as long as the metrics are written to a 'disk file' both access methods are available, based on the guests qemu configuration