Re: Release plan for 0.12.0
Hello, 2009/9/30 Anthony Liguori aligu...@us.ibm.com: Hi, Now that 0.11.0 is behind us, it's time to start thinking about 0.12.0. o storage live migration Sorry for a bit off topic. But, my special NBD server can do this independently of VMM implementations. See http://bitbucket.org/hirofuchi/xnbd/wiki/Home if interested. Takahiro -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Raw vs. tap (was: Re: [Qemu-devel] Re: Release plan for 0.12.0)
On Wed, 2009-10-14 at 17:53 -0500, Anthony Liguori wrote: So at this point, I think it's a mistake to include raw socket support. If the goal is to improve networking usability such that it just works as a root user, let's incorporate a default network script that creates a bridge or something like that. There are better ways to achieve that goal. FWIW, I haven't really played with the raw backend yet, but my initial thought was also what exactly does this gain us apart from yet more confusion for users?. So, I tend to agree, but I'm not so hung up on the user confusion aspect - the users that I worry about confusing (e.g. virt-manager users) would never even know the backend exists, even if qemu did support it. The one hope I had for raw is that it might allow us to get closer to the NIC, get more details on the NIC tx queue and have more intelligent tx mitigation. This is probably better explored in the context of vhost-net, though. Wrt. to configuring bridges, libvirt comes with a good default setup - a bridge without any physical NICs connected, but NAT set up for access to the outside world. For bridging to a physical NIC, our plan continues to be that NetworkManager will eventually make this trivial for users, but that's still in progress. In the meantime, the config isn't all that complex: http://wiki.libvirt.org/page/Networking#Fedora.2FRHEL_Bridging Cheers, Mark. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: Release plan for 0.12.0
On Wed, Oct 14, 2009 at 02:10:00PM -0700, Sridhar Samudrala wrote: On Wed, 2009-10-14 at 17:50 +0200, Michael S. Tsirkin wrote: On Wed, Oct 14, 2009 at 04:19:17PM +0100, Jamie Lokier wrote: Michael S. Tsirkin wrote: On Wed, Oct 14, 2009 at 09:17:15AM -0500, Anthony Liguori wrote: Michael S. Tsirkin wrote: Looks like Or has abandoned it. I have an updated version which works with new APIs, etc. Let me post it and we'll go from there. I'm generally inclined to oppose the functionality as I don't think it offers any advantages over the existing backends. I patch it in and use it all the time. It's much easier to setup on a random machine than a bridged config. Having two things that do the same thing is just going to lead to user confusion. They do not do the same thing. With raw socket you can use windows update without a bridge in the host, with tap you can't. On the other hand, with raw socket, guest Windows can't access files on the host's Samba share can it? So it's not that useful even for Windows guests. I guess this depends on whether you use the same host for samba :) If the problem is tap is too hard to setup, we should try to simplify tap configuration. The problem is bridge is too hard to setup. Simplifying that is a good idea, but outside the scope of the qemu project. I venture it's important enough for qemu that it's worth working on that. Something that looks like the raw socket but behaves like an automatically instantiated bridge attached to the bound interface would be a useful interface. I agree, that would be good to have. Can't we bind the raw socket to the tap interface instead of the physical interface and allow the bridge config to work. We can, kind of (e.g. with veth) but what's the point then? Thanks Sridhar I don't have much time, but I'll help anybody who wants to do that. -- Jamie -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Raw vs. tap (was: Re: [Qemu-devel] Re: Release plan for 0.12.0)
On Wed, Oct 14, 2009 at 05:53:56PM -0500, Anthony Liguori wrote: I would be much more inclined to consider taking raw and improving the performance long term if guest-host networking worked. This appears to be a fundamental limitation though and I think it's something that will forever plague users if we include this feature. In fact, I think it's fixable with a raw socket bound to a macvlan. Would that be enough? -- MST -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Release plan for 0.12.0
On Thu, Oct 08, 2009 at 09:21:04AM -0500, Anthony Liguori wrote: Jens Osterkamp wrote: On Wednesday 30 September 2009, Anthony Liguori wrote: o VMState conversion -- I expect most of the pc target to be completed o qdev conversion -- I hope that we'll get most of the pc target completely converted to qdev o storage live migration o switch to SeaBIOS (need to finish porting features from Bochs) o switch to gPXE (need to resolve slirp tftp server issue) o KSM integration o in-kernel APIC support for KVM o guest SMP support for KVM o updates to the default pc machine type Please add to this list and I'll collect it all and post it somewhere. What about Or Gerlitz' raw backend driver ? I did not see it go in yet, or did I miss something ? The patch seems to have not been updated after the initial posting and the first feedback cycle. Looks like Or has abandoned it. I have an updated version which works with new APIs, etc. Let me post it and we'll go from there. I'm generally inclined to oppose the functionality as I don't think it offers any advantages over the existing backends. I patch it in and use it all the time. It's much easier to setup on a random machine than a bridged config. -- MST -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Release plan for 0.12.0
Michael S. Tsirkin wrote: Looks like Or has abandoned it. I have an updated version which works with new APIs, etc. Let me post it and we'll go from there. I'm generally inclined to oppose the functionality as I don't think it offers any advantages over the existing backends. I patch it in and use it all the time. It's much easier to setup on a random machine than a bridged config. Having two things that do the same thing is just going to lead to user confusion. If the problem is tap is too hard to setup, we should try to simplify tap configuration. Regards, Anthony Liguori -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Release plan for 0.12.0
On Wed, Oct 14, 2009 at 09:17:15AM -0500, Anthony Liguori wrote: Michael S. Tsirkin wrote: Looks like Or has abandoned it. I have an updated version which works with new APIs, etc. Let me post it and we'll go from there. I'm generally inclined to oppose the functionality as I don't think it offers any advantages over the existing backends. I patch it in and use it all the time. It's much easier to setup on a random machine than a bridged config. Having two things that do the same thing is just going to lead to user confusion. They do not do the same thing. With raw socket you can use windows update without a bridge in the host, with tap you can't. If the problem is tap is too hard to setup, we should try to simplify tap configuration. The problem is bridge is too hard to setup. Simplifying that is a good idea, but outside the scope of the qemu project. Regards, Anthony Liguori -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: Release plan for 0.12.0
Michael S. Tsirkin wrote: On Wed, Oct 14, 2009 at 09:17:15AM -0500, Anthony Liguori wrote: Michael S. Tsirkin wrote: Looks like Or has abandoned it. I have an updated version which works with new APIs, etc. Let me post it and we'll go from there. I'm generally inclined to oppose the functionality as I don't think it offers any advantages over the existing backends. I patch it in and use it all the time. It's much easier to setup on a random machine than a bridged config. Having two things that do the same thing is just going to lead to user confusion. They do not do the same thing. With raw socket you can use windows update without a bridge in the host, with tap you can't. On the other hand, with raw socket, guest Windows can't access files on the host's Samba share can it? So it's not that useful even for Windows guests. If the problem is tap is too hard to setup, we should try to simplify tap configuration. The problem is bridge is too hard to setup. Simplifying that is a good idea, but outside the scope of the qemu project. I venture it's important enough for qemu that it's worth working on that. Something that looks like the raw socket but behaves like an automatically instantiated bridge attached to the bound interface would be a useful interface. I don't have much time, but I'll help anybody who wants to do that. -- Jamie -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: Release plan for 0.12.0
On Wed, Oct 14, 2009 at 04:19:17PM +0100, Jamie Lokier wrote: Michael S. Tsirkin wrote: On Wed, Oct 14, 2009 at 09:17:15AM -0500, Anthony Liguori wrote: Michael S. Tsirkin wrote: Looks like Or has abandoned it. I have an updated version which works with new APIs, etc. Let me post it and we'll go from there. I'm generally inclined to oppose the functionality as I don't think it offers any advantages over the existing backends. I patch it in and use it all the time. It's much easier to setup on a random machine than a bridged config. Having two things that do the same thing is just going to lead to user confusion. They do not do the same thing. With raw socket you can use windows update without a bridge in the host, with tap you can't. On the other hand, with raw socket, guest Windows can't access files on the host's Samba share can it? So it's not that useful even for Windows guests. I guess this depends on whether you use the same host for samba :) If the problem is tap is too hard to setup, we should try to simplify tap configuration. The problem is bridge is too hard to setup. Simplifying that is a good idea, but outside the scope of the qemu project. I venture it's important enough for qemu that it's worth working on that. Something that looks like the raw socket but behaves like an automatically instantiated bridge attached to the bound interface would be a useful interface. I agree, that would be good to have. I don't have much time, but I'll help anybody who wants to do that. -- Jamie -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: Release plan for 0.12.0
On Wed, 2009-10-14 at 17:50 +0200, Michael S. Tsirkin wrote: On Wed, Oct 14, 2009 at 04:19:17PM +0100, Jamie Lokier wrote: Michael S. Tsirkin wrote: On Wed, Oct 14, 2009 at 09:17:15AM -0500, Anthony Liguori wrote: Michael S. Tsirkin wrote: Looks like Or has abandoned it. I have an updated version which works with new APIs, etc. Let me post it and we'll go from there. I'm generally inclined to oppose the functionality as I don't think it offers any advantages over the existing backends. I patch it in and use it all the time. It's much easier to setup on a random machine than a bridged config. Having two things that do the same thing is just going to lead to user confusion. They do not do the same thing. With raw socket you can use windows update without a bridge in the host, with tap you can't. On the other hand, with raw socket, guest Windows can't access files on the host's Samba share can it? So it's not that useful even for Windows guests. I guess this depends on whether you use the same host for samba :) If the problem is tap is too hard to setup, we should try to simplify tap configuration. The problem is bridge is too hard to setup. Simplifying that is a good idea, but outside the scope of the qemu project. I venture it's important enough for qemu that it's worth working on that. Something that looks like the raw socket but behaves like an automatically instantiated bridge attached to the bound interface would be a useful interface. I agree, that would be good to have. Can't we bind the raw socket to the tap interface instead of the physical interface and allow the bridge config to work. Thanks Sridhar I don't have much time, but I'll help anybody who wants to do that. -- Jamie -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Raw vs. tap (was: Re: [Qemu-devel] Re: Release plan for 0.12.0)
Sridhar Samudrala wrote: Can't we bind the raw socket to the tap interface instead of the physical interface and allow the bridge config to work. But why use the raw interface instead of tap directly. Let me summarize the discussion so far: Raw sockets Pros: o User specifies a network interface to bind to o External traffic Just Works, guest-to-guest traffic Just Works Cons: o Requires root (cannot chmod) o Guest-host traffic does not work o No support for GSO/checksum offload Some things that I'm not sure will work or not: o guest with a bridge (sending traffic with multiple mac addresses) o guest trying to enter promiscuous mode Tap Pros: o All types of networking works when configured o Supports non-root users via tunctl o Supports GSO/checksum offload Cons: o Requires configuring a bridge which can be difficult for some users Since I don't see any clear features in raw sockets that aren't present in tap, the argument really boils down to two things. First, we should take any feature in qemu and let the user decide whether or not they want to use it. I strongly feel this is a bad philosophy that will lead to increased user confusion and a poor user experience. Second, even though raw looses performance and requires root, since it requires no external configuration it is easier to use and therefore should be an option for users. I dislike this argument because it tricks a user into thinking that raw is a viable replacement for tap. It certainly isn't performance wise but most importantly, it isn't from a functional perspective. I would be much more inclined to consider taking raw and improving the performance long term if guest-host networking worked. This appears to be a fundamental limitation though and I think it's something that will forever plague users if we include this feature. So at this point, I think it's a mistake to include raw socket support. If the goal is to improve networking usability such that it just works as a root user, let's incorporate a default network script that creates a bridge or something like that. There are better ways to achieve that goal. Regards, Anthony Liguori -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Release plan for 0.12.0
Amit Shah wrote: On (Tue) Sep 29 2009 [18:54:53], Anthony Liguori wrote: o multiport virtio-console support Assuming we can get the kernel drivers straightened out, I think it's certainly reasonable for 0.12. -- Regards, Anthony Liguori -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Release plan for 0.12.0
On (Wed) Sep 30 2009 [08:04:17], Anthony Liguori wrote: Amit Shah wrote: On (Tue) Sep 29 2009 [18:54:53], Anthony Liguori wrote: o multiport virtio-console support Assuming we can get the kernel drivers straightened out, I think it's certainly reasonable for 0.12. The kernel drivers are in fine shape. Amit -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Release plan for 0.12.0
Amit Shah wrote: On (Wed) Sep 30 2009 [08:04:17], Anthony Liguori wrote: Amit Shah wrote: On (Tue) Sep 29 2009 [18:54:53], Anthony Liguori wrote: o multiport virtio-console support Assuming we can get the kernel drivers straightened out, I think it's certainly reasonable for 0.12. The kernel drivers are in fine shape. I meant on track for including into the appropriate tree. Looking for an Ack/Nack from Rusty. That's been the general policy for all virtio changes btw. Nothing specific to virtio-console. Amit -- Regards, Anthony Liguori -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Release plan for 0.12.0
On (Wed) Sep 30 2009 [09:47:22], Anthony Liguori wrote: Amit Shah wrote: On (Wed) Sep 30 2009 [08:04:17], Anthony Liguori wrote: Amit Shah wrote: On (Tue) Sep 29 2009 [18:54:53], Anthony Liguori wrote: o multiport virtio-console support Assuming we can get the kernel drivers straightened out, I think it's certainly reasonable for 0.12. The kernel drivers are in fine shape. I meant on track for including into the appropriate tree. Looking for an Ack/Nack from Rusty. That's been the general policy for all virtio changes btw. Nothing specific to virtio-console. That's fine. Amit -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Release plan for 0.12.0
Anthony Liguori aligu...@us.ibm.com wrote: Luiz Capitulino wrote: On Tue, 29 Sep 2009 18:54:53 -0500 Anthony Liguori aligu...@us.ibm.com wrote: I think aiming for early to mid-December would give us roughly a 3 month cycle and would align well with some of the Linux distribution cycles. I'd like to limit things to a single -rc that lasted only for about a week. This is enough time to fix most of the obvious issues I think. How do you plan to do it? I mean, are you going to create a separate branch or make master the -rc? Creating a separate branch (which is what we do today, iiuc) makes it get less attention, freezing master for a certain period is the best way to stabilize. Is this what you had in mind? What do people think? One reason I branch is because some people care a bit less about releases so it makes the process non-disruptive to them. If the other maintainers agreed though, I would certainly like to have the master branch essentially frozen for the week before the release. I am not a maintainer, but I still think that it is a good idea :) Later, Juan. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Release plan for 0.12.0
On Tue, Sep 29, 2009 at 6:54 PM, Anthony Liguori aligu...@us.ibm.com wrote: Now that 0.11.0 is behind us, it's time to start thinking about 0.12.0. I'd like to do a few things different this time around. I don't think the -rc process went very well as I don't think we got more testing out of it. I'd like to shorten the timeline for 0.12.0 a good bit. The 0.10 stable tree got pretty difficult to maintain toward the end of the cycle. We also had a pretty huge amount of change between 0.10 and 0.11 so I think a shorter cycle is warranted. I think aiming for early to mid-December would give us roughly a 3 month cycle and would align well with some of the Linux distribution cycles. I'd like to limit things to a single -rc that lasted only for about a week. This is enough time to fix most of the obvious issues I think. As a downstream packager of qemu-kvm, I thought I'd mention that the next Ubuntu cycle is now public: * https://wiki.ubuntu.com/LucidReleaseSchedule The key date here is Feature Freeze, which is February 25, 2010. That's the point by which we'd need to have a new qemu-kvm (which of course is downstream of qemu) package in Ubuntu for the LTS 10.04 release in April 2010. I'll gladly track the release candidate(s) in the Lucid development tree, and hopefully pull 0.12 as soon as its available. And we also provide daily snapshots of qemu builds at: * https://edge.launchpad.net/~ubuntu-virt/+archive/virt-daily-upstream :-Dustin -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Release plan for 0.12.0
Dustin Kirkland wrote: On Tue, Sep 29, 2009 at 6:54 PM, Anthony Liguori aligu...@us.ibm.com wrote: Now that 0.11.0 is behind us, it's time to start thinking about 0.12.0. I'd like to do a few things different this time around. I don't think the -rc process went very well as I don't think we got more testing out of it. I'd like to shorten the timeline for 0.12.0 a good bit. The 0.10 stable tree got pretty difficult to maintain toward the end of the cycle. We also had a pretty huge amount of change between 0.10 and 0.11 so I think a shorter cycle is warranted. I think aiming for early to mid-December would give us roughly a 3 month cycle and would align well with some of the Linux distribution cycles. I'd like to limit things to a single -rc that lasted only for about a week. This is enough time to fix most of the obvious issues I think. As a downstream packager of qemu-kvm, I thought I'd mention that the next Ubuntu cycle is now public: * https://wiki.ubuntu.com/LucidReleaseSchedule The key date here is Feature Freeze, which is February 25, 2010. That's the point by which we'd need to have a new qemu-kvm (which of course is downstream of qemu) package in Ubuntu for the LTS 10.04 release in April 2010. If we did a December release, then the 0.13 release would probably be in the April time frame. Not really ideal for Lucid so I'd recommend that you ship 0.12. The good news would be that 0.12 should be very stable by Feb 25th and since Lucid is an LTS, that's probably a Good Thing. -- Regards, Anthony Liguori -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Release plan for 0.12.0
On (Tue) Sep 29 2009 [18:54:53], Anthony Liguori wrote: Hi, Now that 0.11.0 is behind us, it's time to start thinking about 0.12.0. I'd like to do a few things different this time around. I don't think the -rc process went very well as I don't think we got more testing out of it. I'd like to shorten the timeline for 0.12.0 a good bit. The 0.10 stable tree got pretty difficult to maintain toward the end of the cycle. We also had a pretty huge amount of change between 0.10 and 0.11 so I think a shorter cycle is warranted. I think aiming for early to mid-December would give us roughly a 3 month cycle and would align well with some of the Linux distribution cycles. I'd like to limit things to a single -rc that lasted only for about a week. This is enough time to fix most of the obvious issues I think. I'd also like to try to enumerate some features for this release. Here's a short list of things I expect to see for this release (target-i386 centric). Please add or comment on items that you'd either like to see in the release or are planning on working on. o VMState conversion -- I expect most of the pc target to be completed o qdev conversion -- I hope that we'll get most of the pc target completely converted to qdev o storage live migration o switch to SeaBIOS (need to finish porting features from Bochs) o switch to gPXE (need to resolve slirp tftp server issue) o KSM integration o in-kernel APIC support for KVM o guest SMP support for KVM o updates to the default pc machine type o multiport virtio-console support Please add to this list and I'll collect it all and post it somewhere. Thanks, Amit -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
