VMchannel Requirements: Difference between revisions

From KVM
(Add a use-cases section)
No edit summary
Line 61: Line 61:
* Online usage
* Online usage
** Locking desktop session when vnc session is closed
** Locking desktop session when vnc session is closed
* Cluster I/O Fencing aka STONITH
** Current models require networking between guest/host
*** [http://git.fedorahosted.org/git/?p=fence-agents.git;a=tree;f=fence/agents/virsh fence_virsh], [http://hg.linux-ha.org/dev/file/64f4592952ea/lib/plugins/stonith/external/xen0 xen0] -> ssh to defined host and to perform fencing; no migration tracking; requires ssh key distribution to work.
*** [http://git.fedorahosted.org/git/?p=fence-agents.git;a=tree;f=fence/agents/xvm 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

Revision as of 11:04, 15 July 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


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