May 2012 - Devel - libvirt List Archives

[libvirt] How to use a Virtio-serial port
by Pankaj Rawat 18 May '12

18 May '12

Hi all, I want to use virtio-serial For this I changes my guest xml <channel type='pty'> <target type='virtio' name='arbitrary.virtio.serial.port.name'/> </channel> This create a virtio port in guest as follow # ls -l /dev/virtio-ports/ lrwxrwxrwx. 1 root root 11 May 15 02:59 arbitrary.virtio.serial.port.name -> ../vport0p1 Now I want to use this port What type of application use this port for communication and how can I use it ? Regards Pankaj Rawat DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or NECHCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of NECHCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. . -----------------------------------------------------------------------------------------------------------------------

2 3

[libvirt] Report of tsan first testing with libvirt(d)
by Daniel Veillard 18 May '12

18 May '12

Tsan is a heavilly reworked version of helgrind the data race detector based on Valgrind (at least for linux) It is developped by Google and described/available there: http://code.google.com/p/data-race-test/wiki/ThreadSanitizer as libvirt code is highly threaded I though that we should try testing it. Helgrind used to not be very practicable but Google suggest they significantly speed up the process and decreased the number of false positive. I tried to build it from source, but it failed in some ways by not finding the i386/686 libraries build when run on my x86_64, could be related to differences in distribution, they use only Ubuntu, and I tested on Fedora 16, I didn't tried to really solve the issue at that point. One of the problem of such a configuration is that the program doesn't have what could be specific Fedora exception lists for valgrind. So I grabbed the prebuilt version tsan-r4363-amd64-linux-self-contained.sh (it's a self extracting binary in shell script) from http://build.chromium.org/p/client.tsan/binaries/ renamid tsan.sh and installed it in my path, works fine... I did a first test run with libxml2 code I know very well and the result were good, i.e. it pointed out a data race I know about and raised another one about some global data initialization, so fairly positive from my POV. Then I instrumented libvirt daemon for 0.9.12 release, launched it as root from command line as a tsan argument: /tmp/tsan.sh --trace-children=no /usr/sbin/libvirtd and then played with virt-manager to exercise it a bit. At first I tried to use --log-file=tsan.log option to collect the logs but the logfile got corrupted so the following is just cut and paste from the output One of the ouput raised frequently is: ---------------------------------------------------------------------- ==5838== WARNING: Possible data race during write of size 4 at 0x34723B3BD0: {{{ ==5838== T1 (L{L17, L125}): ==5838== #0 ptmalloc_unlock_all2 /lib64/libc-2.14.90.so ==5838== #1 fork /lib64/libc-2.14.90.so ==5838== #2 virFork /usr/src/debug/libvirt-0.9.12/src/util/command.c:268 ==5838== #3 virExecWithHook.constprop.5 /usr/src/debug/libvirt-0.9.12/src/util/command.c:489 ==5838== #4 virCommandRunAsync /usr/src/debug/libvirt-0.9.12/src/util/command.c:2177 ==5838== #5 virCommandRun /usr/src/debug/libvirt-0.9.12/src/util/command.c:1970 ==5838== #6 qemuCapsExtractVersionInfo /usr/src/debug/libvirt-0.9.12/src/qemu/qemu_capabilities.c:1379 ==5838== #7 qemuCapsExtractVersion /usr/src/debug/libvirt-0.9.12/src/qemu/qemu_capabilities.c:1568 ==5838== #8 qemudGetVersion /usr/src/debug/libvirt-0.9.12/src/qemu/qemu_driver.c:1320 ==5838== #9 virConnectGetVersion /usr/src/debug/libvirt-0.9.12/src/libvirt.c:1640 ==5838== #10 remoteDispatchGetVersionHelper /usr/src/debug/libvirt-0.9.12/daemon/remote_dispatch.h:6862 ==5838== #11 virNetServerProgramDispatch /usr/src/debug/libvirt-0.9.12/src/rpc/virnetserverprogram.c:416 ==5838== Concurrent read(s) happened at (OR AFTER) these points: ==5838== T11 (L{}): ==5838== #0 arena_thread_freeres /lib64/libc-2.14.90.so ==5838== #1 __libc_thread_freeres /lib64/libc-2.14.90.so ==5838== #2 start_thread /lib64/libpthread-2.14.90.so ==5838== Address 0x34723B3BD0 is 0 bytes inside data symbol "list_lock" ==5838== Locks involved in this report (reporting last lock sites): {L17, L125} ==5838== L17 (0x5339B00) ==5838== #0 pthread_mutex_lock /mnt/data/build/slave/full_linux_build/build/tsan/ts_valgrind_intercepts.c:935 ==5838== #1 virFork /usr/src/debug/libvirt-0.9.12/src/util/command.c:266 ==5838== #2 virExecWithHook.constprop.5 /usr/src/debug/libvirt-0.9.12/src/util/command.c:489 ==5838== #3 virCommandRunAsync /usr/src/debug/libvirt-0.9.12/src/util/command.c:2177 ==5838== #4 virCommandRun /usr/src/debug/libvirt-0.9.12/src/util/command.c:1970 ==5838== #5 qemuCapsExtractVersionInfo /usr/src/debug/libvirt-0.9.12/src/qemu/qemu_capabilities.c:1379 ==5838== #6 qemuCapsExtractVersion /usr/src/debug/libvirt-0.9.12/src/qemu/qemu_capabilities.c:1568 ==5838== #7 qemudGetVersion /usr/src/debug/libvirt-0.9.12/src/qemu/qemu_driver.c:1320 ==5838== #8 virConnectGetVersion /usr/src/debug/libvirt-0.9.12/src/libvirt.c:1640 ==5838== #9 remoteDispatchGetVersionHelper /usr/src/debug/libvirt-0.9.12/daemon/remote_dispatch.h:6862 ==5838== #10 virNetServerProgramDispatch /usr/src/debug/libvirt-0.9.12/src/rpc/virnetserverprogram.c:416 ==5838== #11 virNetServerHandleJob /usr/src/debug/libvirt-0.9.12/src/rpc/virnetserver.c:161 ==5838== L125 (0x4C0A0A00) ==5838== #0 pthread_mutex_lock /mnt/data/build/slave/full_linux_build/build/tsan/ts_valgrind_intercepts.c:935 ==5838== #1 qemudGetVersion /usr/src/debug/libvirt-0.9.12/src/qemu/qemu_driver.c:1319 ==5838== #2 virConnectGetVersion /usr/src/debug/libvirt-0.9.12/src/libvirt.c:1640 ==5838== #3 remoteDispatchGetVersionHelper /usr/src/debug/libvirt-0.9.12/daemon/remote_dispatch.h:6862 ==5838== #4 virNetServerProgramDispatch /usr/src/debug/libvirt-0.9.12/src/rpc/virnetserverprogram.c:416 ==5838== #5 virNetServerHandleJob /usr/src/debug/libvirt-0.9.12/src/rpc/virnetserver.c:161 ==5838== #6 virThreadPoolWorker /usr/src/debug/libvirt-0.9.12/src/util/threadpool.c:144 ==5838== #7 virThreadHelper /usr/src/debug/libvirt-0.9.12/src/util/threads-pthread.c:161 ==5838== Race verifier data: 0x347207CF98,0x347215D6BB ==5838== }}} I don't know what "Race verifier data" means but it seems that we do *pid = fork(); in the main thread and that another thread is accessing without synchronization. The probram properly report that 2 locks are held at that point, the virLogLock() and qemuDriverLock() and give full stack trace on where those locks were taken. That's convenient but I could not really spot where the second thread did the access, I suspect that's somehow related to libpthread considering the minimal stack trace of the second thread T11 ... Unfortunately, it seems that each time we fork we hit one or two issue like that (which could be false positive), and tend to fill logs relatively fast :-\ I however found out a couple of issues not related to libpthread: ==5733== WARNING: Possible data race during write of size 1 at 0x34723B6B14: {{{ ==5733== T5 (L{}): ==5733== #0 Replace_memcpy /mnt/data/build/slave/full_linux_build/build/tsan/ts_replace.h:113 ==5733== #1 __GI_memcpy /mnt/data/build/slave/full_linux_build/build/tsan/ts_valgrind_intercepts.c:2359 ==5733== #2 xdrmem_getbytes /lib64/libc-2.14.90.so ==5733== #3 xdr_string /lib64/libc-2.14.90.so ==5733== #4 xdr_remote_nonnull_string /usr/src/debug/libvirt-0.9.12/daemon/../src/remote/remote_protocol.c:31 ==5733== #5 xdr_remote_nonnull_domain /usr/src/debug/libvirt-0.9.12/daemon/../src/remote/remote_protocol.c:58 ==5733== #6 xdr_remote_domain_get_info_args /usr/src/debug/libvirt-0.9.12/daemon/../src/remote/remote_protocol.c:1390 ==5733== #7 virNetMessageDecodePayload /usr/src/debug/libvirt-0.9.12/src/rpc/virnetmessage.c:382 ==5733== #8 virNetServerProgramDispatch /usr/src/debug/libvirt-0.9.12/src/rpc/virnetserverprogram.c:403 ==5733== #9 virNetServerHandleJob /usr/src/debug/libvirt-0.9.12/src/rpc/virnetserver.c:161 ==5733== #10 virThreadPoolWorker /usr/src/debug/libvirt-0.9.12/src/util/threadpool.c:144 ==5733== #11 virThreadHelper /usr/src/debug/libvirt-0.9.12/src/util/threads-pthread.c:161 ==5733== Concurrent write(s) happened at (OR AFTER) these points: ==5733== T2 (L{}): ==5733== #0 xdrmem_getbytes /lib64/libc-2.14.90.so ==5733== #1 xdr_string /lib64/libc-2.14.90.so ==5733== #2 xdr_remote_nonnull_string /usr/src/debug/libvirt-0.9.12/daemon/../src/remote/remote_protocol.c:31 ==5733== #3 xdr_remote_nonnull_domain /usr/src/debug/libvirt-0.9.12/daemon/../src/remote/remote_protocol.c:58 ==5733== #4 xdr_remote_domain_get_xml_desc_args /usr/src/debug/libvirt-0.9.12/daemon/../src/remote/remote_protocol.c:1532 ==5733== #5 virNetMessageDecodePayload /usr/src/debug/libvirt-0.9.12/src/rpc/virnetmessage.c:382 ==5733== #6 virNetServerProgramDispatch /usr/src/debug/libvirt-0.9.12/src/rpc/virnetserverprogram.c:403 ==5733== #7 virNetServerHandleJob /usr/src/debug/libvirt-0.9.12/src/rpc/virnetserver.c:161 ==5733== #8 virThreadPoolWorker /usr/src/debug/libvirt-0.9.12/src/util/threadpool.c:144 ==5733== #9 virThreadHelper /usr/src/debug/libvirt-0.9.12/src/util/threads-pthread.c:161 ==5733== Address 0x34723B6B14 is 0 bytes inside data symbol "crud.6424" ==5733== Race verifier data: 0x4A091CE,0x347212579D ==5733== }}} that one could potentially be nasty, it seems that 2 threads decoding rpc payload in parallel hit an unsynchronized write access in the xdr routine for xdr_remote_nonnull_string() . I didn't had the debuginfo for glibc installed when I ran it so I don't have the exact informations at the top of the stacks The other one raised is actually something I had initially found with the first run on libxml2 so it's relatively consistent: ==5733== WARNING: Possible data race during read of size 4 at 0x34723B10B4: {{{ ==5733== T1 (L{L173}): ==5733== #0 random_r /lib64/libc-2.14.90.so ==5733== #1 random /lib64/libc-2.14.90.so ==5733== #2 rand /lib64/libc-2.14.90.so ==5733== #3 xmlDictCreate /usr/src/debug/libxml2-2.8.0/dict.c:491 ==5733== #4 xmlInitParserCtxt /usr/src/debug/libxml2-2.8.0/parserInternals.c:1620 ==5733== #5 xmlNewParserCtxt /usr/src/debug/libxml2-2.8.0/parserInternals.c:1874 ==5733== #6 xmlCreateURLParserCtxt /usr/src/debug/libxml2-2.8.0/parser.c:13546 ==5733== #7 xmlReadFile /usr/src/debug/libxml2-2.8.0/parser.c:14713 ==5733== #8 xmlRelaxNGParse /usr/src/debug/libxml2-2.8.0/relaxng.c:7480 ==5733== #9 (no symbols) /usr/lib64/libnetcf.so.1.4.0 ==5733== #10 ncf_init /usr/lib64/libnetcf.so.1.4.0 ==5733== #11 interfaceOpenInterface /usr/src/debug/libvirt-0.9.12/src/interface/netcf_driver.c:144 ==5733== Concurrent write(s) happened at (OR AFTER) these points: ==5733== T10 (L{L156}): ==5733== #0 random_r /lib64/libc-2.14.90.so ==5733== #1 random /lib64/libc-2.14.90.so ==5733== #2 rand /lib64/libc-2.14.90.so ==5733== #3 xmlHashCreate /usr/src/debug/libxml2-2.8.0/hash.c:193 ==5733== #4 xmlRelaxNGCheckRules /usr/src/debug/libxml2-2.8.0/relaxng.c:4125 ==5733== #5 xmlRelaxNGCheckRules /usr/src/debug/libxml2-2.8.0/relaxng.c:6380 ==5733== #6 xmlRelaxNGCheckRules /usr/src/debug/libxml2-2.8.0/relaxng.c:6523 ==5733== #7 xmlRelaxNGCheckRules /usr/src/debug/libxml2-2.8.0/relaxng.c:6319 ==5733== #8 xmlRelaxNGCheckRules /usr/src/debug/libxml2-2.8.0/relaxng.c:6520 ==5733== #9 xmlRelaxNGCheckRules /usr/src/debug/libxml2-2.8.0/relaxng.c:6523 ==5733== Address 0x34723B10B4 is 20 bytes inside data symbol "randtbl" ==5733== Locks involved in this report (reporting last lock sites): {L156, L173} ==5733== L156 (0x402E790) ==5733== #0 pthread_mutex_lock /mnt/data/build/slave/full_linux_build/build/tsan/ts_valgrind_intercepts.c:935 ==5733== #1 remoteDispatchOpenHelper /usr/src/debug/libvirt-0.9.12/daemon/remote.c:683 ==5733== #2 virNetServerProgramDispatch /usr/src/debug/libvirt-0.9.12/src/rpc/virnetserverprogram.c:416 ==5733== #3 virNetServerHandleJob /usr/src/debug/libvirt-0.9.12/src/rpc/virnetserver.c:161 ==5733== #4 virThreadPoolWorker /usr/src/debug/libvirt-0.9.12/src/util/threadpool.c:144 ==5733== #5 virThreadHelper /usr/src/debug/libvirt-0.9.12/src/util/threads-pthread.c:161 ==5733== L173 (0x402F420) ==5733== #0 pthread_mutex_lock /mnt/data/build/slave/full_linux_build/build/tsan/ts_valgrind_intercepts.c:935 ==5733== #1 remoteDispatchOpenHelper /usr/src/debug/libvirt-0.9.12/daemon/remote.c:683 ==5733== #2 virNetServerProgramDispatch /usr/src/debug/libvirt-0.9.12/src/rpc/virnetserverprogram.c:416 ==5733== #3 virNetServerHandleJob /usr/src/debug/libvirt-0.9.12/src/rpc/virnetserver.c:161 ==5733== #4 virThreadPoolWorker /usr/src/debug/libvirt-0.9.12/src/util/threadpool.c:144 ==5733== #5 virThreadHelper /usr/src/debug/libvirt-0.9.12/src/util/threads-pthread.c:161 ==5733== Race verifier data: 0x347203A572,0x347203A565 ==5733== }}} I didn't know that netcf was doing Relax-NG validation on-the-fly :) and hit another in libxml2 though libvirt/netcf/libxslt/libxml2 call: ==5733== WARNING: Possible data race during read of size 4 at 0x34723B10B4: {{{ ==5733== T1 (L{L173}): ==5733== #0 random_r /lib64/libc-2.14.90.so ==5733== #1 random /lib64/libc-2.14.90.so ==5733== #2 rand /lib64/libc-2.14.90.so ==5733== #3 xmlDictCreate /usr/src/debug/libxml2-2.8.0/dict.c:491 ==5733== #4 xmlInitParserCtxt /usr/src/debug/libxml2-2.8.0/parserInternals.c:1620 ==5733== #5 xmlNewParserCtxt /usr/src/debug/libxml2-2.8.0/parserInternals.c:1874 ==5733== #6 xmlCreateURLParserCtxt /usr/src/debug/libxml2-2.8.0/parser.c:13546 ==5733== #7 xmlReadFile /usr/src/debug/libxml2-2.8.0/parser.c:14713 ==5733== #8 xmlRelaxNGParse /usr/src/debug/libxml2-2.8.0/relaxng.c:7480 ==5733== #9 (no symbols) /usr/lib64/libnetcf.so.1.4.0 ==5733== #10 ncf_init /usr/lib64/libnetcf.so.1.4.0 ==5733== #11 interfaceOpenInterface /usr/src/debug/libvirt-0.9.12/src/interface/netcf_driver.c:144 ==5733== Concurrent write(s) happened at (OR AFTER) these points: ==5733== T10 (L{L156}): ==5733== #0 random_r /lib64/libc-2.14.90.so ==5733== #1 random /lib64/libc-2.14.90.so ==5733== #2 rand /lib64/libc-2.14.90.so ==5733== #3 xmlHashCreate /usr/src/debug/libxml2-2.8.0/hash.c:193 ==5733== #4 xmlRelaxNGCheckRules /usr/src/debug/libxml2-2.8.0/relaxng.c:4125 ==5733== #5 xmlRelaxNGCheckRules /usr/src/debug/libxml2-2.8.0/relaxng.c:6380 ==5733== #6 xmlRelaxNGCheckRules /usr/src/debug/libxml2-2.8.0/relaxng.c:6523 ==5733== #7 xmlRelaxNGCheckRules /usr/src/debug/libxml2-2.8.0/relaxng.c:6319 ==5733== #8 xmlRelaxNGCheckRules /usr/src/debug/libxml2-2.8.0/relaxng.c:6520 ==5733== #9 xmlRelaxNGCheckRules /usr/src/debug/libxml2-2.8.0/relaxng.c:6523 ==5733== Address 0x34723B10B4 is 20 bytes inside data symbol "randtbl" ==5733== Locks involved in this report (reporting last lock sites): {L156, L173} Looks like another libxml2 bug calling rand, I should use rand_r() instead if available. I also ran virsh itself under tsan for a few functions, but that didn't raise any issue. So except for the parallel xdr_remote_nonnull_string() issue I don't think there is anything I can report at this point for libvirt code itself. The slowdown of tsan is acceptable, virt-manager is a clearly a bit less responsive when connecting of doing libvirt operations but it is really usable, and that's IMHO the main point of my testing, it's not hard (though it would be better if packaged for Fedora) and the results are interesting but a bit heavy since the same issue can pop-up all the time like for fork(). I guess it would be interesting to try out qemu-kvm with it though it may turn unbearably slow, but it's worth testing ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/

