November 2011 - Devel - libvirt List Archives

[libvirt] client hang in virDomainCreateXML
by Jiff Shen 03 Nov '11

03 Nov '11

Hi, We are using Ubuntu 10.04 eucalyptus 1.6.2 and libvirt 0.7.5. We found eucalyptus-nc sometimes hangs in virDomainCreateXML, and never gets response from libvirtd. After 2 days of investigation, I found there is another libvirt client connects to libvirtd 'qemu:///system', which is the same URI as eucalyptus-nc. The bug never shows after I disabled the client. My question is: 1, can I have multiple clients connect to qemu:///system? 2, is this an bug in libvirt and has it been fixed? Thanks a lot

3 2

[libvirt] sVirt support for LXC?
by Dong-In David Kang 03 Nov '11

03 Nov '11

Hello, We are at the later stage of a project. We are very much interested in sVirt support for LXC. Is there any branch that we can try? We are willing to test one. As I wrote below, we tried Daniel's branch https://gitorious.org/~berrange/libvirt/staging/commits/lxc-svirt. But we didn't have much luck. Any help? Do you have any schedule of adding sVirt support for LXC to upstream libvirt? Thanks, David. ---------------------- Dr. Dong-In "David" Kang Computer Scientist USC/ISI ----- Original Message ----- From: "Eric Blake" <eblake(a)redhat.com> To: "Dong-In David Kang" <dkang(a)isi.edu> Cc: libvir-list(a)redhat.com Sent: Wednesday, November 2, 2011 12:57:16 PM Subject: Re: [libvirt] sVirt support for LXC? On 11/02/2011 10:37 AM, Dong-In David Kang wrote: > > Hello, Replying to a random previous message, even if you change the subject line, doesn't create a new thread. Your message got buried in an existing thread, making it harder to find; in the future, it is better to start a new thread via a fresh email rather than replying to an existing mail. > > Is it planned to support sVirt for LXC? Eventually. It's a work in progress, and tracking this mailing list you will see as it improves. > I know the current libvirt does not support sVirt for LXC. > I found that a branch at https://gitorious.org/~berrange/libvirt/staging/commits/lxc-svirt seems to support sVirt for LXC. Yes, that's Daniel's staging area as he works on improving the situation. > I downloaded the tar file and overwrite libvirt-0.9.6 with the branch. Not recommended. Running a staging area patch is rather risky, and it's better to wait for it to hit upstream libvirt.git first, especially if you want support from this list. -- Eric Blake eblake(a)redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org -- libvir-list mailing list libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list ---------------------- Dr. Dong-In "David" Kang Computer Scientist USC/ISI

2 2

[libvirt] [PATCH] Remove translations in socket test case
by Daniel P. Berrange 03 Nov '11

03 Nov '11

From: "Daniel P. Berrange" <berrange(a)redhat.com> The test case errors should not be translated since they're only targetted at developers, not users. * tests/virnetsockettest.c: Remove error reporting with translations --- tests/virnetsockettest.c | 14 ++++---------- 1 files changed, 4 insertions(+), 10 deletions(-) Pushed as a build breaker fix (make syntax-check fails) diff --git a/tests/virnetsockettest.c b/tests/virnetsockettest.c index a76e5cc..16713e8 100644 --- a/tests/virnetsockettest.c +++ b/tests/virnetsockettest.c @@ -207,14 +207,11 @@ static int testSocketUNIXAccept(const void *data ATTRIBUTE_UNUSED) tmpdir = mkdtemp(template); if (tmpdir == NULL) { - virReportSystemError(errno, "%s", - _("Failed to create temporary directory")); + VIR_WARN("Failed to create temporary directory"); goto cleanup; } - if (virAsprintf(&path, "%s/test.sock", tmpdir) < 0) { - virReportOOMError(); + if (virAsprintf(&path, "%s/test.sock", tmpdir) < 0) goto cleanup; - } if (virNetSocketNewListenUNIX(path, 0700, -1, getgid(), &lsock) < 0) goto cleanup; @@ -260,14 +257,11 @@ static int testSocketUNIXAddrs(const void *data ATTRIBUTE_UNUSED) tmpdir = mkdtemp(template); if (tmpdir == NULL) { - virReportSystemError(errno, "%s", - _("Failed to create temporary directory")); + VIR_WARN("Failed to create temporary directory"); goto cleanup; } - if (virAsprintf(&path, "%s/test.sock", tmpdir) < 0) { - virReportOOMError(); + if (virAsprintf(&path, "%s/test.sock", tmpdir) < 0) goto cleanup; - } if (virNetSocketNewListenUNIX(path, 0700, -1, getgid(), &lsock) < 0) goto cleanup; -- 1.7.6.4

2 1

[libvirt] [PATCH 0/4] new APIs/commands for managed core dump
by Hong Xiang 03 Nov '11

03 Nov '11

This patch series added new APIs and virsh commands for 'managed core dump' functionality. Existing functionalities are intact. The 'managed core dump' functionality is in line with 'managed save', there can be at most 1 managed core dump per domain. In addition to the generate/check-existence/remove APIs/commands, there's also a download API/command to get the managed core dump of a domain for local use. Currently the new functionality has only been implemented for qemu hypervisor driver. Hong Xiang (4): new public APIs for managed core dump remote driver implementation qemu driver implementation New virsh commands for managed core dump include/libvirt/libvirt.h.in | 13 +++ src/driver.h | 18 ++++ src/libvirt.c | 187 +++++++++++++++++++++++++++++++++++++++ src/libvirt_public.syms | 8 ++ src/qemu/qemu_conf.h | 2 + src/qemu/qemu_driver.c | 176 ++++++++++++++++++++++++++++++++++++- src/remote/remote_driver.c | 4 + src/remote/remote_protocol.x | 31 ++++++- tools/virsh.c | 200 ++++++++++++++++++++++++++++++++++++++++++ 9 files changed, 636 insertions(+), 3 deletions(-)

