May 2014 - Devel - libvirt List Archives

[libvirt] Fix an extra ' in a translated string
by Daniel Veillard 26 May '14

26 May '14

Raised by ukrainian translator Yuri Chornoivan https://fedora.transifex.com/projects/p/libvirt/translate/#uk/strings/25483… Pushed as trivial fix, Daniel diff --git a/src/storage/storage_driver.c b/src/storage/storage_driver.c index 9575344..cd6babe 100644 --- a/src/storage/storage_driver.c +++ b/src/storage/storage_driver.c @@ -2975,7 +2975,7 @@ virStorageFileReadHeader(virStorageSourcePtr src, if (!src->drv->backend->storageFileReadHeader) { virReportError(VIR_ERR_INTERNAL_ERROR, _("storage file header reading is not supported for " - "storage type %s (protocol: %s)'"), + "storage type %s (protocol: %s)"), virStorageTypeToString(src->type), virStorageNetProtocolTypeToString(src->protocol)); return -2; -- 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/

1 0

[libvirt] [PATCH] Clean up chardev sockets on QEMU shutdown
by Ján Tomko 26 May '14

26 May '14

https://bugzilla.redhat.com/show_bug.cgi?id=1088787 Clean up unix socket files for chardevs using mode='bind', like we clean up the monitor socket. They are created by QEMU on startup and not really useful after shutting it down. --- src/qemu/qemu_process.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 592e3b7..f3ec246 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -2655,6 +2655,19 @@ qemuProcessPrepareChardevDevice(virDomainDefPtr def ATTRIBUTE_UNUSED, } +static int +qemuProcessCleanupChardevDevice(virDomainDefPtr def ATTRIBUTE_UNUSED, + virDomainChrDefPtr dev, + void *opaque ATTRIBUTE_UNUSED) +{ + if (dev->source.type == VIR_DOMAIN_CHR_TYPE_UNIX && + dev->source.data.nix.listen) + unlink(dev->source.data.nix.path); + + return 0; +} + + struct qemuProcessHookData { virConnectPtr conn; virDomainObjPtr vm; @@ -4339,6 +4352,12 @@ void qemuProcessStop(virQEMUDriverPtr driver, priv->monConfig = NULL; } + ignore_value(virDomainChrDefForeach(vm->def, + false, + qemuProcessCleanupChardevDevice, + NULL)); + + /* shut it off for sure */ ignore_value(qemuProcessKill(vm, VIR_QEMU_PROCESS_KILL_FORCE| -- 1.8.3.2

2 3

[libvirt] virsh reconnect vs. keepalive issue
by Eric Blake 23 May '14

23 May '14

