[libvirt] client hang in virDomainCreateXML
by Jiff Shen
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
13 years, 5 months
[libvirt] sVirt support for LXC?
by Dong-In David Kang
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
13 years, 5 months
[libvirt] [PATCH] Remove translations in socket test case
by Daniel P. Berrange
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
13 years, 5 months
[libvirt] [PATCH 0/4] new APIs/commands for managed core dump
by Hong Xiang
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(-)
13 years, 5 months
[libvirt] [PATCHv5 0/3] Add VIR_TYPED_PARAM_STRING
by Eric Blake
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
13 years, 5 months
[libvirt] [PATCH 0/5] more virTypedParameter cleanup
by Eric Blake
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
13 years, 5 months
[libvirt] [PATCH] API: document scheduler parameter names
by Eric Blake
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 = ¶ms[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 = ¶ms[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
13 years, 5 months
[libvirt] unable to set security context error ...
by Onkar N Mahajan
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
13 years, 5 months
[libvirt] Notes from the KVM Forum relevant to libvirt
by Daniel P. Berrange
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 :|
13 years, 5 months
[libvirt] [PATCH 1/2] docs: improve typed parameter documentation
by Eric Blake
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
13 years, 5 months
