Re: [libvirt] libvirt testing with autotest
On 02/20/2013 03:47 PM, Cole Robinson wrote: A few misc things: - The default libvirt tests seem to work fine as non-root, though every libvirt test is marked as 'root only'. I'm not sure what the practical effect of that is. Long story short, this is mostly due to virbr0 bridge access with the regular user. I didn't know about the qemu bridge helper, so I ended up marking the libvirt tests as 'root only'. I'll fix this ASAP. - qemu also has a basic set of smoke tests that test migration, no extra config required. A custom qemu binary can be used with ./run --qemu-bin. Probably useful even for libvirt devs that are tracking upstream qemu, if you suspect qemu.git may be currently be broken. Yes, we have an extensive set of qemu tests. By default we run basic qemu migration tests, but there are many others, it's all a matter of running: ./run -t qemu --list-tests To see what's in there. Speaking of migration tests, I recall talking about this before with Daniel, but long story short, I believe it would be beneficial for libvirt to implement migration inside the same host. With qemu is possible to do that, qemu transfers its state to another qemu process. It is very handy to test migration, and it seems doable in libvirt as well. Thanks, Lucas -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Modified version of the libvirt-test-api wrapper
On 03/14/2012 11:56 AM, Guannan Ren wrote: On 03/14/2012 06:45 PM, Daniel Veillard wrote: On Tue, Mar 13, 2012 at 11:05:31PM -0300, Lucas Meneghel Rodrigues wrote: Hi Guannan: I've worked on your first version of the libvirt-test-api wrapper for autotest. Could you please check if you like the modified version? https://github.com/autotest/autotest/pull/230 If you do think it's fine, you can ack it, or you might take it, modify and resend it. On a git branch, you can do the following: curl https://github.com/autotest/autotest/pull/230.patch | git am And then modify and resend. All this looks fine to me. Maybe the libvirt-test-API.tar.gz should be renamed to stamp it, we should make sure it is recent, and possibly make a release (that could be as simple as copying one of ftp://libvirt.org/libvirt/libvirt-test-API/libvirt-test-API-git-snapshot.tar.gz and renaming it as libvirt-test-API-0.1.0.tar.gz) and push that to autotest git instead, Daniel I agree with this, for following work, we could submit patch to autotest mailing list. Guannan Ok, so I've commited the wrapper to the upstream repo: https://github.com/autotest/autotest/commit/c915fa8aea2c6a0542f2d798ad6a0fbaf2738ef3 When you want to follow up with this, let me know. Cheers, Lucas -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Modified version of the libvirt-test-api wrapper
Hi Guannan: I've worked on your first version of the libvirt-test-api wrapper for autotest. Could you please check if you like the modified version? https://github.com/autotest/autotest/pull/230 If you do think it's fine, you can ack it, or you might take it, modify and resend it. On a git branch, you can do the following: curl https://github.com/autotest/autotest/pull/230.patch | git am And then modify and resend. Cheers, Lucas -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] libvirt_tck autotest wrapper looks good, commited
Thanks Guannan: https://github.com/autotest/autotest/commit/ba4b748e7b9a9bfe7898a97cdccdc9b867d5321c Cheers, Lucas -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libvirt TCK wrapper for autotest review
On 02/23/2012 12:27 PM, Guannan Ren wrote: Hi Lucas, Thanks for your these good modifications. There is one place I noticed where you output each testcase of *.t into a separate file with .tap extension. hence, it has a corresponding log file with little content for each testcase. it seem a little harder to check compared to just one log file. The rest of them is perfect for me. Guannan Ren Thanks! Now, feel free to pick this up and modify as you wish, then send me as a pull request/patch to the mailing list. I'll close the example pull request and will be waiting on you, ok? Cheers, Lucas -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] conf/default.cfg: Update Fedora download URLs
libvirt TCK is currently broke since it can't download
from the old alias download.fedora.redhat.com, since that
alias was removed and people really should update their
download links. Point to the new dl.fedoraproject.org
URLs.
Signed-off-by: Lucas Meneghel Rodrigues l...@redhat.com
---
conf/default.cfg |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/conf/default.cfg b/conf/default.cfg
index cb70149..a303d88 100644
--- a/conf/default.cfg
+++ b/conf/default.cfg
@@ -69,8 +69,8 @@ kernels = (
hvm
xen
)
- kernel =
http://download.fedora.redhat.com/pub/fedora/linux/releases/15/Fedora/i386/os/images/pxeboot/vmlinuz-PAE
- initrd =
http://download.fedora.redhat.com/pub/fedora/linux/releases/15/Fedora/i386/os/images/pxeboot/initrd-PAE.img
+ kernel =
http://dl.fedoraproject.org/pub/fedora/linux/releases/15/Fedora/i386/os/images/pxeboot/vmlinuz-PAE
+ initrd =
http://dl.fedoraproject.org/pub/fedora/linux/releases/15/Fedora/i386/os/images/pxeboot/initrd-PAE.img
}
# Fedora 15 x86_64 has pv_ops, so one kernel can do both Xen and KVM guests
here
{
@@ -79,8 +79,8 @@ kernels = (
hvm
xen
)
- kernel =
http://download.fedora.redhat.com/pub/fedora/linux/releases/15/Fedora/x86_64/os/images/pxeboot/vmlinuz
- initrd =
http://download.fedora.redhat.com/pub/fedora/linux/releases/15/Fedora/x86_64/os/images/pxeboot/initrd.img
+ kernel =
http://dl.fedoraproject.org/pub/fedora/linux/releases/15/Fedora/x86_64/os/images/pxeboot/vmlinuz
+ initrd =
http://dl.fedoraproject.org/pub/fedora/linux/releases/15/Fedora/x86_64/os/images/pxeboot/initrd.img
}
# User mode linux i686 needs custom kernel + root filesystem
{
--
1.7.7.6
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] libvirt TCK wrapper for autotest review
Hi guys, I was here looking at the autotest wrapper for libvirt TCK and then decided to work on it, as I had the review fresh on my mind. Things that I've worked on: * Fixed some download links, that were already sent to upstream tck and applied (thanks Dan Berrange) * Instead of making all tests output to the same DEBUG log, make them output to separate .tap files on the results directory * Run all tests available for a given item, rather than stopping the test on the first failure * removed capitalization on the wrapper name, since it's project policy * Use os.environ, and some features of the subcommand execution API to execute the tests * Remove usages of error.JobError, as the problems there are more error.TestError, since they are restricted to the libvirt_tck test, not the entire job (in autotest, a job can do more stuff than just a sequence of job.runtest() calls). * Made the error messages more descriptive, with info of all failed tests So, the current output of the tests is like this: $ sudo client/bin/autotest run libvirt_tck 18:29:27 INFO | Writing results to /home/lmr/Code/autotest.lmr/client/results/default 18:29:27 INFO | START timestamp=1329942567 localtime=Feb 22 18:29:27 18:29:27 INFO | START libvirt_tck.domain libvirt_tck.domain timestamp=1329942567 localtime=Feb 22 18:29:27 18:30:19 ERROR| child process failed 18:30:19 INFO | FAIL libvirt_tck.domain libvirt_tck.domain timestamp=1329942619 localtime=Feb 22 18:30:19 FAIL: ['120-disks-stats.t', '205-disk-hotplug-ordering.t'] 18:30:19 INFO | END FAIL libvirt_tck.domain libvirt_tck.domain timestamp=1329942619 localtime=Feb 22 18:30:19 18:30:19 INFO | START libvirt_tck.hooks libvirt_tck.hooks timestamp=1329942619 localtime=Feb 22 18:30:19 18:30:19 ERROR| child process failed 18:30:19 INFO | FAIL libvirt_tck.hooks libvirt_tck.hooks timestamp=1329942619 localtime=Feb 22 18:30:19 FAIL: ['051-daemon-hook.t', '052-domain-hook.t'] 18:30:19 INFO | END FAIL libvirt_tck.hooks libvirt_tck.hooks timestamp=1329942619 localtime=Feb 22 18:30:19 18:30:19 INFO | START libvirt_tck.networks libvirt_tck.networks timestamp=1329942619 localtime=Feb 22 18:30:19 18:30:28 INFO | GOOD libvirt_tck.networks libvirt_tck.networks timestamp=1329942628 localtime=Feb 22 18:30:28 completed successfully 18:30:28 INFO | END GOOD libvirt_tck.networks libvirt_tck.networks timestamp=1329942628 localtime=Feb 22 18:30:28 18:30:28 INFO | START libvirt_tck.nwfilter libvirt_tck.nwfilter timestamp=1329942628 localtime=Feb 22 18:30:28 18:30:32 ERROR| child process failed 18:30:32 INFO | FAIL libvirt_tck.nwfilter libvirt_tck.nwfilter timestamp=1329942632 localtime=Feb 22 18:30:32 FAIL: ['090-install-image.t', '100-ping-still-working.t', '210-no-mac-spoofing.t', '220-no-ip-spoofing.t', '230-no-mac-broadcast.t', '240-no-arp-spoofing.t', '300-vsitype.t'] 18:30:32 INFO | END FAIL libvirt_tck.nwfilter libvirt_tck.nwfilter timestamp=1329942632 localtime=Feb 22 18:30:32 18:30:32 INFO | START libvirt_tck.qemu libvirt_tck.qemu timestamp=1329942632 localtime=Feb 22 18:30:32 18:30:40 ERROR| child process failed 18:30:40 INFO | FAIL libvirt_tck.qemu libvirt_tck.qemu timestamp=1329942640 localtime=Feb 22 18:30:40 FAIL: ['205-qcow2-double-backing-file.t'] 18:30:40 INFO | END FAIL libvirt_tck.qemu libvirt_tck.qemu timestamp=1329942640 localtime=Feb 22 18:30:40 18:30:40 INFO | START libvirt_tck.selinux libvirt_tck.selinux timestamp=1329942640 localtime=Feb 22 18:30:40 18:30:49 ERROR| child process failed 18:30:49 INFO | FAIL libvirt_tck.selinux libvirt_tck.selinux timestamp=1329942649 localtime=Feb 22 18:30:49 FAIL: ['055-dynamic-base-label.t', '100-static-relabel-no.t'] 18:30:49 INFO | END FAIL libvirt_tck.selinux libvirt_tck.selinux timestamp=1329942649 localtime=Feb 22 18:30:49 18:30:49 INFO | START libvirt_tck.storage libvirt_tck.storage timestamp=1329942649 localtime=Feb 22 18:30:49 18:31:24 INFO | GOOD libvirt_tck.storage libvirt_tck.storage timestamp=1329942684 localtime=Feb 22 18:31:24 completed successfully 18:31:24 INFO | END GOOD libvirt_tck.storage libvirt_tck.storage timestamp=1329942684 localtime=Feb 22 18:31:24 18:31:24 INFO | END GOOD timestamp=1329942684 localtime=Feb 22 18:31:24 As time allows, I might take a look at the failures and help with libvirt_tck. I've combined all modifications to a single, self contained commit. Also, as the work is self contained, it could be very very easily rebased to the latest upstream tree. I've updated my personal repo and sent a github pull request that you guys can see and review: https://github.com/autotest/autotest/pull/192 I'm still not going to merge this to the upstream tree just yet, since I'd like to hear some feedback from you guys. As for developing together with autotest, I guess you can easily use the clone you have on libvirt now, and on your working directory you can add the following remote: [remote
Re: [libvirt] [Qemu-devel] Transitioning from HMP to QMP for QEMU
On 12/15/2011 11:33 AM, Kevin Wolf wrote: Am 15.12.2011 14:18, schrieb Jan Kiszka: On 2011-12-15 14:02, Stefan Hajnoczi wrote: What is the status of QEMU's transition from HMP to the QMP interface? My current understanding is that QEMU provides new HMP commands for humans, but HMP is being phased out as an API. Management tools should rely only on QMP for new commands. That would mean new HMP commands are not guaranteed to produce backwards-compatible output because tools are not supposed to parse the output. On the libvirt side, new QEMU features should only be supported via the json monitor in the future (i.e. human monitor patches should not be sent/merged)? Existing HMP commands will still need the human monitor support in order to handle old QEMU versions gracefully, but I'm thinking about new commands only. Does everyone agree on this? I think this is an important discussion if we want our management interface to get better and more consistent in the future. To phase out the classic HMP implementation, we need an internal HMP-over-JSON wrapper (with tab expansion etc.) so that virtual console and gdbstub monitors continue to benefit from new commands. Those interfaces will stay for a long time, I'm sure. I think we're not talking about dropping HMP here, only about how long to support it as a stable API for management tools. I believe that we have been in a transitional phase for long enough now that we can start changing the output format of HMP commands without considering it an API breakage. Yes, I've got the same impression. But while we are at it, forgive my naiveness, but wouldn't be worthwhile to consider dropping the human monitor in the long run? -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
