- Devel - libvirt List Archives

[libvirt] [Patch v2 0/3] use -serial for ppce500 board and add test case
by Olivia Yin 27 May '14

27 May '14

Machine name ppce500 is used to replace ppce500v2 supported by QEMU. QEMU ppce500 board uses the legacy -serial option. Test case ppce500-serial is used to verify this change. Olivia Yin (3): change machine name ppce500v2 as ppce500 qemu: Fix specifying char devs for PPC tests: add test case for -serial option for ppce500 docs/schemas/domaincommon.rng | 2 +- src/qemu/qemu_capabilities.c | 9 +++++++- tests/qemuxml2argvdata/qemuxml2argv-ppc-dtb.args | 2 +- tests/qemuxml2argvdata/qemuxml2argv-ppc-dtb.xml | 2 +- .../qemuxml2argv-ppce500-serial.args | 7 ++++++ .../qemuxml2argv-ppce500-serial.xml | 26 ++++++++++++++++++++++ tests/qemuxml2argvtest.c | 1 + tests/testutilsqemu.c | 2 +- 8 files changed, 46 insertions(+), 5 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-ppce500-serial.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-ppce500-serial.xml -- 1.8.5

2 4

[libvirt] [PATCH 0/3] use -serial for ppce500 board and add test case
by Olivia Yin 27 May '14

27 May '14

Machine name ppce500 is used to replace ppce500v2 supported by QEMU. QEMU ppce500 board uses the old style -serial options. Test case ppce500-serial is used to verify this change. Olivia Yin (3): change machine name ppce500v2 as ppce500 qemu: Fix specifying char devs for PPC tests: add test case for -serial option for ppce500 docs/schemas/domaincommon.rng | 2 +- src/qemu/qemu_capabilities.c | 10 ++++++--- tests/qemuxml2argvdata/qemuxml2argv-ppc-dtb.args | 2 +- tests/qemuxml2argvdata/qemuxml2argv-ppc-dtb.xml | 2 +- .../qemuxml2argv-ppce500-serial.args | 7 ++++++ .../qemuxml2argv-ppce500-serial.xml | 26 ++++++++++++++++++++++ tests/qemuxml2argvtest.c | 1 + tests/testutilsqemu.c | 2 +- 8 files changed, 45 insertions(+), 7 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-ppce500-serial.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-ppce500-serial.xml -- 1.8.5

5 11

[libvirt] Job Control API [RFC]
by Tucker DiNapoli 26 May '14

26 May '14

My name is Tucker DiNapoli and I am working on implementing job control for the storage driver for the google summer of code, the first step in doing this is creating and implementing a unified api for job control. Currently there are several places where various aspects of job control are implemented. The qemu and libxl drivers both contain internal implementations for job control on domain level jobs, with the qemu driver containing support for asynchronous jobs. There is also code in the libvirt.c file for running block jobs and for querying domain jobs for information. I would like for the job control api to be as independent of different drivers as possible since it will need to be used with storage drivers as well as different virtualization drivers. I imagine most of the api will revolve around a job object, and I think it's important to decide what exactly should go in this job object. This is a response from my first post on the mailing list and I think this is a good idea. >>I'd _really_ like to see a common notion of a 'job id' that EVERY job >>(whether domain-level, like migration; or block-level, like >>commit/pull/rebase; or storage-level, like your new proposed storage >>jobs) shares a common job namespace. The job id is a positive integer. >> Existing APIs will have to be retrofitted into the new job id notion; >>any action that starts a long-running job that currently returns 0 on >>success could be changed to return a positive job id; or we may need a >>new API that queries the notion of the 'current job' (the job most >>recently started) or even to set the 'current job' to a different job >>id. We'll need new API for querying a job by id, and to be most >>portable, we should do job reporting via virTypedParameter >>(virDomainGetJobInfo and virDomainGetBlockJobInfo are hardcoded into >>returning a struct, so they are non-extensible; virDomainGetJobStats >>almost did it right, except that the user has to call it twice, once to >>learn how large to allocate, and again to pass in pre-allocated memory - >>the ideal API would allocate the memory on a single call). Currently there are separate types for block job info and job info, if possible I would like to merge these into a common job info type, and perhaps make this a part of the job object itself. Currently (in libxl and qemu) jobs are a part of the domain struct, I think that jobs should be moved out of the domain struct instead using the idea of job ids for domains to keep track of currently running jobs. I'm still new to libvirt so it this doesn't make sense and the idea of keeping job objects attached to domains makes sense that's fine. I think at the minimum each job object should contain: the id of the thread running the job, the type of job, the job id, a condition variable to coordinate jobs, and information about the job, either as a separate job info object or as part of the job object itself. The job should also contain a reference to the domain or storage it is associated with. There are a few basic functions that should definitely be part of the api: initialize a job, free a job, start a job, end a job, abort a job and get info on a job. It would be nice to be able to suspend a job and to change the currently running job as well. That's what I can come up with, but I don't have much experience in libvirt so if there are other features that make sense they can be added as well. Finally (as far as I can think of right now) is the idea of parallel jobs. Currently the qemu driver allows some jobs to be run in parallel by allowing a job to be run asynchronously, this async job has a mask of job types associated with it that determine what types of regular jobs can be run during it. However I would like to allow an arbitrary number of jobs to be run at once (I'm not sure how useful this would be, but it seems best not to impose hard limits on things). The easiest way to deal with this is to just ignore it and put the burden of synchronizing jobs on the drivers. This is obviously a bad solution. Another way would be the way it is currently done it the qemu driver, have a mask of job types associated with each domain/storage which is updated when a job is started or ended which dictates what types of jobs can be started. Regardless of how this is done it will require support from the driver/domain/storage that each job is associated with. Tucker DINapoli

2 1

[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