Re: [openstack-dev] [Summit] Coordination between OpenStack & lower layer virt stack (libvirt, QEMU/KVM)
On Tue, Oct 21, 2014 at 12:07:41PM +0100, Daniel P. Berrange wrote: > On Tue, Oct 21, 2014 at 12:58:48PM +0200, Kashyap Chamarthy wrote: > > I was discussing $subject on #openstack-nova, Nikola Dipanov suggested > > it's worthwhile to bring this up on the list. > > > > I was looking at > > > > http://kilodesignsummit.sched.org/ > > > > and noticed there's no specific session (correct me if I'm wrong) that's > > targeted at coordination between OpenStack <-> libvirt <-> QEMU/KVM. > > At previous summits, Nova has given each virt driver a dedicated session > in its track. Those sessions have pretty much just been a walkthrough of > the various features each virt team was planning. > > We always have far more topics to discuss than we have time available, > and for this summit we want to change direction to maximise the value > extracted from face-to-face meetings. > > As such any session which is just duplicating stuff that could easily be > dealt with over email or irc is being cut, to make room for topics where > we really need to have the f2f discussions. So the virt driver general > sessions from previous summits are not likely to be on the schedule this > time around. Optimized for efficiency, good to know, thanks. -- /kashyap ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Summit] Coordination between OpenStack & lower layer virt stack (libvirt, QEMU/KVM)
On Oct 21, 2014 4:10 AM, "Daniel P. Berrange" wrote: > > On Tue, Oct 21, 2014 at 12:58:48PM +0200, Kashyap Chamarthy wrote: > > I was discussing $subject on #openstack-nova, Nikola Dipanov suggested Sounds like a great idea. > > it's worthwhile to bring this up on the list. > > > > I was looking at > > > > http://kilodesignsummit.sched.org/ > > > > and noticed there's no specific session (correct me if I'm wrong) that's > > targeted at coordination between OpenStack <-> libvirt <-> QEMU/KVM. > > At previous summits, Nova has given each virt driver a dedicated session > in its track. Those sessions have pretty much just been a walkthrough of > the various features each virt team was planning. > > We always have far more topics to discuss than we have time available, > and for this summit we want to change direction to maximise the value > extracted from face-to-face meetings. > > As such any session which is just duplicating stuff that could easily be > dealt with over email or irc is being cut, to make room for topics where > we really need to have the f2f discussions. So the virt driver general > sessions from previous summits are not likely to be on the schedule this > time around. Agreed, this mailing list is a great place to kick off the closer libvirt QEMU/KVM discussions. > > Regards, > Daniel > -- > |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| > |: http://libvirt.org -o- http://virt-manager.org :| > |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| > |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Summit] Coordination between OpenStack & lower layer virt stack (libvirt, QEMU/KVM)
On Tue, Oct 21, 2014 at 11:52:26AM +, Tim Bell wrote: > > It would also be interesting if the features of KVM could be made > available through OpenStack around the same time.. virtio-blk data > plane would be an example where we can't work out how to exploit it > out of the box under OpenStack. The rate of change in QEMU (KVM) is pretty enourmous and many features are not entirely relevant to OpenStack needs. The hard bit though is actually figuring out how to best expose new features via OpenStack. With the cloud paradigm we explicitly want to avoid the end user (the VM instance / image owners) from knowing anything about the compute host hardware. The result is that they will typically not have sufficient knowledge of the system to be able to know whether some new QEMU flag or feature is appropriate to use. So we have to try to design things so that Nova either makes an self-driven policy decision, or define a way for the user or cloud admin to provide hints/preferences via image metadata and/or flavour extra specs, then use this hints to influence the policy decision indirectly. The NUMA work is a good example of this. QEMU provides a feature to let the app define mapping between guest NUMA nodes and host NUMA nodes. The cloud user has no knowledge of the host NUMA topology, so it is impossible for them to take the simply approach to using QEMU's NUMA feature. Instead we have to provide a way for the user or admin to define characteristics of the guest NUMA topology, and then have teh Nova schedular figure out how to map that into the host NUMA topology. This is a pretty major bit of work over & above what QEMU provides, so there's inevitably going to a delay between a feature appearing in QEMU and it being available in OpenStack. On your specific point about the virtio blk dataplane option. Libvirt has explicitly not provided any supported way to turn that feature on in the guest XML config, on advice from the QEMU maintainers. This is because the dataplane option is considered a short term hack/experiment to prove a general conceptual idea. Libvirt does allow for QEMU command line option passthrough, but that "taints" a VM instance as being in an unsupported state. The reason for this is that the dataplane option will be removed from QEMU in favour of a different supportable long term solution, so neither libvirt/QEMU maintainers wish it to be used by production facing apps right now. The long term replacement for dataplane is a new "I/O threads" option that was recently wired up into QEMU and libvirt. It would be appropriate to look at how to support this I/O threads option in OpenStack now, so please feel free to file a bug requesting it. If you have specific info about usage/deployment scenarios in which dataplane has proved a benefit (or equally a negative), then would be useful to have in the bug too, so we can figure out how to best support it. Ideally we'd not hve to expose this to end users and Nova would just "do the right thing" to maximise the performance win. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Summit] Coordination between OpenStack & lower layer virt stack (libvirt, QEMU/KVM)
> -Original Message- > From: Daniel P. Berrange [mailto:berra...@redhat.com] > Sent: 21 October 2014 13:08 > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [Summit] Coordination between OpenStack & > lower layer virt stack (libvirt, QEMU/KVM) > > On Tue, Oct 21, 2014 at 12:58:48PM +0200, Kashyap Chamarthy wrote: > > I was discussing $subject on #openstack-nova, Nikola Dipanov suggested > > it's worthwhile to bring this up on the list. > > > > I was looking at > > > > http://kilodesignsummit.sched.org/ > > > > and noticed there's no specific session (correct me if I'm wrong) > > that's targeted at coordination between OpenStack <-> libvirt <-> QEMU/KVM. > > At previous summits, Nova has given each virt driver a dedicated session in > its > track. Those sessions have pretty much just been a walkthrough of the various > features each virt team was planning. > > We always have far more topics to discuss than we have time available, and for > this summit we want to change direction to maximise the value extracted from > face-to-face meetings. > > As such any session which is just duplicating stuff that could easily be > dealt with > over email or irc is being cut, to make room for topics where we really need > to > have the f2f discussions. So the virt driver general sessions from previous > summits are not likely to be on the schedule this time around. > > Regards, > Daniel > -- It would also be interesting if the features of KVM could be made available through OpenStack around the same time.. virtio-blk data plane would be an example where we can't work out how to exploit it out of the box under OpenStack. > |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| > |: http://libvirt.org -o- http://virt-manager.org :| > |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| > |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Summit] Coordination between OpenStack & lower layer virt stack (libvirt, QEMU/KVM)
On Tue, Oct 21, 2014 at 12:58:48PM +0200, Kashyap Chamarthy wrote: > I was discussing $subject on #openstack-nova, Nikola Dipanov suggested > it's worthwhile to bring this up on the list. > > I was looking at > > http://kilodesignsummit.sched.org/ > > and noticed there's no specific session (correct me if I'm wrong) that's > targeted at coordination between OpenStack <-> libvirt <-> QEMU/KVM. At previous summits, Nova has given each virt driver a dedicated session in its track. Those sessions have pretty much just been a walkthrough of the various features each virt team was planning. We always have far more topics to discuss than we have time available, and for this summit we want to change direction to maximise the value extracted from face-to-face meetings. As such any session which is just duplicating stuff that could easily be dealt with over email or irc is being cut, to make room for topics where we really need to have the f2f discussions. So the virt driver general sessions from previous summits are not likely to be on the schedule this time around. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Summit] Coordination between OpenStack & lower layer virt stack (libvirt, QEMU/KVM)
I was discussing $subject on #openstack-nova, Nikola Dipanov suggested it's worthwhile to bring this up on the list. I was looking at http://kilodesignsummit.sched.org/ and noticed there's no specific session (correct me if I'm wrong) that's targeted at coordination between OpenStack <-> libvirt <-> QEMU/KVM. Nova, as one of the high-profile customers (to borrow Nikola's phrasing) of libvirt/QEMU/KVM projects, would benefit from better coordination and to keep track of what's happening in the lower layers of open source virtualization stack. Also, libvirt is the virtualization driver that upstream OpenStack infrastructure relies on for Gating. (A relevant thread[1] from openstack-dev list). I have not attended an OpenStack design summit before, but if I have to guess: this topic falls under libvirt driver/cross-project sessions or some kind of unconference/BoF that's done on the fly while co-ordinating notes in an etherpad. Correct? On a related note, I just returned from KVM Forum/LinuxCon Europe. More than a couple of developers expressed interest in closer collaboration with OpenStack layer. For those not familiar, KVM Forum is a developer event that mainly focuses on KVM, QEMU, libvirt projects and their integration work. My report of the conference in plain text here[2]. [1] http://lists.openstack.org/pipermail/openstack-dev/2014-July/040421.html "fair standards for all hypervisor drivers" [2] https://kashyapc.fedorapeople.org/virt/kvmforum-linuxcon-eu-2014-trip-report.txt -- /kashyap ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
