KVM call agenda for June 21

KVM call agenda for June 21

[Juan Quintela]

Please send in any agenda items you are interested in covering.

thanks,
-juan

[Qemu-devel] KVM call agenda for June 21

[Juan Quintela]

Please send in any agenda items you are interested in covering.

thanks,
-juan

Re: KVM call agenda for June 21

[Avi Kivity]

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

Re: [Qemu-devel] KVM call agenda for June 21

[Avi Kivity]

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

Re: [Qemu-devel] KVM call agenda for June 21

[Anthony Liguori]

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

Re: [Qemu-devel] KVM call agenda for June 21

[Anthony Liguori]

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

Re: [Qemu-devel] KVM call agenda for June 21

[Anthony Liguori]

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
>
>

Re: [Qemu-devel] KVM call agenda for June 21

[Anthony Liguori]

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
>
>

Re: [Qemu-devel] KVM call agenda for June 21

[Avi Kivity]

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 -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.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] KVM call agenda for June 21

[Avi Kivity]

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 -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.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] KVM call agenda for June 21

[Markus Armbruster]

Avi Kivity <avi@redhat.com> 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 -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.

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.

Re: [Qemu-devel] KVM call agenda for June 21

[Markus Armbruster]

Avi Kivity <avi@redhat.com> 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 -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.

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.

Re: [Qemu-devel] KVM call agenda for June 21

[Avi Kivity]

On 06/21/2011 05:27 PM, Markus Armbruster wrote:
> >
> >  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.
>
> 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

Re: [Qemu-devel] KVM call agenda for June 21

[Avi Kivity]

On 06/21/2011 05:27 PM, Markus Armbruster wrote:
> >
> >  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.
>
> 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

Re: [Qemu-devel] KVM call agenda for June 21

[Frédéric Grelot]

> > 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

Re: [Qemu-devel] KVM call agenda for June 21

[Anthony Liguori]

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 -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.

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.
>

Re: [Qemu-devel] KVM call agenda for June 21

[Anthony Liguori]

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 -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.

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.
>

Re: [Qemu-devel] KVM call agenda for June 21

[Lucas Meneghel Rodrigues]

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.
> 

Re: [Qemu-devel] KVM call agenda for June 21

[Lucas Meneghel Rodrigues]

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.
>