3:09 a.m.
So as discussed earlier this week, I have tagged the release candidate 1
of libvirt-1.0.5 in git and pushed the tarball and associated rpms to
the FTP at:
ftp://libvirt.org/libvirt/
We may still push some of the patches needed by Laine to finish the
serie started yesterday, but at this point we should focuse our commits
on bug fixes and documentation. I will make an rc2 at the beginning of
next week and hopefully can push the final version on May 2nd.
This passed my own small usage tests, but please give it a try.
As usual some feedback on portability issues are really welcome too :-)
thanks !
Daniel
--
Daniel Veillard | Open Source and Standards, Red Hat
veillard(a)redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | virtualization library http://libvirt.org/
3:33 a.m.
On Fri, Apr 26, 2013 at 10:09 AM, Daniel Veillard <veillard(a)redhat.com>wrote:
This passed my own small usage tests, but please give it a try.
As usual some feedback on portability issues are really welcome too :-)
It compiles on OSX 10.8
make check:
1 of 202 tests failed
(10 tests were not run)
Please report to libvir-list(a)redhat.com
=======================================
make[4]: *** [check-TESTS] Error 1
make[3]: *** [check-am] Error 2
make[2]: *** [check-recursive] Error 1
make[1]: *** [check] Error 2
make: *** [check-recursive] Error 1
This is a gnulib test:
[ruben@odin ~/src/libvirt-1.0.5/gnulib/tests]$ ./test-getgroups
test-getgroups.c:58: assertion failed
Abort trap: 6
Kind regards,
Ruben
5:52 a.m.
On Fri, Apr 26, 2013 at 10:33:47AM +0200, Ruben Kerkhof wrote:
On Fri, Apr 26, 2013 at 10:09 AM, Daniel Veillard
<veillard(a)redhat.com>wrote:
> This passed my own small usage tests, but please give it a try.
> As usual some feedback on portability issues are really welcome too :-)
>
It compiles on OSX 10.8
Good :-)
make check:
1 of 202 tests failed
(10 tests were not run)
Please report to libvir-list(a)redhat.com
=======================================
make[4]: *** [check-TESTS] Error 1
make[3]: *** [check-am] Error 2
make[2]: *** [check-recursive] Error 1
make[1]: *** [check] Error 2
make: *** [check-recursive] Error 1
This is a gnulib test:
[ruben@odin ~/src/libvirt-1.0.5/gnulib/tests]$ ./test-getgroups
test-getgroups.c:58: assertion failed
Abort trap: 6
Okay, maybe Eric can guess what's going on
thanks !
Daniel
--
Daniel Veillard | Open Source and Standards, Red Hat
veillard(a)redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | virtualization library http://libvirt.org/
6:03 a.m.
New subject: [libvirt] getgroups failure [was: Entering freeze for libvirt-1.0.5]
[adding bug-gnulib]
On 04/26/2013 02:33 AM, Ruben Kerkhof wrote:
On Fri, Apr 26, 2013 at 10:09 AM, Daniel Veillard
<veillard(a)redhat.com>wrote:
> This passed my own small usage tests, but please give it a try.
> As usual some feedback on portability issues are really welcome too :-)
>
It compiles on OSX 10.8
make check:
1 of 202 tests failed
(10 tests were not run)
Please report to libvir-list(a)redhat.com
That sounds like the tail of the gnulib section of tests, but you
snipped too much output. We need to know WHICH test is failing, and
whether it is a known upstream gnulib bug; if it is fixed quickly in
gnulib, we can pull in a newer gnulib before the rc2 release of libvirt.
This is a gnulib test:
[ruben@odin ~/src/libvirt-1.0.5/gnulib/tests]$ ./test-getgroups
test-getgroups.c:58: assertion failed
Abort trap: 6
Oh, you did narrow in on the test. I haven't seen any recent bug-gnulib
traffic that mentions this test failing on OSX, nor do I have easy
access to a machine to verify and clean it up myself. Can you help
debug the issue? One thing to look at is whether gnulib is declaring
the system getgroups() as working or not - what does 'grep GETGROUPS
config.status' report for you? Also, it could just be an overly-strict
test.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
8:09 a.m.
New subject: [libvirt] getgroups failure [was: Entering freeze for libvirt-1.0.5]
Hi Eric,
On Fri, Apr 26, 2013 at 1:03 PM, Eric Blake <eblake(a)redhat.com> wrote:
This is free software: you are free to change and redistribute
it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin12.3.0".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from
/Users/ruben/src/libvirt-1.0.5/gnulib/tests/test-getgroups...done.
(gdb) b main
Breakpoint 1 at 0x100001327: file test-getgroups.c, line 39.
(gdb) r
Starting program:
/Users/ruben/src/libvirt-1.0.5/gnulib/tests/test-getgroups
Breakpoint 1, main (argc=1, argv=0x7fff5fbffa00) at test-getgroups.c:39
39 errno = 0;
(gdb) n
40 result = getgroups (0, NULL);
(gdb)
41 if (result == -1 && errno == ENOSYS)
(gdb) p result
$1 = 12
(gdb) n
46 ASSERT (0 <= result);
(gdb)
47 ASSERT (result + 1 < SIZE_MAX / sizeof *groups);
(gdb)
48 groups = malloc ((result + 1) * sizeof *groups);
(gdb)
49 ASSERT (groups);
(gdb)
50 groups[result] = -1;
(gdb)
55 if (1 < result)
(gdb)
57 errno = 0;
(gdb)
58 ASSERT (getgroups (result - 1, groups) == -1);
(gdb) s
rpl_getgroups (n=11, group=0x100107cb0) at getgroups.c:54
54 rpl_getgroups (int n, gid_t *group)
(gdb)
60 if (n < 0)
(gdb)
70 return getgroups (n, (GETGROUPS_T *) group);
(gdb)
test-getgroups.c:58: assertion failed
rpl_fflush (stream=0x7fff7cf03bc0) at fflush.c:124
124 rpl_fflush (FILE *stream)
Can you guide me on what to do next?
Thanks,
Ruben
Oh, you did narrow in on the test. I haven't seen any recent
bug-gnulib
traffic that mentions this test failing on OSX, nor do I have easy
access to a machine to verify and clean it up myself. Can you help
debug the issue? One thing to look at is whether gnulib is declaring
the system getgroups() as working or not - what does 'grep GETGROUPS
config.status' report for you? Also, it could just be an overly-strict
test.
[ruben@odin ~/src/libvirt-1.0.5]$ grep GETGROUPS config.status
S["REPLACE_GETGROUPS"]="1"
S["HAVE_GETGROUPS"]="1"
S["GNULIB_GETGROUPS"]="IN_LIBVIRT_GNULIB_TESTS"
D["GETGROUPS_T"]=" gid_t"
D["HAVE_GETGROUPS"]=" 1"
D["GNULIB_TEST_GETGROUPS"]=" 1"
Here's a quick gdb session:
[ruben@odin ~/src/libvirt-1.0.5/gnulib/tests]$ gdb ./test-getgroups
GNU gdb (GDB) 7.5.1
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
9:02 a.m.
On 04/26/2013 10:09 AM, Daniel Veillard wrote:
So as discussed earlier this week, I have tagged the release
candidate 1
of libvirt-1.0.5 in git and pushed the tarball and associated rpms to
the FTP at:
ftp://libvirt.org/libvirt/
We may still push some of the patches needed by Laine to finish the
serie started yesterday, but at this point we should focuse our commits
on bug fixes and documentation. I will make an rc2 at the beginning of
next week and hopefully can push the final version on May 2nd.
This passed my own small usage tests, but please give it a try.
As usual some feedback on portability issues are really welcome too :-)
Unfortunately I have to report that commit b33eb0dc seems to have
broken s390.
I cannot start guests anymore, error message is
error: XML error: No PCI buses available
Will look into it, but any help is welcome.
thanks !
Daniel
--
Mit freundlichen Grüßen/Kind Regards
Viktor Mihajlovski
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Köderitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
9:11 a.m.
On Fri, Apr 26, 2013 at 04:02:51PM +0200, Viktor Mihajlovski wrote:
On 04/26/2013 10:09 AM, Daniel Veillard wrote:
> So as discussed earlier this week, I have tagged the release candidate 1
>of libvirt-1.0.5 in git and pushed the tarball and associated rpms to
>the FTP at:
> ftp://libvirt.org/libvirt/
>
>We may still push some of the patches needed by Laine to finish the
>serie started yesterday, but at this point we should focuse our commits
>on bug fixes and documentation. I will make an rc2 at the beginning of
>next week and hopefully can push the final version on May 2nd.
>
> This passed my own small usage tests, but please give it a try.
>As usual some feedback on portability issues are really welcome too :-)
Unfortunately I have to report that commit b33eb0dc seems to have
broken s390.
I cannot start guests anymore, error message is
error: XML error: No PCI buses available
Will look into it, but any help is welcome.
Hum, the patch seems to add a big switch about def->os.arch
in qemuDomainDefPostParse()
+ case VIR_ARCH_ALPHA:
+ case VIR_ARCH_PPC:
+ case VIR_ARCH_PPC64:
+ case VIR_ARCH_PPCEMB:
+ case VIR_ARCH_SH4:
+ case VIR_ARCH_SH4EB:
+ addPCIRoot = true;
+ break;
+ default:
+ break;
I smell a case for s390 is needed somehow.
Daniel
--
Daniel Veillard | Open Source and Standards, Red Hat
veillard(a)redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | virtualization library http://libvirt.org/
9:35 a.m.
[removed libvirt-announce from the cc]
On 04/26/2013 04:11 PM, Daniel Veillard wrote:
On Fri, Apr 26, 2013 at 04:02:51PM +0200, Viktor Mihajlovski wrote:
> On 04/26/2013 10:09 AM, Daniel Veillard wrote:
>> So as discussed earlier this week, I have tagged the release candidate 1
>> of libvirt-1.0.5 in git and pushed the tarball and associated rpms to
>> the FTP at:
>> ftp://libvirt.org/libvirt/
>>
>> We may still push some of the patches needed by Laine to finish the
>> serie started yesterday, but at this point we should focuse our commits
>> on bug fixes and documentation. I will make an rc2 at the beginning of
>> next week and hopefully can push the final version on May 2nd.
>>
>> This passed my own small usage tests, but please give it a try.
>> As usual some feedback on portability issues are really welcome too :-)
> Unfortunately I have to report that commit b33eb0dc seems to have
> broken s390.
> I cannot start guests anymore, error message is
> error: XML error: No PCI buses available
> Will look into it, but any help is welcome.
The big switch down there lists the architectures/machines that do have
a PCI bus and we disallow adding PCI devices if they don't.
I thought that any device that qemuAssignDevicePCISlots assigns a PCI
address to would fail at QEMU level with a message about the PCI bus not
found, but it seems this is not the case for the implicit USB controller
-- we assign the address 0:0:1.2 to it, but it shows up
just as '-usb' at the qemu commmand line.
Are you able to start it after you delete the PCI address from the USB
controller in the XML? (in this case, qemuAssignDevicePCISlots will just
assign it without checking if there's a PCI bus available)
Hum, the patch seems to add a big switch about def->os.arch
in qemuDomainDefPostParse()
+ case VIR_ARCH_ALPHA:
+ case VIR_ARCH_PPC:
+ case VIR_ARCH_PPC64:
+ case VIR_ARCH_PPCEMB:
+ case VIR_ARCH_SH4:
+ case VIR_ARCH_SH4EB:
+ addPCIRoot = true;
+ break;
+ default:
+ break;
I smell a case for s390 is needed somehow.
Not here, it would result in it getting an implicit PCI controller in
the XML, even though it doesn't have a PCI bus.
The right thing would be to catch all the non-PCI devices we assign an
adddress to. Or we could just assume 1 PCI bus is always available as a
desperate measure not to break anything.
Jan
9:44 a.m.
On 04/26/2013 04:35 PM, Ján Tomko wrote:
Are you able to start it after you delete the PCI address from the USB
controller in the XML? (in this case, qemuAssignDevicePCISlots will just
assign it without checking if there's a PCI bus available)
Disregard that, it would get added there anyway.
I'll do my best to post a patch today
Jan.
9:56 a.m.
On 04/26/2013 04:44 PM, Ján Tomko wrote:
On 04/26/2013 04:35 PM, Ján Tomko wrote:
>
> Are you able to start it after you delete the PCI address from the USB
> controller in the XML? (in this case, qemuAssignDevicePCISlots will just
> assign it without checking if there's a PCI bus available)
>
Disregard that, it would get added there anyway.
I'll do my best to post a patch today
Jan.
Please check out the patch I just sent. It works for me and
should be good enough until we find a better way to disable
the implicit USB->PCI device creation.
--
Mit freundlichen Grüßen/Kind Regards
Viktor Mihajlovski
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Köderitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
10:01 a.m.
On Fri, Apr 26, 2013 at 04:56:01PM +0200, Viktor Mihajlovski wrote:
On 04/26/2013 04:44 PM, Ján Tomko wrote:
>On 04/26/2013 04:35 PM, Ján Tomko wrote:
>>
>>Are you able to start it after you delete the PCI address from the USB
>>controller in the XML? (in this case, qemuAssignDevicePCISlots will just
>>assign it without checking if there's a PCI bus available)
>>
>
>Disregard that, it would get added there anyway.
>
>I'll do my best to post a patch today
>
>Jan.
>
Please check out the patch I just sent. It works for me and
should be good enough until we find a better way to disable
the implicit USB->PCI device creation.
No, it is not good enough. We must never add hardware to the XML
description that does not exist in the actual VM being launched.
By adding a PCI root to the s390, you create a timebomb which
will change guest ABI if libvirt ever starts honouring that
PCI root config in the future.
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
9:47 a.m.
On 04/26/2013 04:35 PM, Ján Tomko wrote:
The big switch down there lists the architectures/machines that do have
a PCI bus and we disallow adding PCI devices if they don't.
I thought that any device that qemuAssignDevicePCISlots assigns a PCI
address to would fail at QEMU level with a message about the PCI bus not
found, but it seems this is not the case for the implicit USB controller
-- we assign the address 0:0:1.2 to it, but it shows up
just as '-usb' at the qemu commmand line.
Are you able to start it after you delete the PCI address from the USB
controller in the XML? (in this case, qemuAssignDevicePCISlots will just
assign it without checking if there's a PCI bus available)
No, the PCI address always get added by default. Specifying model=none
doesn't help either.
>
> Hum, the patch seems to add a big switch about def->os.arch
> in qemuDomainDefPostParse()
>
> + case VIR_ARCH_ALPHA:
> + case VIR_ARCH_PPC:
> + case VIR_ARCH_PPC64:
> + case VIR_ARCH_PPCEMB:
> + case VIR_ARCH_SH4:
> + case VIR_ARCH_SH4EB:
> + addPCIRoot = true;
> + break;
> + default:
> + break;
>
> I smell a case for s390 is needed somehow.
Not here, it would result in it getting an implicit PCI controller in
the XML, even though it doesn't have a PCI bus.
The right thing would be to catch all the non-PCI devices we assign an
adddress to. Or we could just assume 1 PCI bus is always available as a
desperate measure not to break anything.
I am currently testing the workaround
adding a fake PCI root. Will get
you posted. If that works it will give us time to come up with a
cleaner solution for the next release. I don't want to unconditionally
disable PCI for s390 even if it is not implemented in today's QEMUs.
Jan
--
Mit freundlichen Grüßen/Kind Regards
Viktor Mihajlovski
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Köderitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
1:19 p.m.
On 04/26/2013 04:47 PM, Viktor Mihajlovski wrote:
On 04/26/2013 04:35 PM, Ján Tomko wrote:
>
> The big switch down there lists the architectures/machines that do have
> a PCI bus and we disallow adding PCI devices if they don't.
>
> I thought that any device that qemuAssignDevicePCISlots assigns a PCI
> address to would fail at QEMU level with a message about the PCI bus not
> found, but it seems this is not the case for the implicit USB controller
> -- we assign the address 0:0:1.2 to it, but it shows up
> just as '-usb' at the qemu commmand line.
>
> Are you able to start it after you delete the PCI address from the USB
> controller in the XML? (in this case, qemuAssignDevicePCISlots will just
> assign it without checking if there's a PCI bus available)
>
No, the PCI address always get added by default. Specifying model=none
doesn't help either.
A fix that doesn't assign a PCI address for model=none USB controller is
pushed now.
>>
>> Hum, the patch seems to add a big switch about def->os.arch
>> in qemuDomainDefPostParse()
>>
>> + case VIR_ARCH_ALPHA:
>> + case VIR_ARCH_PPC:
>> + case VIR_ARCH_PPC64:
>> + case VIR_ARCH_PPCEMB:
>> + case VIR_ARCH_SH4:
>> + case VIR_ARCH_SH4EB:
>> + addPCIRoot = true;
>> + break;
>> + default:
>> + break;
>>
>> I smell a case for s390 is needed somehow.
>
> Not here, it would result in it getting an implicit PCI controller in
> the XML, even though it doesn't have a PCI bus.
>
> The right thing would be to catch all the non-PCI devices we assign an
> adddress to. Or we could just assume 1 PCI bus is always available as a
> desperate measure not to break anything.
I am currently testing the workaround adding a fake PCI root. Will get
you posted. If that works it will give us time to come up with a
cleaner solution for the next release. I don't want to unconditionally
disable PCI for s390 even if it is not implemented in today's QEMUs.
Other than the none USB controller fix, which I've already pushed, it
seems the patches I posted before that to fix it have finally made it
through:
https://www.redhat.com/archives/libvir-list/2013-April/msg01946.html
If we really have to do a workaround, I'd suggest just ignoring the PCI
root and assuming one PCI bus is always there. I fear adding PCI roots
to machines that don't have them would cause us similar trouble that the
implicit USB controller does now.
Jan
4:10 a.m.
On 04/26/2013 08:19 PM, Ján Tomko wrote:
A fix that doesn't assign a PCI address for model=none USB controller is
pushed now.
I can confirm this is working. Thanks!
If we really have to do a workaround, I'd suggest just ignoring the PCI
root and assuming one PCI bus is always there. I fear adding PCI roots
to machines that don't have them would cause us similar trouble that the
implicit USB controller does now.
Fully agree. The only reason that I suggested a
dummy root as a stop
gap measure was to avoid that we rush in potentially untested code.
The current code base will carry us a while, but eventually
we need to get rid of the implicit devices where they are not
applicable.
Thanks again for fixing the issues.
--
Mit freundlichen Grüßen/Kind Regards
Viktor Mihajlovski
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Köderitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
1:03 p.m.
New subject: [libvirt] [Libvirt-announce] Entering freeze for libvirt-1.0.5
On 26/04/2013, at 9:09 AM, Daniel Veillard wrote:
So as discussed earlier this week, I have tagged the release
candidate 1
of libvirt-1.0.5 in git and pushed the tarball and associated rpms to
the FTP at:
ftp://libvirt.org/libvirt/
Compiles ok on OSX. Haven't tried anything in more depth with it.
+ Justin
--
Open Source and Standards @ Red Hat
twitter.com/realjustinclift
5:09 p.m.
Il 26/04/2013 10:09, Daniel Veillard ha scritto:
So as discussed earlier this week, I have tagged the release
candidate 1
of libvirt-1.0.5 in git and pushed the tarball and associated rpms to
the FTP at:
ftp://libvirt.org/libvirt/
We may still push some of the patches needed by Laine to finish the
serie started yesterday, but at this point we should focuse our commits
on bug fixes and documentation. I will make an rc2 at the beginning of
next week and hopefully can push the final version on May 2nd.
This passed my own small usage tests, but please give it a try.
As usual some feedback on portability issues are really welcome too :-)
The series at http://thread.gmane.org/gmane.comp.emulators.libvirt/76786
is ACKed but not pushed. It can be considered a bugfix:
- it fixes network stat support for <interface type='bridge'>
- it avoids a case where QEMU executes a setuid helper, which it should
never do.
Paolo
12:59 p.m.
On Fri, Apr 26, 2013 at 04:09:59PM +0800, Daniel Veillard wrote:
So as discussed earlier this week, I have tagged the release
candidate 1
of libvirt-1.0.5 in git and pushed the tarball and associated rpms to
the FTP at:
ftp://libvirt.org/libvirt/
We may still push some of the patches needed by Laine to finish the
serie started yesterday, but at this point we should focuse our commits
on bug fixes and documentation. I will make an rc2 at the beginning of
next week and hopefully can push the final version on May 2nd.
This passed my own small usage tests, but please give it a try.
As usual some feedback on portability issues are really welcome too :-)
Looks good on the Debian buildds:
https://buildd.debian.org/status/package.php?p=libvirt&suite=experime...
(still didn't look at the kFreeBSD failures but will do now).
Cheers,
-- Guido
thanks !
Daniel
--
Daniel Veillard | Open Source and Standards, Red Hat
veillard(a)redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | virtualization library http://libvirt.org/
--
libvir-list mailing list
libvir-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
4222
days inactive
4227
days old
16 comments
9 participants
participants (9)
-
Daniel P. Berrange -
Daniel Veillard -
Eric Blake -
Guido Günther -
Justin Clift -
Ján Tomko -
Paolo Bonzini -
Ruben Kerkhof -
Viktor Mihajlovski