2 3

[libvirt] [PATCH 1/1] Assign spapr-vio address value to VIO devices without hardcode
by Li Zhang 18 May '12

18 May '12

Hardcode address will cause conflicts when there are a lot of VIO devices. This patch is to remove the harcode of the address, and assign a variable to it, which is cnt * 0x1000UL. And assign spapr-vio address to VIO devices, such as spapr-vlan and spapr-vty. Several test cases are modified. Signed-off-by: Li Zhang <zhlcindy(a)linux.vnet.ibm.com> --- src/qemu/qemu_command.c | 38 +++++++++++++++----- .../qemuxml2argv-disk-scsi-vscsi.args | 2 +- .../qemuxml2argv-pseries-basic.args | 2 +- .../qemuxml2argv-pseries-vio-user-assigned.args | 4 +-- .../qemuxml2argvdata/qemuxml2argv-pseries-vio.args | 8 ++--- 5 files changed, 37 insertions(+), 17 deletions(-) diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 3a92c70..fbff73e 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -780,14 +780,25 @@ int qemuDomainAssignSpaprVIOAddresses(virDomainDefPtr def) { int i, rc; int model; + int cnt = 0; /* Default values match QEMU. See spapr_(llan|vscsi|vty).c */ for (i = 0 ; i < def->nnets; i++) { - rc = qemuAssignSpaprVIOAddress(def, &def->nets[i]->info, - 0x1000ul); - if (rc) - return rc; + if (!def->nets[i]->model && + STREQ(def->os.arch, "ppc64") && + STREQ(def->os.machine, "pseries")) + strcpy(def->nets[i]->model, "spapr-vlan"); + if (def->nets[i]->model && + STREQ(def->nets[i]->model, "spapr-vlan")) { + cnt ++; + def->nets[i]->info.type = VIR_DOMAIN_DEVICE_ADDRESS_TYPE_SPAPRVIO; + rc = qemuAssignSpaprVIOAddress(def, &def->nets[i]->info, + cnt * 0x1000ul); + if (rc) + return rc; + } + } for (i = 0 ; i < def->ncontrollers; i++) { @@ -797,19 +808,28 @@ int qemuDomainAssignSpaprVIOAddresses(virDomainDefPtr def) model = qemuDefaultScsiControllerModel(def); if (model == VIR_DOMAIN_CONTROLLER_MODEL_SCSI_IBMVSCSI && def->controllers[i]->type == VIR_DOMAIN_CONTROLLER_TYPE_SCSI) { + cnt ++; def->controllers[i]->info.type = VIR_DOMAIN_DEVICE_ADDRESS_TYPE_SPAPRVIO; rc = qemuAssignSpaprVIOAddress(def, &def->controllers[i]->info, - 0x2000ul); + cnt * 0x1000ul); if (rc) return rc; } } for (i = 0 ; i < def->nserials; i++) { - rc = qemuAssignSpaprVIOAddress(def, &def->serials[i]->info, - 0x30000000ul); - if (rc) - return rc; + if (STREQ(def->os.arch, "ppc64") && + STREQ(def->os.machine, "pseries")) + def->serials[i]->info.type = VIR_DOMAIN_DEVICE_ADDRESS_TYPE_SPAPRVIO; + + if (def->serials[i]->info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_SPAPRVIO) { + cnt ++; + rc = qemuAssignSpaprVIOAddress(def, &def->serials[i]->info, + cnt * 0x1000ul); + if (rc) + return rc; + } + } /* No other devices are currently supported on spapr-vio */ diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-scsi-vscsi.args b/tests/qemuxml2argvdata/qemuxml2argv-disk-scsi-vscsi.args index d57159f..1feab49 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-disk-scsi-vscsi.args +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-scsi-vscsi.args @@ -1,7 +1,7 @@ LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/qemu -S -M \ pc -m 214 -smp 1 -nographic -nodefconfig -nodefaults -monitor \ unix:/tmp/test-monitor,server,nowait -no-acpi -boot c -device spapr-vscsi,id=scsi0,\ -reg=0x2000 -drive file=/dev/HostVG/QEMUGuest1,if=none,\ +reg=0x1000 -drive file=/dev/HostVG/QEMUGuest1,if=none,\ id=drive-ide0-0-0 -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 \ -drive file=/tmp/scsidisk.img,if=none,id=drive-scsi0-0-3-0 \ -device scsi-disk,bus=scsi0.0,channel=0,scsi-id=3,lun=0,drive=drive-scsi0-0-3-0,id=scsi0-0-3-0 \ diff --git a/tests/qemuxml2argvdata/qemuxml2argv-pseries-basic.args b/tests/qemuxml2argvdata/qemuxml2argv-pseries-basic.args index f9aec92..927e014 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-pseries-basic.args +++ b/tests/qemuxml2argvdata/qemuxml2argv-pseries-basic.args @@ -1 +1 @@ -LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/qemu-system-ppc64 -S -M pseries -m 512 -smp 1 -nographic -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/tmp/test-monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=readline -no-acpi -boot c -chardev pty,id=charserial0 -device spapr-vty,chardev=charserial0,reg=0x30000000 -usb +LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/qemu-system-ppc64 -S -M pseries -m 512 -smp 1 -nographic -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/tmp/test-monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=readline -no-acpi -boot c -chardev pty,id=charserial0 -device spapr-vty,chardev=charserial0,reg=0x1000 -usb diff --git a/tests/qemuxml2argvdata/qemuxml2argv-pseries-vio-user-assigned.args b/tests/qemuxml2argvdata/qemuxml2argv-pseries-vio-user-assigned.args index fad4346..8072864 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-pseries-vio-user-assigned.args +++ b/tests/qemuxml2argvdata/qemuxml2argv-pseries-vio-user-assigned.args @@ -2,11 +2,11 @@ LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/qemu-system-p -S -M pseries -m 512 -smp 1 -nographic -nodefconfig -nodefaults \ -chardev socket,id=charmonitor,path=/tmp/test-monitor,server,nowait \ -mon chardev=charmonitor,id=monitor,mode=readline -no-acpi -boot c \ --device spapr-vscsi,id=scsi0,reg=0x2000 \ +-device spapr-vscsi,id=scsi0,reg=0x1000 \ -device spapr-vscsi,id=scsi1,reg=0x30000000 \ -drive file=/tmp/scsidisk.img,if=none,id=drive-scsi1-0-0-0 \ -device scsi-disk,bus=scsi1.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi1-0-0-0,id=scsi1-0-0-0 \ -chardev pty,id=charserial0 \ -device spapr-vty,chardev=charserial0,reg=0x20000000 \ -chardev pty,id=charserial1 \ --device spapr-vty,chardev=charserial1,reg=0x30001000 -usb +-device spapr-vty,chardev=charserial1,reg=0x4000 -usb diff --git a/tests/qemuxml2argvdata/qemuxml2argv-pseries-vio.args b/tests/qemuxml2argvdata/qemuxml2argv-pseries-vio.args index a75b428..458a1fe 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-pseries-vio.args +++ b/tests/qemuxml2argvdata/qemuxml2argv-pseries-vio.args @@ -2,11 +2,11 @@ LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/qemu-system-p -S -M pseries -m 512 -smp 1 -nographic -nodefconfig -nodefaults \ -chardev socket,id=charmonitor,path=/tmp/test-monitor,server,nowait \ -mon chardev=charmonitor,id=monitor,mode=readline -no-acpi -boot c \ --device spapr-vscsi,id=scsi0,reg=0x2000 \ --device spapr-vscsi,id=scsi1,reg=0x3000 \ +-device spapr-vscsi,id=scsi0,reg=0x1000 \ +-device spapr-vscsi,id=scsi1,reg=0x2000 \ -drive file=/tmp/scsidisk.img,if=none,id=drive-scsi1-0-0-0 \ -device scsi-disk,bus=scsi1.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi1-0-0-0,id=scsi1-0-0-0 \ -chardev pty,id=charserial0 \ --device spapr-vty,chardev=charserial0,reg=0x30000000 \ +-device spapr-vty,chardev=charserial0,reg=0x3000 \ -chardev pty,id=charserial1 \ --device spapr-vty,chardev=charserial1,reg=0x30001000 -usb +-device spapr-vty,chardev=charserial1,reg=0x4000 -usb -- 1.7.9.5

