- Devel - libvirt List Archives

[libvirt] [PATCH RFC] build: fix build with libselinux 2.3
by Jim Fehlig 28 May '14

28 May '14

The attached patch is an attempt to fix recent build failures I've noticed with libselinux 2.3 CC securityselinuxhelper.lo securityselinuxhelper.c:159:5: error: conflicting types for 'setcon_raw' int setcon_raw(security_context_t context) ^ In file included from securityselinuxhelper.c:30:0: /usr/include/selinux/selinux.h:41:12: note: previous declaration of 'setcon_raw' was here extern int setcon_raw(const char * con); ^ securityselinuxhelper.c:168:5: error: conflicting types for 'setcon' int setcon(security_context_t context) ^ In file included from securityselinuxhelper.c:30:0: /usr/include/selinux/selinux.h:40:12: note: previous declaration of 'setcon' was here extern int setcon(const char * con); ^ securityselinuxhelper.c:174:5: error: conflicting types for 'setfilecon_raw' int setfilecon_raw(const char *path, security_context_t con) ^ In file included from securityselinuxhelper.c:30:0: /usr/include/selinux/selinux.h:110:12: note: previous declaration of 'setfilecon_raw' was here extern int setfilecon_raw(const char *path, const char * con); ^ securityselinuxhelper.c:185:5: error: conflicting types for 'setfilecon' int setfilecon(const char *path, security_context_t con) ^ In file included from securityselinuxhelper.c:30:0: /usr/include/selinux/selinux.h:109:12: note: previous declaration of 'setfilecon' was here extern int setfilecon(const char *path, const char * con); ^ Noticing that security_context_t changed to 'const char *', my first thought was to use AC_CHECK_TYPE to check for security_conext_t, but alas the typedef remains in 2.3 with the comment "No longer used; here for compatibility with legacy callers". I then pursued the approach in this patch of defining a config var based on 'pkg-config --modversion', which works in a test script, but not in the context of the LIBVIRT_CHECK_SELINUX macro. Probably due to some missed quoting, but I'm reaching the m4 knowledge barrier. Before attempting to bypass that, I'd like to see what others think of this approach. Is there a simpler solution? Regards, Jim

2 2

[libvirt] [PATCH] util: fix virTimeLocalOffsetFromUTC DST processing
by Laine Stump 28 May '14

28 May '14

The original version of virTimeLocalOffsetFromUTC() (commit 1cddaea7aeca441b733c31990a3f139dd2d346f6) would fail for certain times of the day if daylight savings time was active. This could most easily be seen by uncommenting the TEST_LOCALOFFSET() cases that invlude a DST setting. After a lot of experimenting, I found that the way to solve it in almost all test cases is to set tm_isdst = -1 in the stuct tm prior to calling mktime(). Once this is done, the correct offset is returned for all test cases at all times except the two hours just after 00:00:00 Jan 1 UTC - during that time, any timezone that is *behind* UTC, and that is supposed to always be in DST will not have DST accounted for in its offset. I still do not know the source of this problem, but it appears to be either a bug in glibc, or my improper specification of a TZ setting, so I am leaving the offending tests listed in virtimetest.c, but disabling them for now. --- See https://www.redhat.com/archives/libvir-list/2014-May/msg00898.html for my earlier comments on this problem. src/util/virtime.c | 3 +++ tests/virtimetest.c | 24 +++++++++++++++++------- 2 files changed, 20 insertions(+), 7 deletions(-) diff --git a/src/util/virtime.c b/src/util/virtime.c index 3a56400..c69dff1 100644 --- a/src/util/virtime.c +++ b/src/util/virtime.c @@ -377,6 +377,9 @@ virTimeLocalOffsetFromUTC(long *offset) return -1; } + /* tell mktime to figure out itself whether or not DST is in effect */ + gmtimeinfo.tm_isdst = -1; + /* mktime() also obeys current timezone rules */ if ((utc = mktime(&gmtimeinfo)) == (time_t)-1) { virReportSystemError(errno, "%s", diff --git a/tests/virtimetest.c b/tests/virtimetest.c index bf27682..35551ea 100644 --- a/tests/virtimetest.c +++ b/tests/virtimetest.c @@ -161,20 +161,30 @@ mymain(void) TEST_LOCALOFFSET("VIR00:30", -30 * 60); TEST_LOCALOFFSET("VIR01:30", -90 * 60); + TEST_LOCALOFFSET("VIR05:00", (-5 * 60) * 60); TEST_LOCALOFFSET("UTC", 0); TEST_LOCALOFFSET("VIR-00:30", 30 * 60); TEST_LOCALOFFSET("VIR-01:30", 90 * 60); -#if __TEST_DST + /* test DST processing with timezones that always * have DST in effect; what's more, cover a zone with * with an unusual DST different than a usual one hour */ - /* NB: These tests fail at certain times of the day, so - * must be disabled until we figure out why - */ - TEST_LOCALOFFSET("VIR-00:30VID,0,365", 90 * 60); - TEST_LOCALOFFSET("VIR-02:30VID,0,365", 210 * 60); - TEST_LOCALOFFSET("VIR-02:30VID-04:30,0,365", 270 * 60); + TEST_LOCALOFFSET("VIR-00:30VID,0/00:00:00,366/23:59:59", + ((1 * 60) + 30) * 60); + TEST_LOCALOFFSET("VIR-02:30VID,0/00:00:00,366/23:59:59", + ((3 * 60) + 30) * 60); + TEST_LOCALOFFSET("VIR-02:30VID-04:30,0/00:00:00,366/23:59:59", + ((4 * 60) + 30) * 60); + TEST_LOCALOFFSET("VIR-12:00VID-13:00,0/00:00:00,366/23:59:59", + ((13 * 60) + 0) * 60); +#ifdef __BROKEN_DST_TESTS + TEST_LOCALOFFSET("VIR02:45VID00:45,0/00:00:00,366/23:59:59", + -45 * 60); + TEST_LOCALOFFSET("VIR05:00VID04:00,0/00:00:00,366/23:59:59", + ((-4 * 60) + 0) * 60); + TEST_LOCALOFFSET("VIR11:00VID10:00,0/00:00:00,366/23:59:59", + ((-10 * 60) + 0) * 60); #endif return ret == 0 ? EXIT_SUCCESS : EXIT_FAILURE; -- 1.9.3