1 4

[libvirt] [PATCHv5 0/3] Add VIR_TYPED_PARAM_STRING
by Eric Blake 03 Nov '11

03 Nov '11

This builds on v4: https://www.redhat.com/archives/libvir-list/2011-October/msg00446.html It only implements the front end of supporting typed strings across an RPC call; I'm still working on refactoring the back half of the v4 series to actually wire up blkio device weights to be the first use that actually sends a string, but wanted to get the review started on these now. Changes from v4: Added a driver feature bit. With that, it is no longer necessary to set a flag when setting parameters (libvirt.c rejects attempts for a new client to send strings to an old server lacking the feature), and getting strings no longer needs user interactions (the user does not have to worry about the flag bit; either the client is too old so the flag is not set, or the client is new enough and libvirt.c probes to see if the driver supports things to auto-set the flag; also, libvirt.c takes care of filtering out strings on the server side before returning so that the drivers do not have to pay much attention to the flag). Eric Blake (3): API: add VIR_TYPED_PARAM_STRING API: remote support for VIR_TYPED_PARAM_STRING API: add trivial qemu support for VIR_TYPED_PARAM_STRING daemon/remote.c | 33 ++++++++++-- include/libvirt/libvirt.h.in | 28 ++++++++++- src/libvirt.c | 119 +++++++++++++++++++++++++++++++++++++----- src/libvirt_internal.h | 9 +++- src/libvirt_private.syms | 1 + src/qemu/qemu_driver.c | 24 +++++++-- src/remote/remote_driver.c | 28 +++++++++- src/remote/remote_protocol.x | 2 + src/remote_protocol-structs | 2 + src/rpc/gendispatch.pl | 3 +- src/util/util.c | 14 +++++ src/util/util.h | 2 + 12 files changed, 237 insertions(+), 28 deletions(-) -- 1.7.4.4

2 8

[libvirt] [PATCH 0/5] more virTypedParameter cleanup
by Eric Blake 02 Nov '11

02 Nov '11

Following in the wake of my qemu cleanup [1], I figured it was worth fixing the other drivers as well. Let me know if I should squash this into one patch instead of 5. [1] https://www.redhat.com/archives/libvir-list/2011-November/msg00055.html Eric Blake (5): esx: allow getting < max typed parameters libxl: allow getting < max typed parameters lxc: allow getting < max typed parameters test: drop redundant check xen: allow getting < max typed parameters src/esx/esx_driver.c | 14 +------------- src/libxl/libxl_driver.c | 22 ++++++++++------------ src/lxc/lxc_driver.c | 16 +++------------- src/test/test_driver.c | 4 ---- src/xen/xen_hypervisor.c | 26 ++++++++++++-------------- src/xen/xend_internal.c | 28 +++++++++++++--------------- 6 files changed, 39 insertions(+), 71 deletions(-) -- 1.7.4.4

2 12

[libvirt] [PATCH] API: document scheduler parameter names
by Eric Blake 02 Nov '11

02 Nov '11