2 2

[libvirt] [PATCH 1/1] Fix cpu check for ppc64
by Li Zhang 18 May '12

18 May '12

ppc64 pseries architecture requires that the cpus be numbered in a certain way. According to SMT, if SMT equals 4, 0-3 on core 0, 4-7 on core 1 and so on. So, depending on how guest topology has been specified, one cannot assume that the vcpus will be numbered 0-N. For example, for smp=2, core=2, threads=1, the two cpus will be 0 and 4 - one HW thread on each core. libvirt needs to take into account. Signed-off-by: Dipankar <dipankar(a)in.ibm.com> Signed-off-by: Li Zhang <zhlcindy(a)linux.vnet.ibm.com> --- src/qemu/qemu_monitor_json.c | 7 ------- 1 file changed, 7 deletions(-) diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c index e1f5453..aee5265 100644 --- a/src/qemu/qemu_monitor_json.c +++ b/src/qemu/qemu_monitor_json.c @@ -1231,13 +1231,6 @@ qemuMonitorJSONExtractCPUInfo(virJSONValuePtr reply, goto cleanup; } - if (cpu != i) { - qemuReportError(VIR_ERR_INTERNAL_ERROR, - _("unexpected cpu index %d expecting %d"), - i, cpu); - goto cleanup; - } - threads[i] = thread; } -- 1.7.9.5