I'm trying to debug a new virsh command, and had two terminals up, one running './run gdb tools/virsh' (I originally ran virsh directly, but re-ran under gdb to get a trace) and the other running './run gdb daemon/libvirtd'. Because I forgot to use the -k0 argument to disable keepalives, and took too long while at a breakpoint on the libvirtd terminal, my virsh session tried to report a keepalive failure: [New Thread 0x7fffe7b8c700 (LWP 7143)] 2014-05-20 23:40:22.337+0000: 7138: info : libvirt version: 1.2.5 2014-05-20 23:40:22.337+0000: 7138: warning : virKeepAliveTimerInternal:143 : No response from client 0x55555586a520 after 6 keepalive messages in 35 seconds 2014-05-20 23:40:22.337+0000: 7143: warning : virKeepAliveTimerInternal:143 : No response from client 0x55555586a520 after 6 keepalive messages in 35 seconds error: internal error: received hangup / error event on socket but then it just hangs there. A backtrace shows that it is hanging trying to reconnect: (gdb) bt #0 0x00007ffff39129dd in poll () at ../sysdeps/unix/syscall-template.S:81 #1 0x00007ffff798e3c1 in virNetClientIOEventLoop (client=0x55555586ae10, thiscall=0x55555586b090) at rpc/virnetclient.c:1514 #2 0x00007ffff798ecbf in virNetClientIO (client=0x55555586ae10, thiscall=0x55555586b090) at rpc/virnetclient.c:1786 #3 0x00007ffff798f5ab in virNetClientSendInternal (client=0x55555586ae10, msg=0x55555586ada0, expectReply=true, nonBlock=false) at rpc/virnetclient.c:1958 #4 0x00007ffff798f648 in virNetClientSendWithReply (client=0x55555586ae10, msg=0x55555586ada0) at rpc/virnetclient.c:1986 #5 0x00007ffff7990580 in virNetClientProgramCall (prog=0x55555586afd0, client=0x55555586ae10, serial=0, proc=66, noutfds=0, outfds=0x0, ninfds=0x0, infds=0x0, args_filter=0x7ffff394f270 <__GI_xdr_void>, args=0x0, ret_filter=0x7ffff798152c <xdr_remote_auth_list_ret>, ret=0x7fffffffd6f0) at rpc/virnetclientprogram.c:329 #6 0x00007ffff7975d4c in callFull (conn=0x555555869fb0, priv=0x55555586ab30, flags=0, fdin=0x0, fdinlen=0, fdout=0x0, fdoutlen=0x0, proc_nr=66, args_filter=0x7ffff394f270 <__GI_xdr_void>, args=0x0, ret_filter=0x7ffff798152c <xdr_remote_auth_list_ret>, ret=0x7fffffffd6f0 "") at remote/remote_driver.c:6544 #7 0x00007ffff7975e25 in call (conn=0x555555869fb0, priv=0x55555586ab30, flags=0, proc_nr=66, args_filter=0x7ffff394f270 <__GI_xdr_void>, args=0x0, ret_filter=0x7ffff798152c <xdr_remote_auth_list_ret>, ---Type <return> to continue, or q <return> to quit--- ret=0x7fffffffd6f0 "") at remote/remote_driver.c:6566 #8 0x00007ffff795f7f1 in remoteAuthenticate (conn=0x555555869fb0, priv=0x55555586ab30, auth=0x7ffff7d71520 <virConnectAuthDefault>, authtype=0x0) at remote/remote_driver.c:3939 #9 0x00007ffff7957f0a in doRemoteOpen (conn=0x555555869fb0, priv=0x55555586ab30, auth=0x7ffff7d71520 <virConnectAuthDefault>, flags=0) at remote/remote_driver.c:973 #10 0x00007ffff795890b in remoteConnectOpen (conn=0x555555869fb0, auth=0x7ffff7d71520 <virConnectAuthDefault>, flags=0) at remote/remote_driver.c:1190 #11 0x00007ffff78fc5e5 in do_open (name=0x0, auth=0x7ffff7d71520 <virConnectAuthDefault>, flags=0) at libvirt.c:1147 #12 0x00007ffff78fd093 in virConnectOpenAuth (name=0x0, auth=0x7ffff7d71520 <virConnectAuthDefault>, flags=0) at libvirt.c:1390 #13 0x0000555555575a67 in vshConnect (ctl=0x7fffffffdbc0, uri=0x0, readonly=false) at virsh.c:337 #14 0x0000555555575c23 in vshReconnect (ctl=0x7fffffffdbc0) at virsh.c:383 #15 0x000055555557943a in vshCommandRun (ctl=0x7fffffffdbc0, cmd=0x5555557f4900) at virsh.c:1853 #16 0x000055555557d8de in main (argc=5, argv=0x7fffffffdda8) at virsh.c:3617 It seems odd that virsh is hanging rather than gracefully exit, because it is trying too hard to reconnect in spite of being forcefully disconnected due to a keepalive timeout. But I'm not sure what, if anything, we could tweak to make this failure mode not require a Ctrl-C on my end to get rid of the failed virsh. It also reiterates the idea that we really ought to allow for a user-specified timeout to virConnect, rather than blocking forever. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org

2 2

[libvirt] [PATCH] Explicitly pin hotplugged vcpu to all cpus
by Ján Tomko 23 May '14

23 May '14

