[linuxkernelnewbies] VMchannel Requirements - KVM

[Peter Teoh]

http://www.linux-kvm.org/page/VMchannel_Requirements Requirements We want an interface between the guest and the host The channel is to be used for simple communication, like sharing of the clipboard between the user desktop and the guest desktop For relatively low rate of data transfer -- a few MB/s Events to be delivered to the guest, like 'shutdown', 'reboot', 'logoff' Queries to the guest, like 'which users are logged in' Survive live migration Support for multiple agents (consumers of the data) on the guest Multiple channels could be opened at the same time In multi-channels case, one blocked channel shouldn't block communication between others (or one channel shouldn't hog all the bandwidth) Stable ABI (for future upgrades) Channel addressing An agent in the guest should be able to find the channel it's interested in Dynamic channel creation Security No threats to the host Unprivileged user should be able to use the channel Should work out of the box, without any configuration necessary on the part of the guest Notifications of channels being added / removed (hotplugging) Notifications on connection / disconnection on guest as well as host side An API inside qemu to communicate with agents in the guest [edit] History A few reasons why the obvious solutions do not work: via the fully emulated serial device. performance (exit per byte) scalability - only 4 serial ports per guest accessed by root only in the guest via TCP/IP network sockets The guest may not have networking enabled The guest firewall may block access to the host IPs Windows can't bind sockets to specific ethernet interfaces via user net http://thread.gmane.org/gmane.comp.emulators.qemu/35780 via slirp This implementation does exist upstream as "-net channel" http://www.nabble.com/-PATCH--specify-vmchannel-as-a-net-option-td21911523.html Again, based on networking so same drawbacks mentioned above apply Currently used by libguestfs [edit] Use Cases Guest - Host clipboard copy/paste operations By a VMM or via an internal API within qemu libguestfs (offline usage) For poking inside a guest to fetch the list of installed apps, etc. Online usage Locking desktop session when vnc session is closed Cluster I/O Fencing aka STONITH Current models require networking between guest/host fence_virsh, xen0 -> ssh to defined host and to perform fencing; no migration tracking; requires ssh key distribution to work. fence_xvm -> tracks migrations, but requires multicast between guest/host; distributed key recommended but not required Using VMChannel-Serial, the requirement of guest-host can be avoided Key distribution of any sort can be avoided, making this easier to configure than existing solutions