Document the parameter names that will be used by virDomain{Get,Set}SchedulerParameters{,Flags}, rather than hard-coding those names in each driver, to match what is done with memory, blkio, and blockstats parameters. * include/libvirt/libvirt.h.in (VIR_DOMAIN_SCHEDULER_CPU_SHARES) (VIR_DOMAIN_SCHEDULER_VCPU_PERIOD) (VIR_DOMAIN_SCHEDULER_VCPU_QUOTA, VIR_DOMAIN_SCHEDULER_WEIGHT) (VIR_DOMAIN_SCHEDULER_CAP): New field name macros. * src/qemu/qemu_driver.c (qemuSetSchedulerParametersFlags) (qemuGetSchedulerParametersFlags): Use new defines. * src/test/test_driver.c (testDomainGetSchedulerParamsFlags) (testDomainSetSchedulerParamsFlags): Likewise. * src/xen/xen_hypervisor.c (xenHypervisorGetSchedulerParameters) (xenHypervisorSetSchedulerParameters): Likewise. * src/xen/xend_internal.c (xenDaemonGetSchedulerParameters) (xenDaemonSetSchedulerParameters): Likewise. * src/lxc/lxc_driver.c (lxcSetSchedulerParametersFlags) (lxcGetSchedulerParametersFlags): Likewise. --- As mentioned here: https://www.redhat.com/archives/libvir-list/2011-November/msg00055.html I will welcome any suggested improvements on how to describe what those parameter names are configuring. Especially for the phrase "mysterious 'oo_req'", which looks just awful in public docs. include/libvirt/libvirt.h.in | 73 ++++++++++++++++++++++++++++++++--------- src/lxc/lxc_driver.c | 5 ++- src/qemu/qemu_driver.c | 25 ++++++++------ src/test/test_driver.c | 4 +- src/xen/xen_hypervisor.c | 19 ++++++----- src/xen/xend_internal.c | 18 +++++----- 6 files changed, 95 insertions(+), 49 deletions(-) diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in index 92a14a8..0840d46 100644 --- a/include/libvirt/libvirt.h.in +++ b/include/libvirt/libvirt.h.in @@ -533,6 +533,46 @@ typedef virTypedParameter *virTypedParameterPtr; /* Management of scheduler parameters */ +/** + * VIR_DOMAIN_SCHEDULER_CPU_SHARES: + * + * Macro represents proportional weight of the scheduler used on the + * host cpu, when using the posix scheduler, as a ullong. + */ +#define VIR_DOMAIN_SCHEDULER_CPU_SHARES "cpu_shares" + +/** + * VIR_DOMAIN_SCHEDULER_VCPU_PERIOD: + * + * Macro represents the enforcement period for a quota, in microseconds, + * when using the posix scheduler, as a ullong. + */ +#define VIR_DOMAIN_SCHEDULER_VCPU_PERIOD "vcpu_period" + +/** + * VIR_DOMAIN_SCHEDULER_VCPU_QUOTA: + * + * Macro represents the maximum bandwidth to be used within a period, + * when using the posix scheduler, as an llong. + */ +#define VIR_DOMAIN_SCHEDULER_VCPU_QUOTA "vcpu_quota" + +/** + * VIR_DOMAIN_SCHEDULER_WEIGHT: + * + * Macro represents the relative weight, when using the credit + * scheduler, as a uint. + */ +#define VIR_DOMAIN_SCHEDULER_WEIGHT "weight" + +/** + * VIR_DOMAIN_SCHEDULER_CAP: + * + * Macro represents the maximum scheduler cap, when using the credit + * scheduler, as a uint. + */ +#define VIR_DOMAIN_SCHEDULER_CAP "cap" + /* * Fetch scheduler parameters, caller allocates 'params' field of size 'nparams' */ @@ -586,15 +626,16 @@ typedef virDomainBlockStatsStruct *virDomainBlockStatsPtr; /** * VIR_DOMAIN_BLOCK_STATS_FIELD_LENGTH: * - * Macro providing the field length of virDomainBlockStatsFlagsStruct + * Macro providing the field length of parameter names when using + * virDomainBlockStatsFlags(). */ -#define VIR_DOMAIN_BLOCK_STATS_FIELD_LENGTH 80 +#define VIR_DOMAIN_BLOCK_STATS_FIELD_LENGTH VIR_TYPED_PARAM_FIELD_LENGTH /** * VIR_DOMAIN_BLOCK_STATS_READ_BYTES: * * Macro represents the total number of read bytes of the - * block device. + * block device, as an llong. */ #define VIR_DOMAIN_BLOCK_STATS_READ_BYTES "rd_bytes" @@ -602,7 +643,7 @@ typedef virDomainBlockStatsStruct *virDomainBlockStatsPtr; * VIR_DOMAIN_BLOCK_STATS_READ_REQ: * * Macro represents the total read requests of the - * block device. + * block device, as an llong. */ #define VIR_DOMAIN_BLOCK_STATS_READ_REQ "rd_operations" @@ -610,7 +651,7 @@ typedef virDomainBlockStatsStruct *virDomainBlockStatsPtr; * VIR_DOMAIN_BLOCK_STATS_READ_TOTAL_TIMES: * * Macro represents the total time spend on cache reads in - * nano-seconds of the block device. + * nano-seconds of the block device, as an llong. */ #define VIR_DOMAIN_BLOCK_STATS_READ_TOTAL_TIMES "rd_total_times" @@ -618,7 +659,7 @@ typedef virDomainBlockStatsStruct *virDomainBlockStatsPtr; * VIR_DOMAIN_BLOCK_STATS_WRITE_BYTES: * * Macro represents the total number of write bytes of the - * block device. + * block device, as an llong. */ #define VIR_DOMAIN_BLOCK_STATS_WRITE_BYTES "wr_bytes" @@ -626,7 +667,7 @@ typedef virDomainBlockStatsStruct *virDomainBlockStatsPtr; * VIR_DOMAIN_BLOCK_STATS_WRITE_REQ: * * Macro represents the total write requests of the - * block device. + * block device, as an llong. */ #define VIR_DOMAIN_BLOCK_STATS_WRITE_REQ "wr_operations" @@ -634,7 +675,7 @@ typedef virDomainBlockStatsStruct *virDomainBlockStatsPtr; * VIR_DOMAIN_BLOCK_STATS_WRITE_TOTAL_TIMES: * * Macro represents the total time spend on cache writes in - * nano-seconds of the block device. + * nano-seconds of the block device, as an llong. */ #define VIR_DOMAIN_BLOCK_STATS_WRITE_TOTAL_TIMES "wr_total_times" @@ -642,7 +683,7 @@ typedef virDomainBlockStatsStruct *virDomainBlockStatsPtr; * VIR_DOMAIN_BLOCK_STATS_FLUSH_REQ: * * Macro represents the total flush requests of the - * block device. + * block device, as an llong. */ #define VIR_DOMAIN_BLOCK_STATS_FLUSH_REQ "flush_operations" @@ -650,14 +691,14 @@ typedef virDomainBlockStatsStruct *virDomainBlockStatsPtr; * VIR_DOMAIN_BLOCK_STATS_FLUSH_TOTAL_TIMES: * * Macro represents the total time spend on cache flushing in - * nano-seconds of the block device. + * nano-seconds of the block device, as an llong. */ #define VIR_DOMAIN_BLOCK_STATS_FLUSH_TOTAL_TIMES "flush_total_times" /** * VIR_DOMAIN_BLOCK_STATS_ERRS: * - * In Xen this returns the mysterious 'oo_req' + * In Xen this returns the mysterious 'oo_req', as an llong. */ #define VIR_DOMAIN_BLOCK_STATS_ERRS "errs" @@ -1136,7 +1177,7 @@ char * virDomainGetSchedulerType(virDomainPtr domain, * VIR_DOMAIN_BLKIO_WEIGHT: * * Macro for the Blkio tunable weight: it represents the io weight - * the guest can use. + * the guest can use, as a uint. */ #define VIR_DOMAIN_BLKIO_WEIGHT "weight" @@ -1163,7 +1204,7 @@ int virDomainGetBlkioParameters(virDomainPtr domain, * VIR_DOMAIN_MEMORY_HARD_LIMIT: * * Macro for the memory tunable hard_limit: it represents the maximum memory - * the guest can use. + * the guest can use, as a ullong. */ #define VIR_DOMAIN_MEMORY_HARD_LIMIT "hard_limit" @@ -1172,7 +1213,7 @@ int virDomainGetBlkioParameters(virDomainPtr domain, * VIR_DOMAIN_MEMORY_SOFT_LIMIT: * * Macro for the memory tunable soft_limit: it represents the memory upper - * limit enforced during memory contention. + * limit enforced during memory contention, as a ullong. */ #define VIR_DOMAIN_MEMORY_SOFT_LIMIT "soft_limit" @@ -1181,7 +1222,7 @@ int virDomainGetBlkioParameters(virDomainPtr domain, * VIR_DOMAIN_MEMORY_MIN_GUARANTEE: * * Macro for the memory tunable min_guarantee: it represents the minimum - * memory guaranteed to be reserved for the guest. + * memory guaranteed to be reserved for the guest, as a ullong. */ #define VIR_DOMAIN_MEMORY_MIN_GUARANTEE "min_guarantee" @@ -1190,7 +1231,7 @@ int virDomainGetBlkioParameters(virDomainPtr domain, * VIR_DOMAIN_MEMORY_SWAP_HARD_LIMIT: * * Macro for the swap tunable swap_hard_limit: it represents the maximum swap - * plus memory the guest can use. This limit has to be more than + * plus memory the guest can use, as a ullong. This limit has to be more than * VIR_DOMAIN_MEMORY_HARD_LIMIT. */ diff --git a/src/lxc/lxc_driver.c b/src/lxc/lxc_driver.c index 3af7a30..9c89c41 100644 --- a/src/lxc/lxc_driver.c +++ b/src/lxc/lxc_driver.c @@ -2524,7 +2524,7 @@ lxcSetSchedulerParametersFlags(virDomainPtr domain, for (i = 0; i < nparams; i++) { virTypedParameterPtr param = &params[i]; - if (STRNEQ(param->field, "cpu_shares")) { + if (STRNEQ(param->field, VIR_DOMAIN_SCHEDULER_CPU_SHARES)) { lxcError(VIR_ERR_INVALID_ARG, _("Invalid parameter `%s'"), param->field); goto cleanup; @@ -2603,7 +2603,8 @@ lxcGetSchedulerParametersFlags(virDomainPtr domain, if (virCgroupGetCpuShares(group, &val) != 0) goto cleanup; params[0].value.ul = val; - if (virStrcpyStatic(params[0].field, "cpu_shares") == NULL) { + if (virStrcpyStatic(params[0].field, + VIR_DOMAIN_SCHEDULER_CPU_SHARES) == NULL) { lxcError(VIR_ERR_INTERNAL_ERROR, "%s", _("Field cpu_shares too big for destination")); goto cleanup; diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index f81cb88..37272e0 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -6297,7 +6297,8 @@ static int qemuDomainSetMemoryParameters(virDomainPtr dom, } } else if (STREQ(param->field, VIR_DOMAIN_MEMORY_MIN_GUARANTEE)) { qemuReportError(VIR_ERR_INVALID_ARG, - _("Memory tunable `%s' not implemented"), param->field); + _("Memory tunable `%s' not implemented"), + param->field); ret = -1; } else { qemuReportError(VIR_ERR_INVALID_ARG, @@ -6696,7 +6697,7 @@ static int qemuSetSchedulerParametersFlags(virDomainPtr dom, for (i = 0; i < nparams; i++) { virTypedParameterPtr param = &params[i]; - if (STREQ(param->field, "cpu_shares")) { + if (STREQ(param->field, VIR_DOMAIN_SCHEDULER_CPU_SHARES)) { if (param->type != VIR_TYPED_PARAM_ULLONG) { qemuReportError(VIR_ERR_INVALID_ARG, "%s", _("invalid type for cpu_shares tunable, expected a 'ullong'")); @@ -6717,7 +6718,7 @@ static int qemuSetSchedulerParametersFlags(virDomainPtr dom, if (flags & VIR_DOMAIN_AFFECT_CONFIG) { vmdef->cputune.shares = params[i].value.ul; } - } else if (STREQ(param->field, "vcpu_period")) { + } else if (STREQ(param->field, VIR_DOMAIN_SCHEDULER_VCPU_PERIOD)) { if (param->type != VIR_TYPED_PARAM_ULLONG) { qemuReportError(VIR_ERR_INVALID_ARG, "%s", _("invalid type for vcpu_period tunable," @@ -6737,7 +6738,7 @@ static int qemuSetSchedulerParametersFlags(virDomainPtr dom, if (flags & VIR_DOMAIN_AFFECT_CONFIG) { vmdef->cputune.period = params[i].value.ul; } - } else if (STREQ(param->field, "vcpu_quota")) { + } else if (STREQ(param->field, VIR_DOMAIN_SCHEDULER_VCPU_QUOTA)) { if (param->type != VIR_TYPED_PARAM_LLONG) { qemuReportError(VIR_ERR_INVALID_ARG, "%s", _("invalid type for vcpu_quota tunable," @@ -6981,11 +6982,11 @@ qemuGetSchedulerParametersFlags(virDomainPtr dom, out: params[0].value.ul = shares; params[0].type = VIR_TYPED_PARAM_ULLONG; - /* XXX make these field names public in libvirt.h */ - if (virStrcpyStatic(params[0].field, "cpu_shares") == NULL) { + if (virStrcpyStatic(params[0].field, + VIR_DOMAIN_SCHEDULER_CPU_SHARES) == NULL) { qemuReportError(VIR_ERR_INTERNAL_ERROR, _("Field name '%s' too long"), - "cpu_shares"); + VIR_DOMAIN_SCHEDULER_CPU_SHARES); goto cleanup; } @@ -6995,10 +6996,11 @@ out: if (*nparams > saved_nparams) { params[1].value.ul = period; params[1].type = VIR_TYPED_PARAM_ULLONG; - if (virStrcpyStatic(params[1].field, "vcpu_period") == NULL) { + if (virStrcpyStatic(params[1].field, + VIR_DOMAIN_SCHEDULER_VCPU_PERIOD) == NULL) { qemuReportError(VIR_ERR_INTERNAL_ERROR, _("Field name '%s' too long"), - "vcpu_period"); + VIR_DOMAIN_SCHEDULER_VCPU_PERIOD); goto cleanup; } saved_nparams++; @@ -7007,10 +7009,11 @@ out: if (*nparams > saved_nparams) { params[2].value.ul = quota; params[2].type = VIR_TYPED_PARAM_LLONG; - if (virStrcpyStatic(params[2].field, "vcpu_quota") == NULL) { + if (virStrcpyStatic(params[2].field, + VIR_DOMAIN_SCHEDULER_VCPU_QUOTA) == NULL) { qemuReportError(VIR_ERR_INTERNAL_ERROR, _("Field name '%s' too long"), - "vcpu_quota"); + VIR_DOMAIN_SCHEDULER_VCPU_QUOTA); goto cleanup; } saved_nparams++; diff --git a/src/test/test_driver.c b/src/test/test_driver.c index 326409d..4e1973a 100644 --- a/src/test/test_driver.c +++ b/src/test/test_driver.c @@ -2713,7 +2713,7 @@ testDomainGetSchedulerParamsFlags(virDomainPtr domain, testError(VIR_ERR_INVALID_ARG, "%s", _("Invalid parameter count")); goto cleanup; } - strcpy(params[0].field, "weight"); + strcpy(params[0].field, VIR_DOMAIN_SCHEDULER_WEIGHT); params[0].type = VIR_TYPED_PARAM_UINT; /* XXX */ /*params[0].value.ui = privdom->weight;*/ @@ -2759,7 +2759,7 @@ testDomainSetSchedulerParamsFlags(virDomainPtr domain, } for (i = 0; i < nparams; i++) { - if (STRNEQ(params[i].field, "weight")) { + if (STRNEQ(params[i].field, VIR_DOMAIN_SCHEDULER_WEIGHT)) { testError(VIR_ERR_INVALID_ARG, "field"); goto cleanup; } diff --git a/src/xen/xen_hypervisor.c b/src/xen/xen_hypervisor.c index 58ae6a3..f1a8e68 100644 --- a/src/xen/xen_hypervisor.c +++ b/src/xen/xen_hypervisor.c @@ -1203,9 +1203,6 @@ xenHypervisorGetSchedulerType(virDomainPtr domain, int *nparams) return schedulertype; } -static const char *str_weight = "weight"; -static const char *str_cap = "cap"; - /** * xenHypervisorGetSchedulerParameters: * @domain: pointer to the Xen Hypervisor block @@ -1291,17 +1288,21 @@ xenHypervisorGetSchedulerParameters(virDomainPtr domain, if (ret < 0) return(-1); - if (virStrcpyStatic(params[0].field, str_weight) == NULL) { + if (virStrcpyStatic(params[0].field, + VIR_DOMAIN_SCHEDULER_WEIGHT) == NULL) { virXenError(VIR_ERR_INTERNAL_ERROR, - "Weight %s too big for destination", str_weight); + "Weight %s too big for destination", + VIR_DOMAIN_SCHEDULER_WEIGHT); return -1; } params[0].type = VIR_TYPED_PARAM_UINT; params[0].value.ui = op_dom.u.getschedinfo.u.credit.weight; - if (virStrcpyStatic(params[1].field, str_cap) == NULL) { + if (virStrcpyStatic(params[1].field, + VIR_DOMAIN_SCHEDULER_CAP) == NULL) { virXenError(VIR_ERR_INTERNAL_ERROR, - "Cap %s too big for destination", str_cap); + "Cap %s too big for destination", + VIR_DOMAIN_SCHEDULER_CAP); return -1; } params[1].type = VIR_TYPED_PARAM_UINT; @@ -1402,7 +1403,7 @@ xenHypervisorSetSchedulerParameters(virDomainPtr domain, for (i = 0; i < nparams; i++) { memset(&buf, 0, sizeof(buf)); - if (STREQ (params[i].field, str_weight) && + if (STREQ (params[i].field, VIR_DOMAIN_SCHEDULER_WEIGHT) && params[i].type == VIR_TYPED_PARAM_UINT) { val = params[i].value.ui; if ((val < 1) || (val > USHRT_MAX)) { @@ -1411,7 +1412,7 @@ xenHypervisorSetSchedulerParameters(virDomainPtr domain, return(-1); } op_dom.u.getschedinfo.u.credit.weight = val; - } else if (STREQ (params[i].field, str_cap) && + } else if (STREQ (params[i].field, VIR_DOMAIN_SCHEDULER_CAP) && params[i].type == VIR_TYPED_PARAM_UINT) { val = params[i].value.ui; if (val >= USHRT_MAX) { diff --git a/src/xen/xend_internal.c b/src/xen/xend_internal.c index fa39e8b..4fcc628 100644 --- a/src/xen/xend_internal.c +++ b/src/xen/xend_internal.c @@ -3554,9 +3554,6 @@ error: } -static const char *str_weight = "weight"; -static const char *str_cap = "cap"; - /** * xenDaemonGetSchedulerParameters: * @domain: pointer to the Domain block @@ -3635,18 +3632,21 @@ xenDaemonGetSchedulerParameters(virDomainPtr domain, goto error; } - if (virStrcpyStatic(params[0].field, str_weight) == NULL) { + if (virStrcpyStatic(params[0].field, + VIR_DOMAIN_SCHEDULER_WEIGHT) == NULL) { virXendError(VIR_ERR_INTERNAL_ERROR, _("Weight %s too big for destination"), - str_weight); + VIR_DOMAIN_SCHEDULER_WEIGHT); goto error; } params[0].type = VIR_TYPED_PARAM_UINT; params[0].value.ui = sexpr_int(root, "domain/cpu_weight"); - if (virStrcpyStatic(params[1].field, str_cap) == NULL) { + if (virStrcpyStatic(params[1].field, + VIR_DOMAIN_SCHEDULER_CAP) == NULL) { virXendError(VIR_ERR_INTERNAL_ERROR, - _("Cap %s too big for destination"), str_cap); + _("Cap %s too big for destination"), + VIR_DOMAIN_SCHEDULER_CAP); goto error; } params[1].type = VIR_TYPED_PARAM_UINT; @@ -3727,10 +3727,10 @@ xenDaemonSetSchedulerParameters(virDomainPtr domain, memset(&buf_weight, 0, VIR_UUID_BUFLEN); memset(&buf_cap, 0, VIR_UUID_BUFLEN); for (i = 0; i < nparams; i++) { - if (STREQ (params[i].field, str_weight) && + if (STREQ (params[i].field, VIR_DOMAIN_SCHEDULER_WEIGHT) && params[i].type == VIR_TYPED_PARAM_UINT) { snprintf(buf_weight, sizeof(buf_weight), "%u", params[i].value.ui); - } else if (STREQ (params[i].field, str_cap) && + } else if (STREQ (params[i].field, VIR_DOMAIN_SCHEDULER_CAP) && params[i].type == VIR_TYPED_PARAM_UINT) { snprintf(buf_cap, sizeof(buf_cap), "%u", params[i].value.ui); } else { -- 1.7.4.4