QEMU does not join vcpu threads after vcpu hotunplug. The thread might stay pinned when we hotplug the cpu again. We were already pinning the hotplugged vcpus when a per-domain pinning was specified. Explicitly pin the hotplugged vcpu to all cpus if there is no cpuset specified in domain XML, to make sure the vcpupin stays accurate. https://bugzilla.redhat.com/show_bug.cgi?id=1099836 --- src/qemu/qemu_driver.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 6fda50d..a4fa488 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -3994,6 +3994,7 @@ static int qemuDomainHotplugVcpus(virQEMUDriverPtr driver, pid_t *cpupids = NULL; int ncpupids; virCgroupPtr cgroup_vcpu = NULL; + virBitmapPtr cpumask = NULL; qemuDomainObjEnterMonitor(driver, vm); @@ -4117,6 +4118,24 @@ static int qemuDomainHotplugVcpus(virQEMUDriverPtr driver, goto cleanup; } } + } else { + /* QEMU doesn't destroy vcpu threads on vcpu unplug. + * Pin the vcpu to all CPUs just to be sure */ + cpumask = qemuPrepareCpumap(driver, NULL); + virBitmapSetAll(cpumask); + if (cgroup_vcpu) { + if (qemuSetupCgroupEmulatorPin(cgroup_vcpu, cpumask) < 0) + goto cleanup; + } else { + if (virProcessSetAffinity(cpupids[i], cpumask) < 0) { + virReportError(VIR_ERR_SYSTEM_ERROR, + _("failed to set cpu affinity for vcpu %zu"), + i); + ret = -1; + goto cleanup; + } + } + VIR_FREE(cpumask); } virCgroupFree(&cgroup_vcpu); @@ -4145,6 +4164,7 @@ static int qemuDomainHotplugVcpus(virQEMUDriverPtr driver, cleanup: qemuDomainObjExitMonitor(driver, vm); vm->def->vcpus = vcpus; + VIR_FREE(cpumask); VIR_FREE(cpupids); virDomainAuditVcpu(vm, oldvcpus, nvcpus, "update", rc == 1); if (cgroup_vcpu) -- 1.8.3.2

2 2

[libvirt] [PATCH] Remove unsupported type sdl from error info when set 2 vnc or spice graphics
by tzheng＠redhat.com 23 May '14

23 May '14