3 3

[libvirt] [PATCHv4 1/2] Add a new param 'vcpu_time' to virDomainGetCPUStats
by Hu Tao 18 May '12

18 May '12

Currently virDomainGetCPUStats gets total cpu usage, which consists of: 1. vcpu usage: the physical cpu time consumed by virtual cpu(s) of domain 2. hypervisor: `total cpu usage' - `vcpu usage' The param 'vcpu_time' is for getting vcpu usages. --- include/libvirt/libvirt.h.in | 6 ++++++ tools/virsh.c | 14 ++++++++------ 2 files changed, 14 insertions(+), 6 deletions(-) diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in index ac5df95..2449cee 100644 --- a/include/libvirt/libvirt.h.in +++ b/include/libvirt/libvirt.h.in @@ -1355,6 +1355,12 @@ int virDomainGetState (virDomainPtr domain, */ #define VIR_DOMAIN_CPU_STATS_SYSTEMTIME "system_time" +/** + * VIR_DOMAIN_CPU_STATS_VCPUTIME: + * vcpu usage in nanoseconds, as a ullong + */ +#define VIR_DOMAIN_CPU_STATS_VCPUTIME "vcpu_time" + int virDomainGetCPUStats(virDomainPtr domain, virTypedParameterPtr params, unsigned int nparams, diff --git a/tools/virsh.c b/tools/virsh.c index dd9292a..b9d05a2 100644 --- a/tools/virsh.c +++ b/tools/virsh.c @@ -5572,6 +5572,7 @@ cmdCPUStats(vshControl *ctl, const vshCmd *cmd) virTypedParameterPtr params = NULL; int i, j, pos, max_id, cpu = -1, show_count = -1, nparams; bool show_total = false, show_per_cpu = false; + unsigned int flags = 0; if (!vshConnectionUsability(ctl, ctl->conn)) return false; @@ -5599,13 +5600,13 @@ cmdCPUStats(vshControl *ctl, const vshCmd *cmd) cpu = 0; /* get number of cpus on the node */ - if ((max_id = virDomainGetCPUStats(dom, NULL, 0, 0, 0, 0)) < 0) + if ((max_id = virDomainGetCPUStats(dom, NULL, 0, 0, 0, flags)) < 0) goto failed_stats; if (show_count < 0 || show_count > max_id) show_count = max_id; /* get percpu information */ - if ((nparams = virDomainGetCPUStats(dom, NULL, 0, 0, 1, 0)) < 0) + if ((nparams = virDomainGetCPUStats(dom, NULL, 0, 0, 1, flags)) < 0) goto failed_stats; if (!nparams) { @@ -5619,7 +5620,7 @@ cmdCPUStats(vshControl *ctl, const vshCmd *cmd) while (show_count) { int ncpus = MIN(show_count, 128); - if (virDomainGetCPUStats(dom, params, nparams, cpu, ncpus, 0) < 0) + if (virDomainGetCPUStats(dom, params, nparams, cpu, ncpus, flags) < 0) goto failed_stats; for (i = 0; i < ncpus; i++) { @@ -5630,7 +5631,8 @@ cmdCPUStats(vshControl *ctl, const vshCmd *cmd) for (j = 0; j < nparams; j++) { pos = i * nparams + j; vshPrint(ctl, "\t%-12s ", params[pos].field); - if (STREQ(params[pos].field, VIR_DOMAIN_CPU_STATS_CPUTIME) && + if ((STREQ(params[pos].field, VIR_DOMAIN_CPU_STATS_CPUTIME) || + STREQ(params[pos].field, VIR_DOMAIN_CPU_STATS_CPUTIME)) && params[j].type == VIR_TYPED_PARAM_ULLONG) { vshPrint(ctl, "%9lld.%09lld seconds\n", params[pos].value.ul / 1000000000, @@ -5653,7 +5655,7 @@ do_show_total: goto cleanup; /* get supported num of parameter for total statistics */ - if ((nparams = virDomainGetCPUStats(dom, NULL, 0, -1, 1, 0)) < 0) + if ((nparams = virDomainGetCPUStats(dom, NULL, 0, -1, 1, flags)) < 0) goto failed_stats; if (!nparams) { @@ -5665,7 +5667,7 @@ do_show_total: goto failed_params; /* passing start_cpu == -1 gives us domain's total status */ - if ((nparams = virDomainGetCPUStats(dom, params, nparams, -1, 1, 0)) < 0) + if ((nparams = virDomainGetCPUStats(dom, params, nparams, -1, 1, flags)) < 0) goto failed_stats; vshPrint(ctl, _("Total:\n")); -- 1.7.4.4