3 4

[libvirt] unable to set security context error ...
by Onkar N Mahajan 02 Nov '11

02 Nov '11

I am getting 'system_u:object_r:svirt_image_t:s0:c129,c783' on '/var/lib/libvirt/images/vm01.img': Permission denied' when I try to install using virt-manager. #semanage fcontext -l | grep images /var/lib/libvirt/images(/.*)? all files system_u:object_r:svirt_image_t:s0 /var/lib/tftpboot/images(/.*)? all files system_u:object_r:cobbler_var_lib_t:s0 /var/lib/xen/images(/.*)? all files system_u:object_r:xen_image_t:s0 /var/www/cobbler/images(/.*)? all files system_u:object_r:cobbler_var_lib_t:s0 and #ls -aZ drwxr-xr-x. root root unconfined_u:object_r:virt_var_lib_t:s0 . drwxr-xr-x. root root system_u:object_r:virt_var_lib_t:s0 .. -rw-------. root root system_u:object_r:svirt_image_t:s0 vm01.img Installation fails with following error message : Unable to complete install: 'unable to set security context 'system_u:object_r:svirt_image_t:s0:c129,c783' on '/var/lib/libvirt/images/vm01.img': Permission denied' Traceback (most recent call last): File "/usr/local/share/virt-manager/virtManager/asyncjob.py", line 44, in cb_wrapper callback(asyncjob, *args, **kwargs) File "/usr/local/share/virt-manager/virtManager/create.py", line 1902, in do_install guest.start_install(False, meter=meter) File "/usr/lib/python2.7/site-packages/virtinst/Guest.py", line 1224, in start_install noboot) File "/usr/lib/python2.7/site-packages/virtinst/Guest.py", line 1292, in _create_guest dom = self.conn.createLinux(start_xml or final_xml, 0) File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1277, in createLinux if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self) libvirtError: unable to set security context 'system_u:object_r:svirt_image_t:s0:c129,c783' on '/var/lib/libvirt/images/vm01.img': Permission denied also, [/usr/libexec]#which qemu-kvm /usr/bin/qemu-kvm [/usr/libexec]#ls -aZ /usr/bin/qemu-kvm -rwxr-xr-x. root root unconfined_u:object_r:qemu_exec_t:s0 /usr/bin/qemu-kvm [/usr/libexec]#which libvirtd /usr/local/sbin/libvirtd [/usr/libexec]#ls -aZ /usr/local/sbin/libvirtd -rwxr-xr-x. root root system_u:object_r:bin_t:s0 /usr/local/sbin/libvirtd Please help me as to where I am going wrong.. Regards, Onkar