2 2

[libvirt] Python setBlkioParameters function broken
by Qiang Guan 27 May '14

27 May '14

I've tried to use domain.setBlkioParameters with ipython, and I'm finding it's throwing the mysterious error: ubuntu@host-192-168-0-7:~$ dpkg -l | grep libvirt ii libvirt-bin 1.2.2-0ubuntu13.1 amd64 programs for the libvirt library ii libvirt0 1.2.2-0ubuntu13.1 amd64 library for interfacing with different virtualization systems ii python-libvirt 1.2.2-0ubuntu1 amd64 libvirt Python bindings ubuntu@host-192-168-0-7:~$ sudo ipython ...... In [85]: doms[0] Out[85]: <libvirt.virDomain at 0x7fe688879250> In [86]: params Out[86]: {'weight': 250} In [87]: doms[0].setBlkioParameters(params, 0) libvirt: error : argument unsupported: parameter '' not supported --------------------------------------------------------------------------- libvirtError Traceback (most recent call last) <ipython-input-87-026c35502a5c> in <module>() ----> 1 doms[0].setBlkioParameters(params, 0) /usr/lib/python2.7/dist-packages/libvirt.pyc in setBlkioParameters(self, params, flags) 1961 """Change the blkio tunables """ 1962 ret = libvirtmod.virDomainSetBlkioParameters(self._o, params, flags) -> 1963 if ret == -1: raise libvirtError ('virDomainSetBlkioParameters() failed', dom=self) 1964 return ret 1965 libvirtError: argument unsupported: parameter '' not supported The libvirt debug log info are as following: 2014-05-27 08:37:27.752+0000: 7559: debug : remoteDispatchDomainSetBlkioParametersHelper:7328 : server=0x7fd81deec930 client=0x7fd81df05170 msg=0x7fd81df06eb0 rerr=0x7fd816059c80 args=0x7fd7e40009a0 ret=0x7fd7e4000910 2014-05-27 08:37:27.752+0000: 7559: debug : virObjectNew:199 : OBJECT_NEW: obj=0x7fd7e4000c60 classname=virDomain 2014-05-27 08:37:27.752+0000: 7559: debug : virObjectRef:293 : OBJECT_REF: obj=0x7fd7f80011f0 2014-05-27 08:37:27.752+0000: 7559: debug : virDomainSetBlkioParameters:3985 : dom=0x7fd7e4000c60, (VM: name=instance-00000050, uuid=f844cf42-07d1-4b73-8de7-7437bf32aab0), params=0x7fd7e4000930, nparams=1, flags=0 2014-05-27 08:37:27.752+0000: 7559: debug : virDomainSetBlkioParameters:3986 : params[""]=(uint)250 2014-05-27 08:37:27.752+0000: 7559: debug : virObjectRef:293 : OBJECT_REF: obj=0x7fd81deec300 2014-05-27 08:37:27.752+0000: 7559: debug : virAccessManagerCheckConnect:215 : manager=0x7fd81deec300(name=stack) driver=QEMU perm=0 2014-05-27 08:37:27.752+0000: 7559: debug : virAccessManagerCheckConnect:215 : manager=0x7fd81deec370(name=none) driver=QEMU perm=0 2014-05-27 08:37:27.752+0000: 7559: debug : virObjectUnref:256 : OBJECT_UNREF: obj=0x7fd81deec300 2014-05-27 08:37:27.752+0000: 7559: error : virTypedParamsValidate:97 : argument unsupported: parameter '' not supported -- ------------ Jackie Best Regards

1 0

[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