2 3

[libvirt] live migration copy-storage-all , inc
by Pankaj Rawat 18 May '12

18 May '12

Hi all, I am currently doing live migration task KVM/qemu based virtual machine I want to know what is exact difference between following: copy-storage-all option and copy-storage-inc option what are necessary steps for doing both? as per my knowledge 'copy-stoarage -all' migrates whole disk image to destination where 'copy-storage-inc' is when we use backing files for guest . with copy-storage-inc we require backing image on both destination and source but I want to know how destination guest get its base image how they share base image? Is there any link need to be created for this base image? or is there need for NFS ? How to set up both options ? what are necessary steps need to follow before starting migration ? Please help me! Regards Pankaj Rawat DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or NECHCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of NECHCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. . -----------------------------------------------------------------------------------------------------------------------

2 1

[libvirt] ANNOUNCE: libvirt 0.9.11.3 maintenance release
by Cole Robinson 18 May '12

18 May '12

libvirt 0.9.11.3 maintenance release is now available (actually, available since April 27 but I neglected to send this mail). This is libvirt 0.9.11 with additional bugfixes that have accumulated upstream since the initial release. This release can be downloaded at: http://libvirt.org/sources/stable_updates/libvirt-0.9.11.3.tar.gz List of changes since libvirt-0.9.11.2: * Stable release 0.9.11.3 * python: Fix doc directory name for stable releases * docs: Serialize running apibuild.py * configure: Use ustar format for dist tarball * qemu: improve errors related to offline domains * nwfilter: address more coverity findings * nwfilter: address coverity findings * util: fix error messages in virNetlinkEventServiceStart For info about past maintenance releases, see: http://wiki.libvirt.org/page/Maintenance_Releases Thanks, Cole