1 0

[libvirt] Notes from the KVM Forum relevant to libvirt
by Daniel P. Berrange 02 Nov '11

02 Nov '11

I was at the KVM Forum / LinuxCon last week and there were many interesting things discussed which are relevant to ongoing libvirt development. Here was the list that caught my attention. If I have missed any, fill in the gaps.... - Sandbox/container KVM. The Solaris port of KVM puts QEMU inside a zone so that an exploit of QEMU can't escape into the full OS. Containers are Linux's parallel of Zones, and while not nearly as secure yet, it would still be worth using more containers support to confine QEMU. - Events for object changes. We already have async events for virDomainPtr. We need the same for virInterfacePtr, virStoragePoolPtr, virStorageVolPtr and virNodeDevPtr, so that at the very least applications can be notified when objects are created or removed. For virNodeDevPtr we also want to be notified when properties change (ie CDROM media change). - CGroups passthrough. There is alot of experimentation with cgroups. We don't want to expose cgroups as a direct concept in the libvirt API, but we should consider putting a generic cgroups get/set in the libvirt-qemu.so library, or create a libvirt-linux.so library. Also likely add a <linux:cgroups> XML element to store arbitrary tunables in the XML. Same (low) level of support as with qemu:XXX of course - CPUSet for changing CPU + Memory NUMA pinning. The CPUset cgroups controller is able to actually move a guest's memory between NUMA nodes. We can already change VCPU pinning, but we need a new API to do node pinning of the whole VM, so we can ensure the I/O threads are also moved. We also need an API to move the memory pinning to new nodes. - Guest NUMA topology. If we have guests with RAM size > node size, we need to expose a NUMA topology into the guest. The CPU/memory pinning APIs will also need to be able to pin individual guest NUMA nodes to individual host NUMA nodes. - AHCI controller. IDE is going the way of the dodo. We need to add support for QEMU's new AHCI controller. This is quite simple, we already have a 'sata' disk type we can wire up to QEMU - VFIO PCI passthru. The current PCI assignment code may well be changed to use something called 'VFIO'. This will need some work in libvirt to support new CLI arg syntax, and probably some SELinux work - QCow3. There will soon be a QCow3 format. We need to add code to detect it and extract backing stores, etc. Trivial since the primary header format will still be the same as QCow2. - QMP completion. Given anthony's plan for a complete replacement of the current CLI + monitor syntax in QEMU 2.0 (long way out), he has dropped objections to adding new commands to QMP in the near future. So all existing HMP commands will immediately be made available in QMP with no attempt to re-design them now. So the need for the HMP passthrough command will soon go away. - Migration + VEPA/VNLink failures. As raised previously on this list, Cisco really wants libvirt to have the ability to do migration, and optionally *not* fail, even if the VEPA/VNLink setup fails. This will require an event notification to the app if a failure of a device backend occurs, and an API to let the admin app fix the device backend (virDomainUpdateDevice) and some way to tell migration what bits are allowed to fail. - Virtio SCSI. We need to support this new stuff in QEMU when it is eventually implemented. It will mean we avoid the PCI slot usage problems inherant in virtio-blk, and get other things like multipath and decent SCSI passthrough support. - USB 2.0. We need to support this in libvirt asap. It is very important for desktop experiance and to support better integration with SPICE This also gets us proper USB port addressing. Fun footnote, QEMU USB has *never* supported migration. The USB tablet only works by sheer luck, as OS' see the device disappear on migration & come back with different device ID/port addr and so does a re-initialize ! - Native KVM tool. The problem statement was that the QEMU code is too big/complex & and command line args are too complex, so lets rewrite from scratch to make the code small & CLI simple. They achieve this, but of course primarily because they lack so many features compared to QEMU. They had libvirt support as a bullet point on their preso, but I'm not expecting it to replace the current QEMU KVM support in the forseeable future, given its current level of features and the size of its dev team compared to QEMU/KVM. They did have some fun demos of booting using the host OS filesystem though. We can actually do the same with regular KVM/libvirt but there's no nice demo tool to show it off. I'm hoping to create one.... - Shared memory devices. Some people doing high performance work are using the QEMU shared memory device. We don't support this (ivhshm device) in libvirt yet. Fairly niche use cases but might be nice to have this. - SDK / Docs. Request for a more SDK like approach to KVM development tools and documentation. Also want to simplify libvirt operations. The exposure of the virt-install internal API as official GObjects would have significantly helped the project Ricardo (from IBM) described in his presentation. Of course no one can argue that we need more documentation in every area. - USB managed mode. As we do with PCI passthrough, we should be able to detach USB device from host OS, and perform a reset before attaching to the guest, and most importantly track which USB devices have been given to which guest, so we don't duplicate assign. We have all neccessary APIs, just need to wire them up. - PCI passthrough. We need to support setting of MAC addr, VLAN and VEPA/VNLink properties against VFs from SRIOV NICs that are assigned to a guest. For those who were not at the KVM Forum, the presentations are already available online at: http://www.linux-kvm.org/page/KVM_Forum_2011 All the session were also video recorded, so sometime in the next week or two, there should be OGG videos of the talks being uploaded to the same site. 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 :|

