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

Daniel P. Berrangé berrange at redhat.com
Thu May 17 12:22:44 UTC 2018


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"

>       <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.

> So far I've tested in a setup with 40 VMs for several days with a mix of
> continuously running/restarting VMs and a simple 'virtio client' inside
> each VM.

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

> 
> Well, before this gets to detailed I guess it's better to have a look into my changes ;-)
> 
> https://github.com/TrappM/vhostmd/commit/4e33175cd403bc1c4f5725b5fe68c74dc209e30a
> 
> 
> 
> Michael
> 
> 
> 
> 
> _______________________________________________
> virt-tools-list mailing list
> virt-tools-list at redhat.com
> https://www.redhat.com/mailman/listinfo/virt-tools-list

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|




More information about the virt-tools-list mailing list