https://linux-kvm.org/api.php?action=feedcontributions&user=RichardJones&feedformat=atomKVM - User contributions [en]2024-03-28T08:32:35ZUser contributionsMediaWiki 1.39.5https://linux-kvm.org/index.php?title=VMchannel_Requirements&diff=2351VMchannel Requirements2009-06-26T08:55:17Z<p>RichardJones: typo</p>
<hr />
<div>== Requirements ==<br />
<br />
* We want an interface between the guest and the host<br />
<br />
* The channel is to be used for simple communication, like sharing of the clipboard between the user desktop and the guest desktop<br />
** For relatively low rate of data transfer -- a few MB/s<br />
** Events to be delivered to the guest, like 'shutdown', 'reboot', 'logoff'<br />
** Queries to the guest, like 'which users are logged in'<br />
<br />
* Survive live migration<br />
<br />
* Support for multiple agents (consumers of the data) on the guest<br />
<br />
* Multiple channels could be opened at the same time<br />
<br />
* In multi-channels case, one blocked channel shouldn't block communication between others (or one channel shouldn't hog all the bandwidth)<br />
<br />
* Stable ABI (for future upgrades)<br />
<br />
* Channel addressing<br />
** An agent in the guest should be able to find the channel it's interested in<br />
<br />
* Dynamic channel creation<br />
<br />
* Security<br />
** No threats to the host<br />
** Unprivileged user should be able to use the channel<br />
<br />
* Should work out of the box, without any configuration necessary on the part of the guest<br />
<br />
* Notifications of channels being added / removed (hotplugging)<br />
<br />
* An API inside qemu to communicate with agents in the guest<br />
<br />
<br /><br />
== History ==<br />
A few reasons why the obvious solutions do not work:<br />
<br />
* via the fully emulated serial device.<br />
** performance (exit per byte)<br />
** scalability - only 4 serial ports per guest<br />
** accessed by root only in the guest<br />
<br />
* via TCP/IP network sockets<br />
** The guest may not have networking enabled<br />
** The guest firewall may block access to the host IPs<br />
** Windows can't bind sockets to specific ethernet interfaces<br />
<br />
* via user net <br>http://thread.gmane.org/gmane.comp.emulators.qemu/35780<br />
<br />
* via slirp <br>This implementation does exist upstream as "-net channel" http://www.nabble.com/-PATCH--specify-vmchannel-as-a-net-option-td21911523.html<br />
** Again, based on networking so same drawbacks mentioned above apply<br />
** Currently used by [http://libguestfs.org libguestfs]</div>RichardJoneshttps://linux-kvm.org/index.php?title=VMchannel_Requirements&diff=2350VMchannel Requirements2009-06-26T08:54:55Z<p>RichardJones: + note libguestfs is used</p>
<hr />
<div>== Requirements ==<br />
<br />
* We want an interface between the guest and the host<br />
<br />
* The channel is to be used for simple communication, like sharing of the clipboard between the user desktop and the guest desktop<br />
** For relatively low rate of data transfer -- a few MB/s<br />
** Events to be delivered to the guest, like 'shutdown', 'reboot', 'logoff'<br />
** Queries to the guest, like 'which users are logged in'<br />
<br />
* Survive live migration<br />
<br />
* Support for multiple agents (consumers of the data) on the guest<br />
<br />
* Multiple channels could be opened at the same time<br />
<br />
* In multi-channels case, one blocked channel shouldn't block communication between others (or one channel shouldn't hog all the bandwidth)<br />
<br />
* Stable ABI (for future upgrades)<br />
<br />
* Channel addressing<br />
** An agent in the guest should be able to find the channel it's interested in<br />
<br />
* Dynamic channel creation<br />
<br />
* Security<br />
** No threats to the host<br />
** Unprivileged user should be able to use the channel<br />
<br />
* Should work out of the box, without any configuration necessary on the part of the guest<br />
<br />
* Notifications of channels being added / removed (hotplugging)<br />
<br />
* An API inside qemu to communicate with agents in the guest<br />
<br />
<br /><br />
== History ==<br />
A few reasons why the obvious solutions do not work:<br />
<br />
* via the fully emulated serial device.<br />
** performance (exit per byte)<br />
** scalability - only 4 serial ports per guest<br />
** accessed by root only in the guest<br />
<br />
* via TCP/IP network sockets<br />
** The guest may not have networking enabled<br />
** The guest firewall may block access to the host IPs<br />
** Windows can't bind sockets to specific ethernet interfaces<br />
<br />
* via user net <br>http://thread.gmane.org/gmane.comp.emulators.qemu/35780<br />
<br />
* via slirp <br>This implementation does exist upstream as "-net channel" http://www.nabble.com/-PATCH--specify-vmchannel-as-a-net-option-td21911523.html<br />
** Again, based on networking so same drawbacks mentioned above apply<br />
** Currently used by [http://libguestfs.org libguestfs]]</div>RichardJones