[Qemu-devel] KVM call minutes for Apr 6

[Chris Wright]

Management stack again
- qemud?
- external mgmt stack, qemu/kvm devs less inclined to care
  - "Oh, you're using virsh, try #virt on OFTC"
- standard libvirt issues
  - concern about speed of adopting kvm features
  - complicated, XML hard to understand
  - being slowed by hv agnositc
  - ...
  - but...clearly have done a lot of work and widely used/deployed/etc...
- libvirt is still useful, so need to play well w/ libvirt
- qemud
  - qemu registers
  - have enumeration
  - have access to all qemu features (QMP based)
  - runs privileged, can deal w/ bridge, tap setup
  - really good UI magically appears </sarcasm>
  - regressions (we'd lose these w/ qemud):
    - sVirt
    - networking
    - storage pools, etc
    - device assignment
    - hotplug
    - large pages
    - cgroups
    - stable mgmt ABI
  - what's needed global/privileged?
    - guest enumeration
    - network setup
    - device hotplug
  - need good single VM UI
    - but...as soon as you want 2 VMs, or 2 hosts...
    - no need to reinvent the wheel
- qemu project push features up towards mgmt stack, but doesn't make
  those features exist in mgmt stack
- automated interface creation (remove barrier to adding libvirt features)
- QtEmu as example of nice interface that suffered because programming to qemu 
cli is too hard
- libvirt has made a lot of effort, nobody is discouting that, what's un
- strong agreement is that libvirt is needed long term
- we should focus on making qemu easy to manage not on writing mgmt tools
  - qmp + libvirt
  - define requirements for layering
    - needs for global scope and privilege requirements