[libvirt] Start of freeze for libvirt-0.9.10 and availability of rc1
We are now entering the freeze for libvirt-0.9.10 Hopefully all the API changes needed for that version are already commited to git head. I have made a release candidate 1 tarball (and associated rpms) at ftp://libvirt.org/libvirt/libvirt-0.9.10-rc1.tar.gz and the git tree is tagged. I think I will make an release candidate 2 tarball on Wednesday, and I'm hoping for a final release next Monday the 13th. Please give it a try ! thanks in advance, Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
Hi all, I found the following issues: 1. compilation warnings: CC cputest.o cputest.c: In function 'cpuTestBaseline': cputest.c:122: warning: 'n' may be used uninitialized in this function [-Wuninitialized] cputest.c:122: note: 'n' was declared here At top level: cc1: warning: unrecognized command line option "-Wno-suggest-attribute=const" cc1: warning: unrecognized command line option "-Wno-suggest-attribute=pure" CCLD cputest Notes: I saw Jiri just fixed it in commit 8f0b039. 2. test cases fail: TEST: virnetsockettest ........!!!.!!! 15 FAIL TEST: qemuxml2argvtest ....................!!.................. 40 ......................................!. 80 ........................................ 120 ........................................ 160 ...!.!!!!!!.!..!!.!.................... 199 FAIL ======================================= 2 of 59 tests failed Please report to libvir-list@redhat.com ======================================= Notes: it may be I'm missing some dev package. Regards, Alex ----- Original Message ----- From: "Daniel Veillard" <veillard@redhat.com> To: libvir-list@redhat.com Cc: libvirt-announce@redhat.com Sent: Monday, February 6, 2012 3:21:21 PM Subject: [libvirt] Start of freeze for libvirt-0.9.10 and availability of rc1 We are now entering the freeze for libvirt-0.9.10 Hopefully all the API changes needed for that version are already commited to git head. I have made a release candidate 1 tarball (and associated rpms) at ftp://libvirt.org/libvirt/libvirt-0.9.10-rc1.tar.gz and the git tree is tagged. I think I will make an release candidate 2 tarball on Wednesday, and I'm hoping for a final release next Monday the 13th. Please give it a try ! thanks in advance, Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Mon, Feb 06, 2012 at 04:11:45AM -0500, Alex Jia wrote:
Hi all, I found the following issues: [...] 2. test cases fail:
TEST: virnetsockettest ........!!!.!!! 15 FAIL
TEST: qemuxml2argvtest ....................!!.................. 40 ......................................!. 80 ........................................ 120 ........................................ 160 ...!.!!!!!!.!..!!.!.................... 199 FAIL
Weird that definitely worked fine for me. Try to do an rpmbuild --rebuild libvirt-0.9.10-rc1.tar.gz to get a list of possible missing build packages. However I don't see how that could possibly affect qemuxml2argvtest ... Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On 02/06/2012 05:44 PM, Daniel Veillard wrote:
Hi all, I found the following issues: [...] 2. test cases fail:
TEST: virnetsockettest ........!!!.!!! 15 FAIL
TEST: qemuxml2argvtest ....................!!.................. 40 ......................................!. 80 ........................................ 120 ........................................ 160 ...!.!!!!!!.!..!!.!.................... 199 FAIL Weird that definitely worked fine for me. Try to do an rpmbuild --rebuild libvirt-0.9.10-rc1.tar.gz to get a list of possible missing build packages. However I don't see how
On Mon, Feb 06, 2012 at 04:11:45AM -0500, Alex Jia wrote: that could possibly affect qemuxml2argvtest ... It's okay if I installed related dev packages.
Other issues: 1. GEN probes.o /tmp/tmpOSBnp3.c:1: warning: return type defaults to 'int' /tmp/tmpOSBnp3.c:1: warning: '__dtrace' defined but not used CC libvirt_qemu_la-libvirt-qemu.lo Notes, maybe, we should silence the warning. 2. CC libvirtmod_qemu_la-libvirt-qemu-override.lo libvirt-qemu-override.c:53: warning: 'py_str' defined but not used CC libvirtmod_qemu_la-libvirt-qemu.lo Notes, it should be a useful function, maybe, we will use it later ... 3. CCLD libvirt_test.la *** Warning: Linking the shared library libvirt.la against the non-libtool *** objects probes.o is not portable! 4. *** Warning: Linking the shared library libvirt_test.la against the non-libtool *** objects probes.o is not portable! CCLD libvirt-qemu.la Notes, I often meet the item 3 and 4 warnings when compiling, although I saw gcc book said they were common error and should use .o instead of .la, we can ignore these 2 warnings in here, right? Regards, Alex
Daniel
On 02/06/2012 03:11 AM, Alex Jia wrote:
TEST: qemuxml2argvtest ....................!!.................. 40 ......................................!. 80 ........................................ 120 ........................................ 160 ...!.!!!!!!.!..!!.!.................... 199 FAIL Weird that definitely worked fine for me. Try to do an rpmbuild --rebuild libvirt-0.9.10-rc1.tar.gz to get a list of possible missing build packages. However I don't see how that could possibly affect qemuxml2argvtest ...
I haven't reproduced this issue.
It's okay if I installed related dev packages.
Do you know which dev package made the difference?
Other issues: 1. GEN probes.o /tmp/tmpOSBnp3.c:1: warning: return type defaults to 'int' /tmp/tmpOSBnp3.c:1: warning: '__dtrace' defined but not used CC libvirt_qemu_la-libvirt-qemu.lo
Notes, maybe, we should silence the warning.
I'd like to; but doing that requires either patching systemtap-sdt-devel, or else post-processing the systemtap generated files prior to passing them to the compiler. In other words, the warning is not coming from libvirt source code.
2. CC libvirtmod_qemu_la-libvirt-qemu-override.lo libvirt-qemu-override.c:53: warning: 'py_str' defined but not used CC libvirtmod_qemu_la-libvirt-qemu.lo
Notes, it should be a useful function, maybe, we will use it later ...
We should fix this one.
3. CCLD libvirt_test.la
*** Warning: Linking the shared library libvirt.la against the non-libtool *** objects probes.o is not portable!
4. *** Warning: Linking the shared library libvirt_test.la against the non-libtool *** objects probes.o is not portable! CCLD libvirt-qemu.la
Notes, I often meet the item 3 and 4 warnings when compiling, although I saw gcc book said they were common error and should use .o instead of .la, we can ignore these 2 warnings in here, right?
Not the gcc book. But this has previously come up on this list, and the answer is still the same - libtool doesn't have a way to let us shut it up when we _know_ that we are doing something that works on Linux, and where we are not doing the non-portable action of using probes.o on non-Linux because systemtap is Linux-specific. You can ignore the warning, and any patch to silence it would have to come from upstream libtool, or else finding a way to create a .lo file that wraps the generated probes.o file but which libtool can still link with. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 02/06/2012 03:11 AM, Alex Jia wrote:
TEST: qemuxml2argvtest ....................!!.................. 40 ......................................!. 80 ........................................ 120 ........................................ 160 ...!.!!!!!!.!..!!.!.................... 199 FAIL Weird that definitely worked fine for me. Try to do an rpmbuild --rebuild libvirt-0.9.10-rc1.tar.gz to get a list of possible missing build packages. However I don't see how that could possibly affect qemuxml2argvtest ... I haven't reproduced this issue.
It's okay if I installed related dev packages. Do you know which dev package made the difference?
Other issues: 1. GEN probes.o /tmp/tmpOSBnp3.c:1: warning: return type defaults to 'int' /tmp/tmpOSBnp3.c:1: warning: '__dtrace' defined but not used CC libvirt_qemu_la-libvirt-qemu.lo
Notes, maybe, we should silence the warning. I'd like to; but doing that requires either patching systemtap-sdt-devel, or else post-processing the systemtap generated files prior to passing them to the compiler. In other words, the warning is not coming from libvirt source code.
2. CC libvirtmod_qemu_la-libvirt-qemu-override.lo libvirt-qemu-override.c:53: warning: 'py_str' defined but not used CC libvirtmod_qemu_la-libvirt-qemu.lo
Notes, it should be a useful function, maybe, we will use it later ... We should fix this one.
3. CCLD libvirt_test.la
*** Warning: Linking the shared library libvirt.la against the non-libtool *** objects probes.o is not portable!
4. *** Warning: Linking the shared library libvirt_test.la against the non-libtool *** objects probes.o is not portable! CCLD libvirt-qemu.la
Notes, I often meet the item 3 and 4 warnings when compiling, although I saw gcc book said they were common error and should use .o instead of .la, we can ignore these 2 warnings in here, right? Not the gcc book. But this has previously come up on this list, and the The common error is introduced in ch8 of "The Definitive Guide to GCC" v1 book. but I think it should be a warning not error. answer is still the same - libtool doesn't have a way to let us shut it up when we _know_ that we are doing something that works on Linux, and where we are not doing the non-portable action of using probes.o on non-Linux because systemtap is Linux-specific. You can ignore the Yeah, indeed. warning, and any patch to silence it would have to come from upstream libtool, or else finding a way to create a .lo file that wraps the generated probes.o file but which libtool can still link with. However, libtool manual said we may silence this warning if specify link
On 02/07/2012 02:41 AM, Eric Blake wrote: library the path with '-lm' option, I'm not sure whether we need to follow this, as you said, after all, libvirt also supports non-linux platform. http://www.gnu.org/software/libtool/manual/libtool.html Thanks & Regards, Alex
On 02/06/2012 08:46 PM, Alex Jia wrote:
4. *** Warning: Linking the shared library libvirt_test.la against the non-libtool *** objects probes.o is not portable! CCLD libvirt-qemu.la
Notes, I often meet the item 3 and 4 warnings when compiling, although I saw gcc book said they were common error and should use .o instead of .la, we can ignore these 2 warnings in here, right? Not the gcc book. But this has previously come up on this list, and the The common error is introduced in ch8 of "The Definitive Guide to GCC" v1 book. but I think it should be a warning not error.
It _is_ a warning, not an error, and the warning is coming from libtool, with no way for us to shut it up unless we patch libtool, or else write a probes.lo wrapper around probes.o. It doesn't halt the build.
answer is still the same - libtool doesn't have a way to let us shut it up when we _know_ that we are doing something that works on Linux, and where we are not doing the non-portable action of using probes.o on non-Linux because systemtap is Linux-specific. You can ignore the Yeah, indeed. warning, and any patch to silence it would have to come from upstream libtool, or else finding a way to create a .lo file that wraps the generated probes.o file but which libtool can still link with. However, libtool manual said we may silence this warning if specify link library the path with '-lm' option, I'm not sure whether we need to follow this, as you said, after all, libvirt also supports non-linux platform.
We support non-Linux platforms, which is why we are using libtool. And on other platforms, linking probes.o via libtool won't work, which is why libtool is issuing the warning. But probes.o is only generated on Linux, and Linux happens to be a platform where libtool gets away with linking probes.o without needing a wrapper .lo file. We've been through this before - the warning is annoying, but harmless, precisely because we are doing something only on Linux, where we know that it works. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 02/07/2012 02:41 AM, Eric Blake wrote:
On 02/06/2012 03:11 AM, Alex Jia wrote:
TEST: qemuxml2argvtest ....................!!.................. 40 ......................................!. 80 ........................................ 120 ........................................ 160 ...!.!!!!!!.!..!!.!.................... 199 FAIL Weird that definitely worked fine for me. Try to do an rpmbuild --rebuild libvirt-0.9.10-rc1.tar.gz to get a list of possible missing build packages. However I don't see how that could possibly affect qemuxml2argvtest ... I haven't reproduced this issue.
It's okay if I installed related dev packages. Do you know which dev package made the difference? I missed one, as Daniel suggested, I used rpmbuild to rebuild
On 02/07/2012 11:46 AM, Alex Jia wrote: libvirt-0.9.10-rc1.tar.gz then install related packages: libblkid-devel, libpcap-devel, avahi-devel, sanlock-devel, parted-devel, libpciaccess-devel
Other issues: 1. GEN probes.o /tmp/tmpOSBnp3.c:1: warning: return type defaults to 'int' /tmp/tmpOSBnp3.c:1: warning: '__dtrace' defined but not used CC libvirt_qemu_la-libvirt-qemu.lo
Notes, maybe, we should silence the warning. I'd like to; but doing that requires either patching systemtap-sdt-devel, or else post-processing the systemtap generated files prior to passing them to the compiler. In other words, the warning is not coming from libvirt source code.
2. CC libvirtmod_qemu_la-libvirt-qemu-override.lo libvirt-qemu-override.c:53: warning: 'py_str' defined but not used CC libvirtmod_qemu_la-libvirt-qemu.lo
Notes, it should be a useful function, maybe, we will use it later ... We should fix this one.
3. CCLD libvirt_test.la
*** Warning: Linking the shared library libvirt.la against the non-libtool *** objects probes.o is not portable!
4. *** Warning: Linking the shared library libvirt_test.la against the non-libtool *** objects probes.o is not portable! CCLD libvirt-qemu.la
Notes, I often meet the item 3 and 4 warnings when compiling, although I saw gcc book said they were common error and should use .o instead of .la, we can ignore these 2 warnings in here, right? Not the gcc book. But this has previously come up on this list, and the
answer is still the same - libtool doesn't have a way to let us shut it up when we _know_ that we are doing something that works on Linux, and where we are not doing the non-portable action of using probes.o on non-Linux because systemtap is Linux-specific. You can ignore the Yeah, indeed. warning, and any patch to silence it would have to come from upstream libtool, or else finding a way to create a .lo file that wraps the generated probes.o file but which libtool can still link with. However, libtool manual said we may silence this warning if specify
The common error is introduced in ch8 of "The Definitive Guide to GCC" v1 book. but I think it should be a warning not error. link library the path with '-lm' option, I'm not sure whether we need to follow this, as you said, after all, libvirt also supports non-linux platform.
http://www.gnu.org/software/libtool/manual/libtool.html
Thanks & Regards, Alex
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On 02/06/2012 11:41 AM, Eric Blake wrote:
1. GEN probes.o /tmp/tmpOSBnp3.c:1: warning: return type defaults to 'int' /tmp/tmpOSBnp3.c:1: warning: '__dtrace' defined but not used CC libvirt_qemu_la-libvirt-qemu.lo
Notes, maybe, we should silence the warning.
I'd like to; but doing that requires either patching systemtap-sdt-devel, or else post-processing the systemtap generated files prior to passing them to the compiler. In other words, the warning is not coming from libvirt source code.
Postprocessing files prior to passing them to the compiler is not even possible - 'dtrace' is converting the .d file straight to .o via an embedded call to gcc, with no chance of us ever getting our hands on the intermediate file (in your case, it was named /tmp/tmpOSBnp3.c, but this name changes on every run of dtrace). You may want to file a bugzilla against dtrace, from the systemtap-sdt-devel package.
2. CC libvirtmod_qemu_la-libvirt-qemu-override.lo libvirt-qemu-override.c:53: warning: 'py_str' defined but not used CC libvirtmod_qemu_la-libvirt-qemu.lo
Notes, it should be a useful function, maybe, we will use it later ...
We should fix this one.
Done - I'm pushing this under the trivial rule. From 9fbbcda6b73e3c33b22a34e2f3dceefe60fc1a2a Mon Sep 17 00:00:00 2001 From: Eric Blake <eblake@redhat.com> Date: Tue, 7 Feb 2012 17:14:11 -0700 Subject: [PATCH] python: drop unused function Gcc warned about an unused static function. * python/libvirt-qemu-override.c (py_str): Delete. --- python/libvirt-qemu-override.c | 16 +--------------- 1 files changed, 1 insertions(+), 15 deletions(-) diff --git a/python/libvirt-qemu-override.c b/python/libvirt-qemu-override.c index 485c809..c220af1 100644 --- a/python/libvirt-qemu-override.c +++ b/python/libvirt-qemu-override.c @@ -4,7 +4,7 @@ * entry points where an automatically generated stub is * unpractical * - * Copyright (C) 2011 Red Hat, Inc. + * Copyright (C) 2011-2012 Red Hat, Inc. * * Daniel Veillard <veillard@redhat.com> */ @@ -47,20 +47,6 @@ extern void initcygvirtmod_qemu(void); #define VIR_PY_INT_FAIL (libvirt_intWrap(-1)) #define VIR_PY_INT_SUCCESS (libvirt_intWrap(0)) -/* We don't want to free() returned value. As written in doc: - * PyString_AsString returns pointer to 'internal buffer of string, - * not a copy' and 'It must not be deallocated'. */ -static char *py_str(PyObject *obj) -{ - PyObject *str = PyObject_Str(obj); - if (!str) { - PyErr_Print(); - PyErr_Clear(); - return NULL; - }; - return PyString_AsString(str); -} - /************************************************************************ * * * Statistics * -- 1.7.7.6 -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 06/02/2012, at 6:21 PM, Daniel Veillard wrote:
We are now entering the freeze for libvirt-0.9.10 Hopefully all the API changes needed for that version are already commited to git head.
I have made a release candidate 1 tarball (and associated rpms) at ftp://libvirt.org/libvirt/libvirt-0.9.10-rc1.tar.gz and the git tree is tagged.
I think I will make an release candidate 2 tarball on Wednesday, and I'm hoping for a final release next Monday the 13th.
Please give it a try !
Compiles ok on Mac OS X 10.7. (64-bit) Haven't tried the regression tests, nor earlier versions of OSX though. ;) Regards and best wishes, Justin Clift -- Aeolus Community Manager http://www.aeolusproject.org
On Mon, Feb 06, 2012 at 03:21:21PM +0800, Daniel Veillard wrote:
We are now entering the freeze for libvirt-0.9.10 Hopefully all the API changes needed for that version are already commited to git head.
Okay I made an rc2 release with the python bindings fix (thanks !) ftp://libvirt.org/libvirt/libvirt-0.9.10-rc2.tar.gz the rpms are available too and the git tree is tagged. Hopefully that one is more usable, and I'm still hoping for a release on Monday, thanks ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On 2012年02月08日 14:59, Daniel Veillard wrote:
On Mon, Feb 06, 2012 at 03:21:21PM +0800, Daniel Veillard wrote:
We are now entering the freeze for libvirt-0.9.10 Hopefully all the API changes needed for that version are already commited to git head.
Okay I made an rc2 release with the python bindings fix (thanks !)
ftp://libvirt.org/libvirt/libvirt-0.9.10-rc2.tar.gz the rpms are available too and the git tree is tagged.
Hopefully that one is more usable, and I'm still hoping for a release on Monday,
thanks !
Daniel
Things are fine on my FC16. Osier
On 02/08/2012 02:59 PM, Daniel Veillard wrote:
On Mon, Feb 06, 2012 at 03:21:21PM +0800, Daniel Veillard wrote:
We are now entering the freeze for libvirt-0.9.10 Hopefully all the API changes needed for that version are already commited to git head. Okay I made an rc2 release with the python bindings fix (thanks !) The python bindings work well for me on rhel, and unit test cases also are fine except for valgrind found a memory leak:
==21503== 112 (32 direct, 80 indirect) bytes in 1 blocks are definitely lost in loss record 37 of 40 ==21503== at 0x4A04A28: calloc (vg_replace_malloc.c:467) ==21503== by 0x4A8991: virAlloc (memory.c:101) ==21503== by 0x505A6C: x86DataCopy (cpu_x86.c:247) ==21503== by 0x507B34: x86Compute (cpu_x86.c:1225) ==21503== by 0x43103C: qemuBuildCommandLine (qemu_command.c:3561) ==21503== by 0x41C9F7: testCompareXMLToArgvHelper (qemuxml2argvtest.c:183) ==21503== by 0x41E10D: virtTestRun (testutils.c:141) ==21503== by 0x41B942: mymain (qemuxml2argvtest.c:705) ==21503== by 0x41D7E7: virtTestMain (testutils.c:696)
ftp://libvirt.org/libvirt/libvirt-0.9.10-rc2.tar.gz the rpms are available too and the git tree is tagged.
Hopefully that one is more usable, and I'm still hoping for a release on Monday,
thanks !
Daniel
On Wed, Feb 08, 2012 at 16:35:57 +0800, Alex Jia wrote:
On 02/08/2012 02:59 PM, Daniel Veillard wrote:
On Mon, Feb 06, 2012 at 03:21:21PM +0800, Daniel Veillard wrote:
We are now entering the freeze for libvirt-0.9.10 Hopefully all the API changes needed for that version are already commited to git head. Okay I made an rc2 release with the python bindings fix (thanks !) The python bindings work well for me on rhel, and unit test cases also are fine except for valgrind found a memory leak:
==21503== 112 (32 direct, 80 indirect) bytes in 1 blocks are definitely lost in loss record 37 of 40 ==21503== at 0x4A04A28: calloc (vg_replace_malloc.c:467) ==21503== by 0x4A8991: virAlloc (memory.c:101) ==21503== by 0x505A6C: x86DataCopy (cpu_x86.c:247) ==21503== by 0x507B34: x86Compute (cpu_x86.c:1225) ==21503== by 0x43103C: qemuBuildCommandLine (qemu_command.c:3561) ==21503== by 0x41C9F7: testCompareXMLToArgvHelper (qemuxml2argvtest.c:183) ==21503== by 0x41E10D: virtTestRun (testutils.c:141) ==21503== by 0x41B942: mymain (qemuxml2argvtest.c:705) ==21503== by 0x41D7E7: virtTestMain (testutils.c:696)
This should be fixed by "qemu: Fix memory leak when building -cpu argument" patch I've just sent. Jirka
On 08/02/2012, at 5:59 PM, Daniel Veillard wrote:
On Mon, Feb 06, 2012 at 03:21:21PM +0800, Daniel Veillard wrote:
We are now entering the freeze for libvirt-0.9.10 Hopefully all the API changes needed for that version are already commited to git head.
Okay I made an rc2 release with the python bindings fix (thanks !)
ftp://libvirt.org/libvirt/libvirt-0.9.10-rc2.tar.gz the rpms are available too and the git tree is tagged.
Hopefully that one is more usable, and I'm still hoping for a release on Monday,
RC2 also compiles/runs ok on OSX 10.7. + Justin
thanks !
Daniel
-- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
_______________________________________________ Libvirt-announce mailing list Libvirt-announce@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-announce
-- Aeolus Community Manager http://www.aeolusproject.org
On 02/08/2012 07:59 AM, Daniel Veillard wrote:
ftp://libvirt.org/libvirt/libvirt-0.9.10-rc2.tar.gz the rpms are available too and the git tree is tagged.
Hopefully that one is more usable, and I'm still hoping for a release on Monday,
Osier and I discussed SCSI addressing today. It looks like there is a risk of having backwards-incompatible changes to the addressing of spapr-vscsi and virtio-scsi LUNs in 0.9.11. This is because the implicit addressing of SCSI devices misuses the "unit" element for the SCSI target. If there is still time, could you revert commit c9abfad (qemu: add virtio-scsi controller model, 2012-01-13) and commit 7b345b6 (qemu: add ibmvscsi controller model, 2012-01-13) from 0.9.10? Osier then can resubmit them together with his work on SCSI addresses. Paolo
On Mon, Feb 13, 2012 at 02:24:05PM +0100, Paolo Bonzini wrote:
On 02/08/2012 07:59 AM, Daniel Veillard wrote:
ftp://libvirt.org/libvirt/libvirt-0.9.10-rc2.tar.gz the rpms are available too and the git tree is tagged.
Hopefully that one is more usable, and I'm still hoping for a release on Monday,
Osier and I discussed SCSI addressing today. It looks like there is a risk of having backwards-incompatible changes to the addressing of spapr-vscsi and virtio-scsi LUNs in 0.9.11. This is because the implicit addressing of SCSI devices misuses the "unit" element for the SCSI target.
If there is still time, could you revert commit c9abfad (qemu: add virtio-scsi controller model, 2012-01-13) and commit 7b345b6 (qemu: add ibmvscsi controller model, 2012-01-13) from 0.9.10? Osier then can resubmit them together with his work on SCSI addresses.
Okay, done, thanks for the heads-up ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On 02/06/2012 12:21 AM, Daniel Veillard wrote:
We are now entering the freeze for libvirt-0.9.10 Hopefully all the API changes needed for that version are already commited to git head.
I have made a release candidate 1 tarball (and associated rpms) at ftp://libvirt.org/libvirt/libvirt-0.9.10-rc1.tar.gz and the git tree is tagged.
I think I will make an release candidate 2 tarball on Wednesday, and I'm hoping for a final release next Monday the 13th.
Please give it a try !
I'm wondering if we're too late for one more API to round out the API we added in this release. Qemu is proposing a new monitor command system_wakeup which lets the host inject a power-button wakeup to a guest that has gone into S3 sleep. Since we added the virDomainPMSuspendForDuration command to put the guest into S3 from the host, I think we need a counterpart API that wakes the guest back up, rather than relying on mouse clicks, serial input, or timeouts doing the job for us. It's a shame that virDomainResume() has no flags argument, and that it is already tied to virDomainSuspend() (aka guest pause), so I'm thinking something like: /* Inject a wakeup into the guest that previously used * virDomainPMSuspendForDuration, rather than waiting for the * previously requested duration (if any) to elapse. */ int virDomainPMWakeup(virDomainPtr dom, unsigned int flags); -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 10.02.2012 00:32, Eric Blake wrote:
On 02/06/2012 12:21 AM, Daniel Veillard wrote:
We are now entering the freeze for libvirt-0.9.10 Hopefully all the API changes needed for that version are already commited to git head.
I have made a release candidate 1 tarball (and associated rpms) at ftp://libvirt.org/libvirt/libvirt-0.9.10-rc1.tar.gz and the git tree is tagged.
I think I will make an release candidate 2 tarball on Wednesday, and I'm hoping for a final release next Monday the 13th.
Please give it a try !
I'm wondering if we're too late for one more API to round out the API we added in this release. Qemu is proposing a new monitor command system_wakeup which lets the host inject a power-button wakeup to a guest that has gone into S3 sleep. Since we added the virDomainPMSuspendForDuration command to put the guest into S3 from the host, I think we need a counterpart API that wakes the guest back up, rather than relying on mouse clicks, serial input, or timeouts doing the job for us. It's a shame that virDomainResume() has no flags argument, and that it is already tied to virDomainSuspend() (aka guest pause), so I'm thinking something like:
/* Inject a wakeup into the guest that previously used * virDomainPMSuspendForDuration, rather than waiting for the * previously requested duration (if any) to elapse. */ int virDomainPMWakeup(virDomainPtr dom, unsigned int flags);
I'd like to see this API in as well. Michal
On Thu, Feb 09, 2012 at 04:32:46PM -0700, Eric Blake wrote:
On 02/06/2012 12:21 AM, Daniel Veillard wrote:
We are now entering the freeze for libvirt-0.9.10 Hopefully all the API changes needed for that version are already commited to git head.
I have made a release candidate 1 tarball (and associated rpms) at ftp://libvirt.org/libvirt/libvirt-0.9.10-rc1.tar.gz and the git tree is tagged.
I think I will make an release candidate 2 tarball on Wednesday, and I'm hoping for a final release next Monday the 13th.
Please give it a try !
I'm wondering if we're too late for one more API to round out the API we added in this release. Qemu is proposing a new monitor command system_wakeup which lets the host inject a power-button wakeup to a guest that has gone into S3 sleep. Since we added the virDomainPMSuspendForDuration command to put the guest into S3 from the host, I think we need a counterpart API that wakes the guest back up, rather than relying on mouse clicks, serial input, or timeouts doing the job for us. It's a shame that virDomainResume() has no flags argument, and that it is already tied to virDomainSuspend() (aka guest pause), so I'm thinking something like:
/* Inject a wakeup into the guest that previously used * virDomainPMSuspendForDuration, rather than waiting for the * previously requested duration (if any) to elapse. */ int virDomainPMWakeup(virDomainPtr dom, unsigned int flags);
Just to throw this out there, could we not simply implement the rest of the power states in this API? Kind of late to be asking this question, I suppose, but we haven't released this API yet, could we change its name to virDomainPMSetPowerStateForDuration? Dave
-- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On 02/10/2012 12:21 PM, Dave Allan wrote:
I'm wondering if we're too late for one more API to round out the API we added in this release. Qemu is proposing a new monitor command system_wakeup which lets the host inject a power-button wakeup to a guest that has gone into S3 sleep. Since we added the virDomainPMSuspendForDuration command to put the guest into S3 from the host, I think we need a counterpart API that wakes the guest back up, rather than relying on mouse clicks, serial input, or timeouts doing the job for us. It's a shame that virDomainResume() has no flags argument, and that it is already tied to virDomainSuspend() (aka guest pause), so I'm thinking something like:
/* Inject a wakeup into the guest that previously used * virDomainPMSuspendForDuration, rather than waiting for the * previously requested duration (if any) to elapse. */ int virDomainPMWakeup(virDomainPtr dom, unsigned int flags);
Just to throw this out there, could we not simply implement the rest of the power states in this API? Kind of late to be asking this question, I suppose, but we haven't released this API yet, could we change its name to virDomainPMSetPowerStateForDuration?
Interesting idea! It means we have one call, instead of 2, and 4 PM states instead of 3 (suspend, hibernate, hybrid, and now wakeup). Of course, wakeup for duration doesn't make much sense, so we could explicitly require a 0 duration for the wakeup case. That name is rather long; we originally went with DomainPMSuspendForDuration for similarity to NodeSuspendForDuration and to make it clear that this is PMSuspend (power management in the guest) vs. virDomainSuspend (hypervisor pause). But once we lose the name 'Suspend', the 'ForDuration' just sounds long; and then there is the fact that this API can wakeup where NodeSuspendForDuration cannot. Maybe even this shorter name would do: virDomainSetPowerState(domain, state, duration, flags) On the other hand, it probably also points out that we are missing a counterpart: virDomainGetPowerState(domain, flags) after all, with NodeSuspendForDuration, we always know what state we are in (the host is active if you can query, and all other states the host is non-responsive); but with guests, the hypervisor can indeed be queried to see whether the guest is currently active or in S3. Sounds like we have some important API decisions to make, and fast, before the 0.9.10 release locks us in stone. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 02/10/2012 01:33 PM, Eric Blake wrote:
On the other hand, it probably also points out that we are missing a counterpart:
virDomainGetPowerState(domain, flags)
after all, with NodeSuspendForDuration, we always know what state we are in (the host is active if you can query, and all other states the host is non-responsive); but with guests, the hypervisor can indeed be queried to see whether the guest is currently active or in S3.
Actually, the existing virDomainGetState() may be good enough for this task of querying whether the guest is in S3; but it may require enhancing our collection of virDomain*Reason to have more states and transition reasons. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On Fri, Feb 10, 2012 at 13:33:47 -0700, Eric Blake wrote:
On 02/10/2012 12:21 PM, Dave Allan wrote:
I'm wondering if we're too late for one more API to round out the API we added in this release. Qemu is proposing a new monitor command system_wakeup which lets the host inject a power-button wakeup to a guest that has gone into S3 sleep. Since we added the virDomainPMSuspendForDuration command to put the guest into S3 from the host, I think we need a counterpart API that wakes the guest back up, rather than relying on mouse clicks, serial input, or timeouts doing the job for us. It's a shame that virDomainResume() has no flags argument, and that it is already tied to virDomainSuspend() (aka guest pause), so I'm thinking something like:
/* Inject a wakeup into the guest that previously used * virDomainPMSuspendForDuration, rather than waiting for the * previously requested duration (if any) to elapse. */ int virDomainPMWakeup(virDomainPtr dom, unsigned int flags);
Just to throw this out there, could we not simply implement the rest of the power states in this API? Kind of late to be asking this question, I suppose, but we haven't released this API yet, could we change its name to virDomainPMSetPowerStateForDuration?
Interesting idea! It means we have one call, instead of 2, and 4 PM states instead of 3 (suspend, hibernate, hybrid, and now wakeup). Of course, wakeup for duration doesn't make much sense, so we could explicitly require a 0 duration for the wakeup case.
I'm not a big fan of this idea. There are two different things here: suspending (in whatever way) and waking up. I think it makes sense to have separate APIs for them. After all we don't have a virDomainSetState API which we could use to transition domain between lifecycle states (running, shutoff, paused, ...). We have separate APIs for each transition, each doing one "simple" thing and possibly taking different data needed for that transition. Jirka
On Mon, Feb 13, 2012 at 03:39:51PM +0100, Jiri Denemark wrote:
On Fri, Feb 10, 2012 at 13:33:47 -0700, Eric Blake wrote:
On 02/10/2012 12:21 PM, Dave Allan wrote:
I'm wondering if we're too late for one more API to round out the API we added in this release. Qemu is proposing a new monitor command system_wakeup which lets the host inject a power-button wakeup to a guest that has gone into S3 sleep. Since we added the virDomainPMSuspendForDuration command to put the guest into S3 from the host, I think we need a counterpart API that wakes the guest back up, rather than relying on mouse clicks, serial input, or timeouts doing the job for us. It's a shame that virDomainResume() has no flags argument, and that it is already tied to virDomainSuspend() (aka guest pause), so I'm thinking something like:
/* Inject a wakeup into the guest that previously used * virDomainPMSuspendForDuration, rather than waiting for the * previously requested duration (if any) to elapse. */ int virDomainPMWakeup(virDomainPtr dom, unsigned int flags);
Just to throw this out there, could we not simply implement the rest of the power states in this API? Kind of late to be asking this question, I suppose, but we haven't released this API yet, could we change its name to virDomainPMSetPowerStateForDuration?
Interesting idea! It means we have one call, instead of 2, and 4 PM states instead of 3 (suspend, hibernate, hybrid, and now wakeup). Of course, wakeup for duration doesn't make much sense, so we could explicitly require a 0 duration for the wakeup case.
I'm not a big fan of this idea. There are two different things here: suspending (in whatever way) and waking up. I think it makes sense to have separate APIs for them. After all we don't have a virDomainSetState API which we could use to transition domain between lifecycle states (running, shutoff, paused, ...). We have separate APIs for each transition, each doing one "simple" thing and possibly taking different data needed for that transition.
Ok, fair enough; I just thought I'd better ask the question. Dave
Jirka
participants (9)
-
Alex Jia -
Daniel Veillard -
Dave Allan -
Eric Blake -
Jiri Denemark -
Justin Clift -
Michal Privoznik -
Osier Yang -
Paolo Bonzini