- Devel - libvirt List Archives

[libvirt] [libvirt-python] Call virGetLastError from mod rather than py wrapper
by Doug Goldstein 27 Nov '13

27 Nov '13

All other code always calls the methods from the mod rather than using the python wrapper so this matches the state of all other callers. --- libvirt-override.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libvirt-override.py b/libvirt-override.py index ccfec48..87996f8 100644 --- a/libvirt-override.py +++ b/libvirt-override.py @@ -20,7 +20,7 @@ class libvirtError(Exception): # Never call virConnGetLastError(). # virGetLastError() is now thread local - err = virGetLastError() + err = libvirtmod.virGetLastError() if err is None: msg = defmsg else: -- 1.8.3.2

2 1

[libvirt] [PATCH python] Make block pull event dispatcher private
by Daniel P. Berrange 27 Nov '13

27 Nov '13

From: "Daniel P. Berrange" <berrange(a)redhat.com> The method dispatchDomainEventBlockPullCallback which is used internally to dispatch block pull events to the python application code was missing the leading '_', to denote that it was private. All other event callback helpers have a leading '_'. No application should have been using this so it is justifiable to rename it. Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- libvirt-override-virConnect.py | 2 +- libvirt-override.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/libvirt-override-virConnect.py b/libvirt-override-virConnect.py index 4ba3d30..23fadfd 100644 --- a/libvirt-override-virConnect.py +++ b/libvirt-override-virConnect.py @@ -113,7 +113,7 @@ authScheme, subject, opaque) return 0 - def dispatchDomainEventBlockPullCallback(self, dom, path, type, status, cbData): + def _dispatchDomainEventBlockPullCallback(self, dom, path, type, status, cbData): """Dispatches events to python user domain blockJob event callbacks """ try: diff --git a/libvirt-override.c b/libvirt-override.c index 4cc64b7..d3802de 100644 --- a/libvirt-override.c +++ b/libvirt-override.c @@ -5998,7 +5998,7 @@ libvirt_virConnectDomainEventBlockJobCallback(virConnectPtr conn ATTRIBUTE_UNUSE /* Call the Callback Dispatcher */ pyobj_ret = PyObject_CallMethod(pyobj_conn, - (char*)"dispatchDomainEventBlockPullCallback", + (char*)"_dispatchDomainEventBlockPullCallback", (char*)"OsiiO", pyobj_dom, path, type, status, pyobj_cbData); -- 1.8.3.1

2 1

[libvirt] [PATCH python] Don't include virDomainSnapshotRef in python API
by Daniel P. Berrange 27 Nov '13

27 Nov '13

From: "Daniel P. Berrange" <berrange(a)redhat.com> The reference counting API is for internal use only. Attempts to use it from python application code will cause havoc. Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- generator.py | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/generator.py b/generator.py index ea5b8a1..c769ed0 100755 --- a/generator.py +++ b/generator.py @@ -517,7 +517,8 @@ skip_function = ( "virNWFilterRef", "virStoragePoolRef", "virStorageVolRef", - 'virStreamRef', + "virStreamRef", + "virDomainSnapshotRef", # This functions shouldn't be called via the bindings (and even the docs # contain an explicit warning to that effect). The equivalent should be -- 1.8.3.1

2 1

[libvirt] [PATCH v2 1/2] LXC: fix the problem that libvirt lxc fail to start on latest kernel
by Gao feng 27 Nov '13

27 Nov '13

After kernel commit 5ff9d8a65ce80efb509ce4e8051394e9ed2cd942 vfs: Lock in place mounts from more privileged users, unprivileged user has no rights to move the mounts that inherited from parent mountns. we use this feature to move the /stateDir/domain-name.{dev, devpts} to the /dev/ and /dev/pts directroy of container. this commit breaks libvirt lxc. this patch changes the behavior to bind these mounts when user namespace is enabled and move these mounts when user namespace is disabled. Signed-off-by: Gao feng <gaofeng(a)cn.fujitsu.com> --- src/lxc/lxc_container.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/src/lxc/lxc_container.c b/src/lxc/lxc_container.c index 2bdf957..3d9b491 100644 --- a/src/lxc/lxc_container.c +++ b/src/lxc/lxc_container.c @@ -958,6 +958,7 @@ static int lxcContainerMountFSDev(virDomainDefPtr def, { int ret = -1; char *path = NULL; + int flags = def->idmap.nuidmap ? MS_BIND : MS_MOVE; VIR_DEBUG("Mount /dev/ stateDir=%s", stateDir); @@ -971,9 +972,10 @@ static int lxcContainerMountFSDev(virDomainDefPtr def, goto cleanup; } - VIR_DEBUG("Trying to move %s to /dev", path); + VIR_DEBUG("Trying to %s %s to /dev", def->idmap.nuidmap ? + "bind" : "move", path); - if (mount(path, "/dev", NULL, MS_MOVE, NULL) < 0) { + if (mount(path, "/dev", NULL, flags, NULL) < 0) { virReportSystemError(errno, _("Failed to mount %s on /dev"), path); @@ -992,6 +994,7 @@ static int lxcContainerMountFSDevPTS(virDomainDefPtr def, { int ret; char *path = NULL; + int flags = def->idmap.nuidmap ? MS_BIND : MS_MOVE; VIR_DEBUG("Mount /dev/pts stateDir=%s", stateDir); @@ -1007,10 +1010,10 @@ static int lxcContainerMountFSDevPTS(virDomainDefPtr def, goto cleanup; } - VIR_DEBUG("Trying to move %s to /dev/pts", path); + VIR_DEBUG("Trying to %s %s to /dev/pts", def->idmap.nuidmap ? + "bind" : "move", path); - if ((ret = mount(path, "/dev/pts", - NULL, MS_MOVE, NULL)) < 0) { + if ((ret = mount(path, "/dev/pts", NULL, flags, NULL)) < 0) { virReportSystemError(errno, _("Failed to mount %s on /dev/pts"), path); -- 1.8.3.1

2 4

Re: [libvirt] [Qemu-devel] [PATCH] virtio-rng: correct the default limit rate
by Eric Blake 27 Nov '13

27 Nov '13

[adding libvirt] On 11/26/2013 06:58 AM, Paolo Bonzini wrote: > Il 26/11/2013 14:43, Amos Kong ha scritto: >> /* Set a default rate limit of 2^47 bytes per minute or roughly 2TB/s. If >> * you have an entropy source capable of generating more entropy than this >> * and you can pass it through via virtio-rng, then hats off to you. Until >> * then, this is unlimited for all practical purposes. >> */ >> >> But the current rate is (INT64_MAX) bytes per (1 << 16) ms, it's 128,000 TB/s > > You are changing: > > * max-bytes from 2^63 to 2^47 > > * period from 65536 to 60000 > > For a user, changing only period would have no effect, the limit rate > would remain effectively infinite. Changing max-bytes would give a 7% > higher rate after your patch. > > Not a big deal, and max-bytes is easier to explain after your patch > (bytes/minute) than before (bytes/65536ms). > > Reviewed-by: Paolo Bonzini <pbonzini(a)redhat.com> > Hmm. Libvirt is already converting a user's rate of bytes/period into the qemu parameters, defaulting to 1 second as its default period. Am I correct that as long as libvirt specified both rate AND period, then this change has no impact (and that the 7% change occurs if you specify period while leaving max-bytes alone)? Or is this an ABI change where libvirt will have to be taught to be smart enough to know whether it is old qemu or new qemu to adjust how libvirt does its calculations when converting the user's rate into qemu terms? -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org

3 3

[libvirt] [PATCH v2] Pin guest to memory node on NUMA system
by Shivaprasad G Bhat 27 Nov '13

27 Nov '13

Version 2: Fixed the string formatting errors in v1. Version 1: The patch contains the fix for defect 1009880 reported at redhat bugzilla. The root cause is, ever since the subcpusets(vcpu,emulator) were introduced, the paren cpuset cannot be modified to remove the nodes that are in use by the subcpusets. The fix is to break the memory node modification into three steps as to assign new nodes into the parent first. Change the nodes in the child nodes. Then remove the old nodes on the parent node. Signed-off-by: Shivaprasad G Bhat <sbhat(a)linux.vnet.ibm.com> --- src/qemu/qemu_driver.c | 129 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 129 insertions(+) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index e8bc04d..2435b75 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -8171,7 +8171,11 @@ qemuDomainSetNumaParameters(virDomainPtr dom, } } else if (STREQ(param->field, VIR_DOMAIN_NUMA_NODESET)) { virBitmapPtr nodeset = NULL; + virBitmapPtr old_nodeset = NULL; + virBitmapPtr temp_nodeset = NULL; char *nodeset_str = NULL; + char *old_nodeset_str = NULL; + char *temp_nodeset_str = NULL; if (virBitmapParse(params[i].value.s, 0, &nodeset, @@ -8181,6 +8185,10 @@ qemuDomainSetNumaParameters(virDomainPtr dom, } if (flags & VIR_DOMAIN_AFFECT_LIVE) { + size_t j; + virCgroupPtr cgroup_vcpu = NULL; + virCgroupPtr cgroup_emulator = NULL; + if (vm->def->numatune.memory.mode != VIR_DOMAIN_NUMATUNE_MEM_STRICT) { virReportError(VIR_ERR_OPERATION_INVALID, "%s", @@ -8200,7 +8208,128 @@ qemuDomainSetNumaParameters(virDomainPtr dom, continue; } + if (virCgroupGetCpusetMems(priv->cgroup, &old_nodeset_str) < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("Failed to get current system nodeset values")); + virBitmapFree(nodeset); + VIR_FREE(nodeset_str); + ret = -1; + continue; + } + + if (virBitmapParse(old_nodeset_str, 0, &old_nodeset, + VIR_DOMAIN_CPUMASK_LEN) < 0) { + virBitmapFree(nodeset); + VIR_FREE(nodeset_str); + VIR_FREE(old_nodeset_str); + ret = -1; + continue; + } + + if ((temp_nodeset = virBitmapNewCopy(old_nodeset)) == NULL) { + virBitmapFree(nodeset); + VIR_FREE(nodeset_str); + virBitmapFree(old_nodeset); + VIR_FREE(old_nodeset_str); + ret = -1; + continue; + } + virBitmapFree(old_nodeset); + VIR_FREE(old_nodeset_str); + + for (j = 0; j < caps->host.nnumaCell; j++) { + bool result; + if (virBitmapGetBit(nodeset, j, &result) < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("Failed to get cpuset bit values")); + ret = -1; + break; + } + if (result && (virBitmapSetBit(temp_nodeset, j) < 0)) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("Failed to set temporary cpuset bit values")); + ret = -1; + break; + } + } + + if (ret) { + virBitmapFree(nodeset); + VIR_FREE(nodeset_str); + virBitmapFree(temp_nodeset); + continue; + } + + if (!(temp_nodeset_str = virBitmapFormat(temp_nodeset))) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("Failed to format nodeset")); + virBitmapFree(nodeset); + VIR_FREE(nodeset_str); + virBitmapFree(temp_nodeset); + ret = -1; + continue; + } + + if (virCgroupSetCpusetMems(priv->cgroup, temp_nodeset_str) < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("Failed to set cpuset values")); + virBitmapFree(nodeset); + VIR_FREE(nodeset_str); + virBitmapFree(temp_nodeset); + VIR_FREE(temp_nodeset_str); + ret = -1; + continue; + } + + virBitmapFree(temp_nodeset); + VIR_FREE(temp_nodeset_str); + + for (j = 0; j < priv->nvcpupids; j++) { + if (virCgroupNewVcpu(priv->cgroup, j, false, &cgroup_vcpu) < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, + _("Failed to get cpuset values for vcpu%zu"), j); + ret = -1; + break; + } + if (virCgroupSetCpusetMems(cgroup_vcpu, nodeset_str) < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, + _("Failed to set cpuset values for vcpu%zu"), j); + virCgroupFree(&cgroup_vcpu); + ret = -1; + break; + } + virCgroupFree(&cgroup_vcpu); + } + + if (ret) { + virBitmapFree(nodeset); + VIR_FREE(nodeset_str); + continue; + } + + if (virCgroupNewEmulator(priv->cgroup, false, &cgroup_emulator) < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("Failed to get cpuset values for emulator")); + virBitmapFree(nodeset); + VIR_FREE(nodeset_str); + ret = -1; + continue; + } + + if (virCgroupSetCpusetMems(cgroup_emulator, nodeset_str) < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("Failed to set cpuset values for emulator")); + virBitmapFree(nodeset); + VIR_FREE(nodeset_str); + virCgroupFree(&cgroup_emulator); + ret = -1; + continue; + } + virCgroupFree(&cgroup_emulator); + if (virCgroupSetCpusetMems(priv->cgroup, nodeset_str) < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("Failed to set cpuset")); virBitmapFree(nodeset); VIR_FREE(nodeset_str); ret = -1;

3 2

[libvirt] [libvirt-python PATCH] Make setup.py executable
by Martin Kletzander 27 Nov '13

27 Nov '13

Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com> --- setup.py | 0 1 file changed, 0 insertions(+), 0 deletions(-) mode change 100644 => 100755 setup.py diff --git a/setup.py b/setup.py old mode 100644 new mode 100755 -- 1.8.4.3

2 2

Re: [libvirt] VirtIO-SCSI disks limitation
by Osier Yang 26 Nov '13

26 Nov '13

[[ TO libvir-list ]] Hi, Daniel, I'm going to share the thread to public list for further discussion. Hope you don't mind. On 26/11/13 02:37, Daniel Erez wrote: > Hi Osier, > > It seems there's a limitation in libvirt that allows up to six disks in a > virtio-scsi controller. I.e. when sending more than six disks, libvirt > automatically creates a new controller but of type virtual LSI Logic SCSI. > Is this behavior a known issue? For narrow SCSI bus, we allow 6 disks indeed. For wide SCSI bus, we allow 15 disks (not including the controller itself on unit 7). I'm doubting if we have problem on detecting if it supports wide SCSI bus though, since as far as I see from the user cases, it's always narrow SCSI bus. > Shouldn't libvirt allow up to 256 disks > per controller or at least create a new controller of type virtio-scsi when needed? The controller model for virtio-scsi controller is lsilogic, which we can't change simply, since it might affect the existing guests. There was the similar discussion in libvir-list before [1]. But auto generation for controller is quite old, which I'm also not quite clear about. I'd like see another discussion to make it more clear whether we should do some work for upper layer app (e.g. oVirt). Basicly two points: * Should we do some changes on the maximum units for a SCSI controller, I.e. Should 7 (narrow bus) 16 (wide bus) be changed to other numbers? I'm afraid the changes could affect existing guests though. * Do we really want to put the burden on users, I.E, let them create the controller explicitly. For use cases like one wants to add many disks for a guest, they need to know whether it's narrow SCSI bus or wide SCSI bus first (which we don't expose outside), and then do the calculation to know when to create a new SCSI controller. @Daniel, am I correct on your problems? Please comments if it doesn't cover all your thoughts. [1] http://www.redhat.com/archives/libvir-list/2012-November/msg00537.html Regards, Osier > > [the issue as been discussed as part of: http://gerrit.ovirt.org/#/c/20630] > > Thanks, > Daniel > > > ----- Original Message ----- >> From: "Dave Allan" <dallan(a)redhat.com> >> To: "Daniel Erez" <derez(a)redhat.com> >> Cc: "Ayal Baron" <abaron(a)redhat.com>, "Osier Yang" <jyang(a)redhat.com>, "John Ferlan" <jferlan(a)redhat.com> >> Sent: Monday, November 25, 2013 8:19:42 PM >> Subject: Re: VirtIO-SCSI disks limitation >> >> Hi Daniel, >> >> Talk to Osier Yang and John Ferlan (cc'd). >> >> Dave >> >> >> On Mon, Nov 25, 2013 at 12:48:45PM -0500, Daniel Erez wrote: >>> Hi Dave, >>> >>> I'm an engineer at oVirt team and I'm working on VirtIO-SCSI integration. >>> I would appreciate it if you could refer me to a point of contact at >>> libvirt. >>> In specific, I need to know if there's any hardcoded limitation for the >>> number of disks per VirtIO-SCSI controller. >>> >>> Best Regards, >>> Daniel

3 2

[libvirt] [PATCH v3] sasl: Fix authentication when using PLAIN mechanism
by Christophe Fergeau 26 Nov '13

26 Nov '13

With some authentication mechanism (PLAIN for example), sasl_client_start() can return SASL_OK, which translates to virNetSASLSessionClientStart() returning VIR_NET_SASL_COMPLETE. cyrus-sasl documentation is a bit vague as to what to do in such situation, but upstream clarified this a bit in http://asg.andrew.cmu.edu/archive/message.php?mailbox=archive.cyrus-sasl&ms… When we got VIR_NET_SASL_COMPLETE after virNetSASLSessionClientStart() and if the remote also tells us that authentication is complete, then we should end the authentication procedure rather than forcing a call to virNetSASLSessionClientStep(). Without this patch, when trying to use SASL PLAIN, I get: error :authentication failed : Failed to step SASL negotiation: -1 (SASL(-1): generic failure: Unable to find a callback: 32775) This patch is based on a spice-gtk patch by Dietmar Maurer. --- Change since v2: - move the added test out of the for(;;) loop src/remote/remote_driver.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/src/remote/remote_driver.c b/src/remote/remote_driver.c index df7558b..f9fd915 100644 --- a/src/remote/remote_driver.c +++ b/src/remote/remote_driver.c @@ -4121,10 +4121,18 @@ remoteAuthSASL(virConnectPtr conn, struct private_data *priv, VIR_DEBUG("Client step result complete: %d. Data %zu bytes %p", complete, serverinlen, serverin); + /* Previous server call showed completion & sasl_client_start() told us + * we are locally complete too */ + if (complete && err == VIR_NET_SASL_COMPLETE) + goto done; + /* Loop-the-loop... - * Even if the server has completed, the client must *always* do at least one step - * in this loop to verify the server isn't lying about something. Mutual auth */ + * Even if the server has completed, the client must loop until sasl_client_start() or + * sasl_client_step() return SASL_OK to verify the server isn't lying + * about something. Mutual auth + * */ for (;;) { + restep: if ((err = virNetSASLSessionClientStep(sasl, serverin, @@ -4195,6 +4203,7 @@ remoteAuthSASL(virConnectPtr conn, struct private_data *priv, priv->is_secure = 1; } +done: VIR_DEBUG("SASL authentication complete"); virNetClientSetSASLSession(priv->client, sasl); ret = 0; -- 1.8.4.2

2 2

[libvirt] [PATCH 0/3] SASL valgrind fixes
by Christophe Fergeau 26 Nov '13

26 Nov '13

Hey, While running virsh through valgrind for some SASL tests, I triggered some leaks/invalid reads, this patch series fixes these. Christophe

3 7