3 7

[libvirt] [PATCH] qemu: Don't delete USB device on failed qemuPrepareHostdevUSBDevices
by Michal Privoznik 18 May '12

18 May '12

If qemuPrepareHostdevUSBDevices fail it will roll back devices added to the driver list of used devices. However, if it may fail because the device is being used already. But then again - with roll back. Therefore don't try to remove a usb device manually if the function fail. Although, we want to remove the device if any operation performed afterwards fail. --- src/qemu/qemu_hotplug.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index 9b60816..dfca7e2 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -1173,8 +1173,10 @@ int qemuDomainAttachHostDevice(struct qemud_driver *driver, goto cleanup; } - if (qemuPrepareHostdevUSBDevices(driver, vm->def->name, list) < 0) + if (qemuPrepareHostdevUSBDevices(driver, vm->def->name, list) < 0) { + usb = NULL; goto cleanup; + } usbDeviceListSteal(list, usb); } -- 1.7.8.5

2 2

[libvirt] [PATCH 0/6] support to set cpu bandwidth for hypervisor threads
by Wen Congyang 17 May '12

17 May '12

Currently, we only can set cpu bandwidth for vcpu. If the hypervisor threads consume too much cpu time, it may affect the vcpu. This patchset allows the user to control the cpu bandwidth for hypervisor threads. It does not change the behavior if the cpu bandwidth for hypervisor is unlimited. Wen Congyang (6): Introduce the function virCgroupForHypervisor introduce the function virCgroupMoveTask() create a new cgroup and move all hypervisor threads to the new cgroup Update XML Schema for new entries qemu: Implement hypervisor's period and quota tunable XML configuration and parsing qemu: Implement hypervisor_period and hypervisor_quota's modification docs/schemas/domaincommon.rng | 10 ++ include/libvirt/libvirt.h.in | 16 +++ src/conf/domain_conf.c | 25 +++++- src/conf/domain_conf.h | 2 + src/libvirt_private.syms | 1 + src/qemu/qemu_cgroup.c | 94 +++++++++++++++-- src/qemu/qemu_cgroup.h | 2 + src/qemu/qemu_driver.c | 220 +++++++++++++++++++++++++++++++++++----- src/qemu/qemu_process.c | 4 + src/util/cgroup.c | 97 ++++++++++++++++++ src/util/cgroup.h | 6 + 11 files changed, 436 insertions(+), 41 deletions(-)