--- src/qemu/qemu_command.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 193959f..a146463 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -8579,7 +8579,7 @@ qemuBuildCommandLine(virConnectPtr conn, if (sdl > 1 || vnc > 1 || spice > 1) { virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", _("only 1 graphics device of each type " - "(sdl, vnc, spice) is supported")); + "(vnc, spice) is supported")); goto error; } -- 1.9.3

4 5

[libvirt] [PATCH 0/3] Fix various migration issues
by Jiri Denemark 23 May '14

23 May '14

Jiri Denemark (3): Fix error message when TUNNELLED flag is used in non-p2p migration qemu: Send migrate_cancel when aborting migration qemu: Properly abort migration to a file src/libvirt.c | 8 ++++- src/qemu/qemu_migration.c | 74 ++++++++++++++++++++++++++++++----------------- 2 files changed, 54 insertions(+), 28 deletions(-) -- 1.9.3

4 14

Re: [libvirt] [PATCH 2/3] qemu: Fix specifying char devs for PPC
by Eric Blake 23 May '14

23 May '14

[reposting to the list with permission] On 05/22/2014 06:37 PM, Hong-Hua.Yin(a)freescale.com wrote: > Hi Eric, > > Thanks for your comments. > I also prefer the second reply threading. > > Exactly I use git send-email to post patches to this mailing list. > $ git send-email 0000-cover-letter.patch 0001-change-machine-name-ppce500v2-as-ppce500.patch 0002-qemu-Fix-specifying-char-devs-for-PPC.patch 0003-tests-add-test-case-for-serial-option-for-ppce500.patch --to="libvir-list(a)redhat.com" > > > $ git config --global -l > sendemail.smtpserver=remotesmtp.freescale.net > sendemail.chainreplyto=true This is the culprit. Per 'git send-email --help', the git default of sendemail.chainreplyto=false gives the style we prefer. > sendemail.confirm=auto > > Is there any configuration for git to follow up? Depends on whether you want to change the settings for all repositories on your computer (~/.gitconfig, or 'git config --global') or just for your copy of libvirt.git (libvirt/.git/config, or plain 'git config'). We also tend to avoid top-posting on the list. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org

1 0

[libvirt] [PATCHv2] qemu: Add cmd_per_lun, max_sectors to virtio-scsi
by Mike Perez 22 May '14

22 May '14

This introduces two new attributes "cmd_per_lun" and "max_sectors" same with the names QEMU uses for virtio-scsi. An example of the XML: <controller type='scsi' index='0' model='virtio-scsi' cmd_per_lun='50' max_sectors='512'/> The corresponding QEMU command line: -device virtio-scsi-pci,id=scsi0,cmd_per_lun=50,max_sectors=512, bus=pci.0,addr=0x3 Signed-off-by: Mike Perez <thingee(a)gmail.com> --- docs/formatdomain.html.in | 29 +++++++++++++++++++--- docs/schemas/domaincommon.rng | 10 ++++++++ src/conf/domain_conf.c | 27 ++++++++++++++++++-- src/conf/domain_conf.h | 2 ++ src/qemu/qemu_command.c | 27 ++++++++++++++++---- .../qemuxml2argv-disk-virtio-scsi-cmd-per-lun.args | 9 +++++++ .../qemuxml2argv-disk-virtio-scsi-cmd-per-lun.xml | 29 ++++++++++++++++++++++ .../qemuxml2argv-disk-virtio-scsi-max-sectors.args | 9 +++++++ .../qemuxml2argv-disk-virtio-scsi-max-sectors.xml | 29 ++++++++++++++++++++++ tests/qemuxml2argvtest.c | 6 +++++ tests/qemuxml2xmltest.c | 2 ++ 11 files changed, 168 insertions(+), 11 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-virtio-scsi-cmd-per-lun.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-virtio-scsi-cmd-per-lun.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-virtio-scsi-max-sectors.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-virtio-scsi-max-sectors.xml diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index 691a451..8d44bc8 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -2559,11 +2559,32 @@ An optional sub-element <code>driver</code> can specify the driver - specific options. Currently it only supports attribute <code>queues</code> - (1.0.5, QEMU and KVM only), which specifies the - number of queues for the controller. For best performance, it's recommended - to specify a value matching the number of vCPUs. + specific options: + <dl> + <dt><code>queues</code></dt> + <dd> + The optional <code>queues</code> attribute specifies the number of + queues for the controller. For best performance, it's recommended to + specify a value matching the number of vCPUs. + Since 1.0.5 (QEMU and KVM only) + </dd> + <dt><code>cmd-per-lun</code></dt> + <dd> + The optional <code>cmd-per-lun</code> attribute specifies the maximum + number of commands that can be queued on devices controlled by the + host. + Since 1.2.5 (QEMU and KVM only) + </dd> + <dt><code>max-sectors</code></dt> + <dd> + The optional <code>max-sectors</code> attribute specifies the maximum + amount of data in bytes that will be transferred to or from the device + in a single command. The transfer length is measured in sectors, where + a sector is 512 bytes. + Since 1.2.5 (QEMU and KVM only) + </dd> + </dl> USB companion controllers have an optional sub-element <code><master></code> to specify the exact diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng index 4249ed5..d2ed8df 100644 --- a/docs/schemas/domaincommon.rng +++ b/docs/schemas/domaincommon.rng @@ -1735,6 +1735,16 @@ <ref name="unsignedInt"/> </attribute> </optional> + <optional> + <attribute name="cmd-per-lun"> + <ref name="unsignedInt"/> + </attribute> + </optional> + <optional> + <attribute name="max-sectors"> + <ref name="unsignedInt"/> + </attribute> + </optional> </element> </optional> </interleave> diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 40c385e..9132463 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -6041,6 +6041,8 @@ virDomainControllerDefParseXML(xmlNodePtr node, char *idx = NULL; char *model = NULL; char *queues = NULL; + char *cmd_per_lun = NULL; + char *max_sectors = NULL; xmlNodePtr saved = ctxt->node; int rc; @@ -6084,6 +6086,8 @@ virDomainControllerDefParseXML(xmlNodePtr node, if (cur->type == XML_ELEMENT_NODE) { if (xmlStrEqual(cur->name, BAD_CAST "driver")) queues = virXMLPropString(cur, "queues"); + cmd_per_lun = virXMLPropString(cur, "cmd-per-lun"); + max_sectors = virXMLPropString(cur, "max-sectors"); } cur = cur->next; } @@ -6094,6 +6098,17 @@ virDomainControllerDefParseXML(xmlNodePtr node, goto error; } + if (cmd_per_lun && virStrToLong_ui(cmd_per_lun, NULL, 10, &def->cmd_per_lun) < 0) { + virReportError(VIR_ERR_XML_ERROR, + _("Malformed 'cmd-per-lun' value '%s'"), cmd_per_lun); + goto error; + } + + if (max_sectors && virStrToLong_ui(max_sectors, NULL, 10, &def->max_sectors) < 0) { + virReportError(VIR_ERR_XML_ERROR, + _("Malformed 'max-sectors' value %s'"), max_sectors); + } + if (virDomainDeviceInfoParseXML(node, NULL, &def->info, flags) < 0) goto error; @@ -6201,6 +6216,8 @@ virDomainControllerDefParseXML(xmlNodePtr node, VIR_FREE(idx); VIR_FREE(model); VIR_FREE(queues); + VIR_FREE(cmd_per_lun); + VIR_FREE(max_sectors); return def; @@ -15279,13 +15296,19 @@ virDomainControllerDefFormat(virBufferPtr buf, break; } - if (def->queues || virDomainDeviceInfoIsSet(&def->info, flags) || - pcihole64) { + if (def->queues || def->cmd_per_lun || def->max_sectors || + virDomainDeviceInfoIsSet(&def->info, flags) || pcihole64) { virBufferAddLit(buf, ">\n"); virBufferAdjustIndent(buf, 2); if (def->queues) virBufferAsprintf(buf, "<driver queues='%u'/>\n", def->queues); + if (def->cmd_per_lun) + virBufferAsprintf(buf, "<driver cmd-per-lun='%u'/>\n", def->cmd_per_lun); + + if (def->max_sectors) + virBufferAsprintf(buf, "<driver max-sectors='%u'/>\n", def->max_sectors); + if (virDomainDeviceInfoIsSet(&def->info, flags) && virDomainDeviceInfoFormat(buf, &def->info, flags) < 0) return -1; diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h index bde303c..66484a1 100644 --- a/src/conf/domain_conf.h +++ b/src/conf/domain_conf.h @@ -720,6 +720,8 @@ struct _virDomainControllerDef { unsigned int idx; int model; /* -1 == undef */ unsigned int queues; + unsigned int cmd_per_lun; + unsigned int max_sectors; union { virDomainVirtioSerialOpts vioserial; virDomainPCIControllerOpts pciopts; diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 193959f..da4543b 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -4236,12 +4236,23 @@ qemuBuildControllerDevStr(virDomainDefPtr domainDef, virBuffer buf = VIR_BUFFER_INITIALIZER; int model; - if (def->queues && - !(def->type == VIR_DOMAIN_CONTROLLER_TYPE_SCSI && + if (!(def->type == VIR_DOMAIN_CONTROLLER_TYPE_SCSI && def->model == VIR_DOMAIN_CONTROLLER_MODEL_SCSI_VIRTIO_SCSI)) { - virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", - _("'queues' is only supported by virtio-scsi controller")); - return NULL; + if (def->queues) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("'queues' is only supported by virtio-scsi controller")); + return NULL; + } + if (def->cmd_per_lun) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("'cmd-per-lun' is only supported by virtio-scsi controller")); + return NULL; + } + if (def->max_sectors) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("'max-sectors' is only supported by virtio-scsi controller")); + return NULL; + } } switch (def->type) { @@ -4369,6 +4380,12 @@ qemuBuildControllerDevStr(virDomainDefPtr domainDef, if (def->queues) virBufferAsprintf(&buf, ",num_queues=%u", def->queues); + if (def->cmd_per_lun) + virBufferAsprintf(&buf, ",cmd_per_lun=%u", def->cmd_per_lun); + + if (def->max_sectors) + virBufferAsprintf(&buf, ",max_sectors=%u", def->max_sectors); + if (qemuBuildDeviceAddressStr(&buf, domainDef, &def->info, qemuCaps) < 0) goto error; diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-virtio-scsi-cmd-per-lun.args b/tests/qemuxml2argvdata/qemuxml2argv-disk-virtio-scsi-cmd-per-lun.args new file mode 100644 index 0000000..2c75790 --- /dev/null +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-virtio-scsi-cmd-per-lun.args @@ -0,0 +1,9 @@ +LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test QEMU_AUDIO_DRV=none \ +/usr/bin/qemu -S -M pc -m 214 -smp 8 -nographic -nodefconfig -nodefaults \ +-monitor unix:/tmp/test-monitor,server,nowait -no-acpi -boot c \ +-device virtio-scsi-pci,id=scsi0,cmd_per_lun=50,bus=pci.0,addr=0x3 \ +-usb \ +-drive file=/dev/HostVG/QEMUGuest1,if=none,id=drive-scsi0-0-0-0 \ +-device scsi-disk,bus=scsi0.0,channel=0,scsi-id=0,lun=0,\ +drive=drive-scsi0-0-0-0,id=scsi0-0-0-0 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-virtio-scsi-cmd-per-lun.xml b/tests/qemuxml2argvdata/qemuxml2argv-disk-virtio-scsi-cmd-per-lun.xml new file mode 100644 index 0000000..e35603a --- /dev/null +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-virtio-scsi-cmd-per-lun.xml @@ -0,0 +1,29 @@ +<domain type='qemu'> + <name>QEMUGuest1</name> + <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid> + <memory unit='KiB'>219136</memory> + <currentMemory unit='KiB'>219136</currentMemory> + <vcpu placement='static'>8</vcpu> + <os> + <type arch='i686' machine='pc'>hvm</type> + <boot dev='hd'/> + </os> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <emulator>/usr/bin/qemu</emulator> + <disk type='block' device='disk'> + <source dev='/dev/HostVG/QEMUGuest1'/> + <target dev='sdb' bus='scsi'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <controller type='usb' index='0'/> + <controller type='scsi' index='0' model='virtio-scsi'> + <driver cmd-per-lun='50'/> + </controller> + <controller type='pci' index='0' model='pci-root'/> + <memballoon model='virtio'/> + </devices> +</domain> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-virtio-scsi-max-sectors.args b/tests/qemuxml2argvdata/qemuxml2argv-disk-virtio-scsi-max-sectors.args new file mode 100644 index 0000000..895f379 --- /dev/null +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-virtio-scsi-max-sectors.args @@ -0,0 +1,9 @@ +LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test QEMU_AUDIO_DRV=none \ +/usr/bin/qemu -S -M pc -m 214 -smp 8 -nographic -nodefconfig -nodefaults \ +-monitor unix:/tmp/test-monitor,server,nowait -no-acpi -boot c \ +-device virtio-scsi-pci,id=scsi0,max_sectors=512,bus=pci.0,addr=0x3 \ +-usb \ +-drive file=/dev/HostVG/QEMUGuest1,if=none,id=drive-scsi0-0-0-0 \ +-device scsi-disk,bus=scsi0.0,channel=0,scsi-id=0,lun=0,\ +drive=drive-scsi0-0-0-0,id=scsi0-0-0-0 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-virtio-scsi-max-sectors.xml b/tests/qemuxml2argvdata/qemuxml2argv-disk-virtio-scsi-max-sectors.xml new file mode 100644 index 0000000..0ad94fc --- /dev/null +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-virtio-scsi-max-sectors.xml @@ -0,0 +1,29 @@ +<domain type='qemu'> + <name>QEMUGuest1</name> + <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid> + <memory unit='KiB'>219136</memory> + <currentMemory unit='KiB'>219136</currentMemory> + <vcpu placement='static'>8</vcpu> + <os> + <type arch='i686' machine='pc'>hvm</type> + <boot dev='hd'/> + </os> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <emulator>/usr/bin/qemu</emulator> + <disk type='block' device='disk'> + <source dev='/dev/HostVG/QEMUGuest1'/> + <target dev='sdb' bus='scsi'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <controller type='usb' index='0'/> + <controller type='scsi' index='0' model='virtio-scsi'> + <driver max-sectors='512'/> + </controller> + <controller type='pci' index='0' model='pci-root'/> + <memballoon model='virtio'/> + </devices> +</domain> diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c index 1ea7bf8..6f4e14b 100644 --- a/tests/qemuxml2argvtest.c +++ b/tests/qemuxml2argvtest.c @@ -807,6 +807,12 @@ mymain(void) DO_TEST("disk-virtio-scsi-num_queues", QEMU_CAPS_DRIVE, QEMU_CAPS_DEVICE, QEMU_CAPS_NODEFCONFIG, QEMU_CAPS_VIRTIO_SCSI); + DO_TEST("disk-virtio-scsi-cmd-per-lun", + QEMU_CAPS_DRIVE, QEMU_CAPS_DEVICE, QEMU_CAPS_NODEFCONFIG, + QEMU_CAPS_VIRTIO_SCSI); + DO_TEST("disk-virtio-scsi-max-sectors", + QEMU_CAPS_DRIVE, QEMU_CAPS_DEVICE, QEMU_CAPS_NODEFCONFIG, + QEMU_CAPS_VIRTIO_SCSI); DO_TEST("disk-scsi-megasas", QEMU_CAPS_DRIVE, QEMU_CAPS_DEVICE, QEMU_CAPS_NODEFCONFIG, QEMU_CAPS_SCSI_MEGASAS); diff --git a/tests/qemuxml2xmltest.c b/tests/qemuxml2xmltest.c index da528da..a17e432 100644 --- a/tests/qemuxml2xmltest.c +++ b/tests/qemuxml2xmltest.c @@ -223,6 +223,8 @@ mymain(void) DO_TEST("disk-scsi-vscsi"); DO_TEST("disk-scsi-virtio-scsi"); DO_TEST("disk-virtio-scsi-num_queues"); + DO_TEST("disk-virtio-scsi-cmd-per-lun"); + DO_TEST("disk-virtio-scsi-max-sectors"); DO_TEST("disk-scsi-megasas"); DO_TEST_FULL("disk-mirror", false, WHEN_ACTIVE); DO_TEST_FULL("disk-mirror", true, WHEN_INACTIVE); -- 1.9.1

1 0

[libvirt] [PATCH] conf: fix backing store parse off-by-one
by Eric Blake 22 May '14

22 May '14

Commit 546154e parses the type attribute from a <backingStore> element, but forgot that the earlier commit 9673418 added a placeholder element in the same 1.2.3 release; as a result, the C code was mistakenly allowing "none" as a type. Similarly, the same commit allows "none" as the <format> sub-element type, even though that has been a placeholder since the 0.10.2 release with commit f772b3d. * src/conf/domain_conf.c (virDomainDiskBackingStoreParse): Require non-zero types. Signed-off-by: Eric Blake <eblake(a)redhat.com> --- Maybe worth addressing in a later patch: the RelaxNG grammar currently requires a <format> and <backingStore> subelement to any non-empty <backingStore>, and the C code matches this requirement. However, we should probably make both of them optional, to represent the case where the user is requesting that we perform a probe to complete the backing chain details. --- src/conf/domain_conf.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 055b979..40c385e 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -5110,7 +5110,7 @@ virDomainDiskBackingStoreParse(xmlXPathContextPtr ctxt, } backingStore->type = virStorageTypeFromString(type); - if (backingStore->type < 0) { + if (backingStore->type <= 0) { virReportError(VIR_ERR_CONFIG_UNSUPPORTED, _("unknown disk backing store type '%s'"), type); goto cleanup; @@ -5123,7 +5123,7 @@ virDomainDiskBackingStoreParse(xmlXPathContextPtr ctxt, } backingStore->format = virStorageFileFormatTypeFromString(format); - if (backingStore->format < 0) { + if (backingStore->format <= 0) { virReportError(VIR_ERR_CONFIG_UNSUPPORTED, _("unknown disk backing store format '%s'"), format); goto cleanup; -- 1.7.1

2 2

[libvirt] RFC: Any interest in a weekly(?) dev community meeting ?
by Daniel P. Berrange 22 May '14

22 May '14

Hi Libvirt team, A number of opensource projects have weekly meetings between their community of contributors to facilitate their day-to-day working and particularly to resolve roadblocks that people are having. I feel that libvirt is large enough, with contributors from many different organizations, that a meeting could be beneficial to our operation. This could serve a number of purposes - Remind us of patches that have been posted and accidentally forgotten by reviewers - Resolve hard debates that are not making adequate progress on the mailing list(s) - Track progress of major ongoing pieces of work with many collaborators - Forum for those new to the community to introduce themselves & their ideas before starting work - Discuss release critical bugs during freeze periods - Place for downstream users of libvirt (eg openstack/ovirt/etc) to interact with libvirt team. - Place for projects we use (eg KVM, Xen) to interact with libvirt team. I like to keep the overhead of this low, so I'd suggest we try todo it on IRC, since that has been fairly effective for OpenStack teams. If people think this is worth while I'd suggest an arbitrary time of 1500 UTC using the #virt-meeting IRC channel on irc.oftc.net, to last an absolute max of 1 hour. Currently this time point works out as 08:00 San Francisco 11:00 Boston 15:00 UTC 16:00 London 17:00 Berlin 20:30 Mumbai 23:00 Bejing 24:00 Tokyo http://www.timeanddate.com/worldclock/fixedtime.html?hour=15&min=00&sec=0p1… Regards, 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 :|

4 8