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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
