On Tue, 2011-06-21 at 16:56 +0300, Avi Kivity wrote: > On 06/21/2011 04:50 PM, Anthony Liguori wrote: > > On 06/21/2011 06:28 AM, Avi Kivity wrote: > >> On 06/20/2011 10:42 AM, Juan Quintela wrote: > >>> Please send in any agenda items you are interested in covering. > >>> > >> > >> > >> https://bugzilla.redhat.com/show_bug.cgi?id=689672 - Guests do not start > >> after upgrading qemu to 0.13 > >> > >> Seems like our backward compatibility plan isn't working. How do we > >> address it? How do we test it? > > > > f13 is ancient, no? > > Yes, a year old. > > Furthermore, Justin tells me it carries a lot downstream patches. > > > > > I'm not sure what this particular issue is, but is this doing -M pc-0.12? > > > > It has its own machine type. So this report may not indicate any > problem with upstream. > > Still, I feel we have a potential problem here. We identify > guest-visible attributes just by review; we're sure to miss something > here and there. Unlike ordinary bugs, compatibility problems only show > up later and are much harder to fix. > > Second, we don't do any tests in this area that I'm aware of. Lucas, > what would it take (thanks, you're most kind) to test multiple qemus in > a single run? I have thought about it, people have asked about this in the past. Here's my implementation idea: 1) Turn qemu to be a configurable option very much like images, cdroms, nics, etc, such as: qemu_binary_upstream = '/path/1' qemu_binary_rhel6 = '/path/2' ... qemu_binary_n = '/path/n' So people in need of testing multiple qemus can set them and have them all track down by autotest 2) Add support in the build test for building multiple user spaces 3) Make qemu_binary to be a VM param. This way if we need to change the userspace a given VM uses, just update the params and start the vm again. Noticing different params, the VM will be restarted using the alternate userspace. I will start to work on this right now. It'll probably take a couple of weeks for a first patchset, but it's high time we get this implemented, since there are several uses for it. > We can have a script that runs lspci -vvvvvvvvvvvvvvvvvvv, x86info, and > other interesting stuff and compare the results, and also system tests > that boot a guest on multiple qemus (with the same -M and different -M) > and see if things work. > > We can probably continue on email, I don't see a real need for a call > for this topic. > -- 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