3 19

Re: [libvirt] libvirt chowning my kernel/initrd files
by Seth Jennings 17 May '12

17 May '12

On Wed, May 16, 2012 at 2:31 PM, Eric Blake <eblake(a)redhat.com> wrote: > On 05/16/2012 11:19 AM, Seth Jennings wrote: >> On Wed, May 16, 2012 at 12:06 PM, Eric Blake <eblake(a)redhat.com> wrote: >>> On 05/16/2012 10:30 AM, Seth Jennings wrote: > Did you mean for this replay to go to the list? Yes I did :-/ Back on the list. > You might also want to play with dynamic_ownership in > /etc/libvirt/qemu.conf, which changes whether libvirtd will chown in the > first place. That does the trick. Although, without dynamic_ownership, libvirt-qemu doesn't have write access to the LV I'm using as a virtio disk. So I guess it's a two edged sword. However, manually adding the libvirt-qemu user to the disk group fixed that. Might be a little coarse security-wise, but I don't feel like writing new udev rules for the device mapper today. <snip> > At least read access is required, for the uid that qemu will be running > as. If the file permissions _already_ grants read access, and libvirt > isn't recognizing that fact but doing the chown anyways, then that would > be something worth cleaning up. That is the case; it is chowning things even if it has the access required. Additionally, at least in Ubuntu 12.04, it does _not_ restore the original ownership. The initial chown when the VM starts is to libvirt-qemu:kvm, and once the VM shuts down, the ownership switches to root:root, regardless of the original ownership. Honestly, this could be used for privilege escalation of sorts. If I was a member of the libvirtd group, I could target a file owned by another user by making it the kernel for a VM and starting it. Of course, the VM wouldn't boot (unless the target file was actually a kernel image), but I would have successfully chowned that file to root:root using libvirtd, which runs a root, to do it. The user that originally owned the file would no longer be the owner. Thanks, Seth

1 0