Re: [Qemu-devel] KVM call agenda for June 21
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 -vvv, 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call agenda for June 21
On 06/21/2011 08:56 AM, Avi Kivity wrote: On 06/21/2011 04:50 PM, Anthony Liguori wrote: We can have a script that runs lspci -vvv, 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. I think a simple tool that dumped as much info as possible in a diff'able format would be useful not only within guests but also in bare metal. Regards, Anthony Liguori 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call agenda for June 21
> > f13 is ancient, no? > > Yes, a year old. > Furthermore, the following mail was sent to the Fedora announce mailing list just one week ago : This is a reminder email about the end of life process for Fedora 13. Fedora 13 will reach end of life on 2011-06-24, and no further updates will be pushed out after that time. Additionally, with the recent release of Fedora 15, no new packages will be added to the Fedora 13 collection. Please see http://fedoraproject.org/wiki/DistributionUpgrades for more information on upgrading from Fedora 13 to a newer release. kevin -- 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] KVM call agenda for June 21
On 06/21/2011 05:27 PM, Markus Armbruster wrote: > > We can have a script that runs lspci -vvv, 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. Suggest to compare info qtree as well. Good idea. Also the memory map, when the memory API is there. -- error compiling committee.c: too many arguments to function -- 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] KVM call agenda for June 21
Avi Kivity writes: > 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? > > We can have a script that runs lspci -vvv, 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. Suggest to compare info qtree as well. > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call agenda for June 21
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? We can have a script that runs lspci -vvv, 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. -- error compiling committee.c: too many arguments to function -- 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] KVM call agenda for June 21
On 06/20/2011 02:42 AM, Juan Quintela wrote: Please send in any agenda items you are interested in covering. State of image streaming/block copy. Regards, Anthony Liguori thanks, -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: [Qemu-devel] KVM call agenda for June 21
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? I'm not sure what this particular issue is, but is this doing -M pc-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: KVM call agenda for June 21
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? -- error compiling committee.c: too many arguments to function -- 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
KVM call agenda for June 21
Please send in any agenda items you are interested in covering. thanks, -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
