VMchannel Requirements
From KVM
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)
- An API inside qemu to communicate with agents in the guest
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 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