6 13

[libvirt] [PATCH 1/2] docs: improve typed parameter documentation
by Eric Blake 02 Nov '11

02 Nov '11

virDomainBlockStatsFlags was missing a check that was present in virDomainGetMemoryParameters. Additionally, I found that the existing descriptions were a bit hard to read. A later patch will fix qemu to return fewer than max parameters if @nparams was too small on input, rather than outright fail. * src/libvirt.c (virDomainGetMemoryParameters) (virDomainGetBlkioParameters, virDomainGetSchedulerParameters) (virDomainGetSchedulerParametersFlags): Tweak documentation wording. (virDomainBlockStatsFlags): Likewise, and add sanity check. --- src/libvirt.c | 100 +++++++++++++++++++++++++++++++++++++-------------------- 1 files changed, 65 insertions(+), 35 deletions(-) diff --git a/src/libvirt.c b/src/libvirt.c index e9d1a29..f9cddef 100644 --- a/src/libvirt.c +++ b/src/libvirt.c @@ -3639,15 +3639,17 @@ error: * @domain: pointer to domain object * @params: pointer to memory parameter object * (return value, allocated by the caller) - * @nparams: pointer to number of memory parameters + * @nparams: pointer to number of memory parameters; input and output * @flags: one of virDomainModificationImpact * - * Get all memory parameters, the @params array will be filled with the values - * equal to the number of parameters suggested by @nparams + * Get all memory parameters. On input, @nparams gives the size of the + * @params array; on output, @nparams gives how many slots were filled + * with parameter information, which might be less but will not exceed + * the input value. * - * As the value of @nparams is dynamic, call the API setting @nparams to 0 and - * @params as NULL, the API returns the number of parameters supported by the - * HV by updating @nparams on SUCCESS. The caller should then allocate @params + * As a special case, calling with @params as NULL and @nparams as 0 on + * input will cause @nparams on output to contain the number of parameters + * supported by the hypervisor. The caller should then allocate @params * array, i.e. (sizeof(@virTypedParameter) * @nparams) bytes and call the API * again. * @@ -3765,12 +3767,21 @@ error: * @domain: pointer to domain object * @params: pointer to blkio parameter object * (return value, allocated by the caller) - * @nparams: pointer to number of blkio parameters + * @nparams: pointer to number of blkio parameters; input and output * @flags: an OR'ed set of virDomainModificationImpact * - * Get all blkio parameters, the @params array will be filled with the values - * equal to the number of parameters suggested by @nparams. - * See virDomainGetMemoryParameters for an equivalent usage example. + * Get all blkio parameters. On input, @nparams gives the size of the + * @params array; on output, @nparams gives how many slots were filled + * with parameter information, which might be less but will not exceed + * the input value. + * + * As a special case, calling with @params as NULL and @nparams as 0 on + * input will cause @nparams on output to contain the number of parameters + * supported by the hypervisor. The caller should then allocate @params + * array, i.e. (sizeof(@virTypedParameter) * @nparams) bytes and call the API + * again. + * + * See virDomainGetMemoryParameters() for an equivalent usage example. * * This function may require privileged access to the hypervisor. This function * expects the caller to allocate the @params. @@ -6335,14 +6346,17 @@ error: * @params: pointer to scheduler parameter objects * (return value) * @nparams: pointer to number of scheduler parameter objects - * (this value must be at least as large as the returned value - * nparams of virDomainGetSchedulerType) + * (this value should generally be as large as the returned value + * nparams of virDomainGetSchedulerType()); input and output + * + * Get all scheduler parameters. On input, @nparams gives the size of the + * @params array; on output, @nparams gives how many slots were filled + * with parameter information, which might be less but will not exceed + * the input value. @nparams cannot be 0. * - * Get all scheduler parameters, the @params array will be filled with the - * values and @nparams will be updated to the number of valid elements in - * @params. It is hypervisor specific whether this returns the live or + * It is hypervisor specific whether this returns the live or * persistent state; for more control, use - * virDomainGetSchedulerParametersFlags. + * virDomainGetSchedulerParametersFlags(). * * Returns -1 in case of error, 0 in case of success. */ @@ -6391,15 +6405,28 @@ error: * (return value) * @nparams: pointer to number of scheduler parameter * (this value should be same than the returned value - * nparams of virDomainGetSchedulerType) + * nparams of virDomainGetSchedulerType()); input and output * @flags: one of virDomainModificationImpact * - * Get the scheduler parameters, the @params array will be filled with the - * values. + * Get all scheduler parameters. On input, @nparams gives the size of the + * @params array; on output, @nparams gives how many slots were filled + * with parameter information, which might be less but will not exceed + * the input value. @nparams cannot be 0. * * The value of @flags can be exactly VIR_DOMAIN_AFFECT_CURRENT, * VIR_DOMAIN_AFFECT_LIVE, or VIR_DOMAIN_AFFECT_CONFIG. * + * Here is a sample code snippet: + * + * char *ret = virDomainGetSchedulerType(dom, &nparams); + * if (ret && nparams != 0) { + * if ((params = malloc(sizeof(*params) * nparams)) == NULL) + * goto error; + * memset(params, 0, sizeof(*params) * nparams); + * if (virDomainGetSchedulerParametersFlags(dom, params, &nparams, 0)) + * goto error; + * } + * * Returns -1 in case of error, 0 in case of success. */ int @@ -6633,8 +6660,8 @@ error: * @path: path to the block device * @params: pointer to block stats parameter object * (return value) - * @nparams: pointer to number of block stats - * @flags: unused, always passes 0 + * @nparams: pointer to number of block stats; input and output + * @flags: unused, always pass 0 * * This function is to get block stats parameters for block * devices attached to the domain. @@ -6646,24 +6673,26 @@ error: * Domains may have more than one block device. To get stats for * each you should make multiple calls to this function. * - * The @params array will be filled with the value equal to the number of - * parameters suggested by @nparams. + * On input, @nparams gives the size of the @params array; on output, + * @nparams gives how many slots were filled with parameter + * information, which might be less but will not exceed the input + * value. * - * As the value of @nparams is dynamic, call the API setting @nparams to 0 and - * @params as NULL, the API returns the number of parameters supported by the - * HV by updating @nparams on SUCCESS. (Note that block device of different type - * might support different parameters numbers, so it might be necessary to compute - * @nparams for each block device type). The caller should then allocate @params + * As a special case, calling with @params as NULL and @nparams as 0 on + * input will cause @nparams on output to contain the number of parameters + * supported by the hypervisor. (Note that block devices of different types + * might support different parameters, so it might be necessary to compute + * @nparams for each block device). The caller should then allocate @params * array, i.e. (sizeof(@virTypedParameter) * @nparams) bytes and call the API - * again. See virDomainGetMemoryParameters for more details. + * again. See virDomainGetMemoryParameters() for more details. * * Returns -1 in case of error, 0 in case of success. */ -int virDomainBlockStatsFlags (virDomainPtr dom, - const char *path, - virTypedParameterPtr params, - int *nparams, - unsigned int flags) +int virDomainBlockStatsFlags(virDomainPtr dom, + const char *path, + virTypedParameterPtr params, + int *nparams, + unsigned int flags) { virConnectPtr conn; @@ -6677,7 +6706,8 @@ int virDomainBlockStatsFlags (virDomainPtr dom, virDispatchError(NULL); return -1; } - if (!path || (nparams == NULL) || (*nparams < 0)) { + if (!path || (nparams == NULL) || (*nparams < 0) || + (params == NULL && *nparams != 0)) { virLibConnError(VIR_ERR_INVALID_ARG, __FUNCTION__); goto error; } -- 1.7.4.4

4 7