From: Chris Wright <chrisw@redhat.com>
To: kvm@vger.kernel.org
Cc: qemu-devel@nongnu.org
Subject: [Qemu-devel] KVM call minutes for Apr 6
Date: Tue, 6 Apr 2010 08:13:58 -0700 [thread overview]
Message-ID: <20100406151358.GC7088@x200.localdomain> (raw)
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
reply other threads:[~2010-04-06 15:25 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100406151358.GC7088@x200.localdomain \
--to=chrisw@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).