Anthony Liguori <anthony@xxxxxxxxxxxxx> writes: > On 04/03/2011 05:11 AM, Avi Kivity wrote: >> On 04/03/2011 12:59 PM, Pekka Enberg wrote: >>> Hi Avi, >>> >>> On Sun, Apr 3, 2011 at 11:23 AM, Avi Kivity<avi@xxxxxxxxxx> wrote: >>> >> Note that this is a development prototype for the time being: >>> there's no >>> >> networking support and no graphics support, amongst other missing >>> >> essentials. >>> > >>> > Mind posting a roadmap? I would put smp support near the top. >>> This sort of >>> > thing has to be designed in, otherwise you wind up with a big >>> lock like >>> > qemu. >>> >>> What are the pain points with qemu at the moment? >> >> It's an ugly gooball. > > Because it solves a lot of very difficult problems. And the solutions emerged / evolved over a long time. Meanwhile, goals shifted. It wasn't designed as user space for KVM, it got shoehorned into that role (successfully). It has some solutions it should have left to other tools. For instance, it shouldn't be in the network configuration business. > You could drop all of the TCG support and it'd still be an ugly gooball. > > Supporting lots of different emulated hardware devices, live > migration, tons of different types of networking and image formats, > etc., all adds up over time. It does. Still, a fresh start could lead to a less ugly gooball. >>> SMP, networking, and simpler guest to host communication from shell >>> are most interesting missing features for me. >> >> If it is to be more than a toy, then Windows (really generic guest) >> support, manageability, live migration, hotplug, etc. are all >> crucial. > > I concur that SMP is probably one of those features you need to start > with if you're designing something from scratch. Certainly. Another one that doesn't like retrofitting is security. -- 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
