VMchannel Requirements: Difference between revisions
From KVM
(Add page for vmchannel; list out a few requirements.) |
(History - Add a couple of more approaches that were tried on user networking) |
||
Line 46: | Line 46: | ||
** The guest firewall may block access to the host IPs | ** The guest firewall may block access to the host IPs | ||
** Windows can't bind sockets to specific ethernet interfaces | ** Windows can't bind sockets to specific ethernet interfaces | ||
* via user net <br>http://thread.gmane.org/gmane.comp.emulators.qemu/35780 | |||
* via slirp <br>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 |
Revision as of 00:37, 26 June 2009
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