[libvirt] [PATCH v2 1/3] qemu: Remove CPU features functions calling for non-x86 platform.
From: Li Zhang zhlci...@linux.vnet.ibm.com
CPU features are not supported on non-x86 and hasFeatures will be NULL.
This patch is to remove CPU features functions calling to avoid errors.
Signed-off-by: Li Zhang zhlci...@linux.vnet.ibm.com
---
src/qemu/qemu_command.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index f8fccea..3b6ba7a 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -6349,7 +6349,6 @@ qemuBuildCpuArgStr(const virQEMUDriverPtr driver,
(def-cpu-mode != VIR_CPU_MODE_CUSTOM || def-cpu-model)) {
virCPUCompareResult cmp;
const char *preferred;
-int hasSVM;
if (!host ||
!host-model ||
@@ -6389,10 +6388,13 @@ qemuBuildCpuArgStr(const virQEMUDriverPtr driver,
/* Only 'svm' requires --enable-nesting. The nested
* 'vmx' patches now simply hook off the CPU features
*/
-hasSVM = cpuHasFeature(data, svm);
-if (hasSVM 0)
-goto cleanup;
-*hasHwVirt = hasSVM 0 ? true : false;
+if (def-os.arch == VIR_ARCH_X86_64 ||
+def-os.arch == VIR_ARCH_I686) {
+int hasSVM = cpuHasFeature(data, svm);
+if (hasSVM 0)
+goto cleanup;
+*hasHwVirt = hasSVM 0 ? true : false;
+}
if (cpu-mode == VIR_CPU_MODE_HOST_PASSTHROUGH) {
const char *mode = virCPUModeTypeToString(cpu-mode);
@@ -10575,7 +10577,9 @@ qemuParseCommandLineCPU(virDomainDefPtr dom,
model = NULL;
}
-if (virCPUDefAddFeature(cpu, feature, policy) 0)
+if ((dom-os.arch == VIR_ARCH_X86_64 ||
+dom-os.arch == VIR_ARCH_I686)
+virCPUDefAddFeature(cpu, feature, policy) 0)
goto cleanup;
}
} else if (STRPREFIX(tokens[i], hv_)) {
--
1.8.1.4
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH v2 0/3] Improve PPC CPU driver
From: Li Zhang zhlci...@linux.vnet.ibm.com Currently, PPC CPU driver doesn't support to parse guest data. It can't pass CPU parameters to Qemu command line. This patchset is to implement .guestData to support to parse guest CPU configuration and .update to support host-model and host-passthrough. The guest CPU configuration is as the following: cpu match='exact' modelPOWER7_v2.3/model vendorIBM/vendor /cpu v2 - v1: * Remove features functions calling for non-x86 platform (Doug Goldstein) * Improve update code. * Merge update code with guestData. Li Zhang (3): Remove CPU features check for non-x86 platform. cpu: Implement guestData and update for PPC cpu: Add cpu test cases for PPC CPU driver. src/cpu/cpu_powerpc.c | 178 - src/qemu/qemu_command.c| 16 +- tests/cputest.c| 9 ++ tests/cputestdata/ppc64-baseline-1-result.xml | 3 + .../ppc64-baseline-incompatible-vendors.xml| 14 ++ .../ppc64-baseline-no-vendor-result.xml| 3 + tests/cputestdata/ppc64-baseline-no-vendor.xml | 7 + tests/cputestdata/ppc64-exact.xml | 3 + tests/cputestdata/ppc64-guest-nofallback.xml | 4 + tests/cputestdata/ppc64-guest.xml | 4 + .../ppc64-host+guest,ppc_models-result.xml | 5 + ...st-nofallback,ppc_models,POWER7_v2.1-result.xml | 5 + tests/cputestdata/ppc64-host.xml | 6 + tests/cputestdata/ppc64-strict.xml | 3 + .../qemuxml2argv-pseries-cpu-exact.args| 7 + .../qemuxml2argv-pseries-cpu-exact.xml | 21 +++ tests/qemuxml2argvtest.c | 1 + 17 files changed, 279 insertions(+), 10 deletions(-) create mode 100644 tests/cputestdata/ppc64-baseline-1-result.xml create mode 100644 tests/cputestdata/ppc64-baseline-incompatible-vendors.xml create mode 100644 tests/cputestdata/ppc64-baseline-no-vendor-result.xml create mode 100644 tests/cputestdata/ppc64-baseline-no-vendor.xml create mode 100644 tests/cputestdata/ppc64-exact.xml create mode 100644 tests/cputestdata/ppc64-guest-nofallback.xml create mode 100644 tests/cputestdata/ppc64-guest.xml create mode 100644 tests/cputestdata/ppc64-host+guest,ppc_models-result.xml create mode 100644 tests/cputestdata/ppc64-host+guest-nofallback,ppc_models,POWER7_v2.1-result.xml create mode 100644 tests/cputestdata/ppc64-host.xml create mode 100644 tests/cputestdata/ppc64-strict.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pseries-cpu-exact.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pseries-cpu-exact.xml -- 1.8.1.4 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH v2 2/3] cpu: Implement guestData and update for PPC
From: Li Zhang zhlci...@linux.vnet.ibm.com
On Power platform, Power7+ can support Power7 guest.
It needs to define XML configuration to specify guest's CPU model.
For exmaple:
cpu match='exact'
modelPOWER7_v2.1/model
vendorIBM/vendor
/cpu
Signed-off-by: Li Zhang zhlci...@linux.vnet.ibm.com
---
src/cpu/cpu_powerpc.c | 178 --
1 file changed, 174 insertions(+), 4 deletions(-)
diff --git a/src/cpu/cpu_powerpc.c b/src/cpu/cpu_powerpc.c
index 647a8a1..62a789e 100644
--- a/src/cpu/cpu_powerpc.c
+++ b/src/cpu/cpu_powerpc.c
@@ -99,6 +99,23 @@ ppcModelFindPVR(const struct ppc_map *map,
return NULL;
}
+static struct ppc_model *
+ppcModelCopy(const struct ppc_model *model)
+{
+struct ppc_model *copy;
+
+if (VIR_ALLOC(copy) 0 ||
+VIR_STRDUP(copy-name, model-name) 0) {
+ppcModelFree(copy);
+return NULL;
+}
+
+copy-data.pvr = model-data.pvr;
+copy-vendor = model-vendor;
+
+return copy;
+}
+
static struct ppc_vendor *
ppcVendorFind(const struct ppc_map *map,
const char *name)
@@ -126,6 +143,29 @@ ppcVendorFree(struct ppc_vendor *vendor)
VIR_FREE(vendor);
}
+static struct ppc_model *
+ppcModelFromCPU(const virCPUDefPtr cpu,
+const struct ppc_map *map)
+{
+struct ppc_model *model = NULL;
+
+if ((model = ppcModelFind(map, cpu-model)) == NULL) {
+virReportError(VIR_ERR_INTERNAL_ERROR,
+ _(Unknown CPU model %s), cpu-model);
+goto error;
+}
+
+if ((model = ppcModelCopy(model)) == NULL)
+goto error;
+
+return model;
+
+error:
+ppcModelFree(model);
+return NULL;
+}
+
+
static int
ppcVendorLoad(xmlXPathContextPtr ctxt,
struct ppc_map *map)
@@ -288,6 +328,111 @@ error:
return NULL;
}
+static virCPUDataPtr
+ppcMakeCPUData(virArch arch, struct cpuPPCData *data)
+{
+virCPUDataPtr cpuData;
+
+if (VIR_ALLOC(cpuData) 0)
+return NULL;
+
+cpuData-arch = arch;
+cpuData-data.ppc = *data;
+data = NULL;
+
+return cpuData;
+}
+
+static virCPUCompareResult
+ppcCompute(virCPUDefPtr host,
+ const virCPUDefPtr cpu,
+ virCPUDataPtr *guestData,
+ char **message)
+
+{
+struct ppc_map *map = NULL;
+struct ppc_model *host_model = NULL;
+struct ppc_model *guest_model = NULL;
+
+int ret = 0;
+virArch arch;
+size_t i;
+
+if (cpu-arch != VIR_ARCH_NONE) {
+bool found = false;
+
+for (i = 0; i ARRAY_CARDINALITY(archs); i++) {
+if (archs[i] == cpu-arch) {
+found = true;
+break;
+}
+}
+
+if (!found) {
+VIR_DEBUG(CPU arch %s does not match host arch,
+ virArchToString(cpu-arch));
+if (message
+virAsprintf(message,
+_(CPU arch %s does not match host arch),
+virArchToString(cpu-arch)) 0)
+goto error;
+return VIR_CPU_COMPARE_INCOMPATIBLE;
+}
+arch = cpu-arch;
+} else {
+arch = host-arch;
+}
+
+if (cpu-vendor
+(!host-vendor || STRNEQ(cpu-vendor, host-vendor))) {
+VIR_DEBUG(host CPU vendor does not match required CPU vendor %s,
+ cpu-vendor);
+if (message
+virAsprintf(message,
+_(host CPU vendor does not match required
+CPU vendor %s),
+cpu-vendor) 0)
+goto error;
+return VIR_CPU_COMPARE_INCOMPATIBLE;
+}
+
+if (!(map = ppcLoadMap()) ||
+!(host_model = ppcModelFromCPU(host, map)) ||
+!(guest_model = ppcModelFromCPU(cpu, map)))
+goto error;
+
+if (guestData != NULL) {
+if (cpu-type == VIR_CPU_TYPE_GUEST
+cpu-match == VIR_CPU_MATCH_STRICT
+STRNEQ(guest_model-name, host_model-name)) {
+VIR_DEBUG(host CPU model does not match required CPU model %s,
+ guest_model-name);
+if (message
+virAsprintf(message,
+_(host CPU model does not match required
+CPU model %s),
+guest_model-name) 0)
+goto error;
+return VIR_CPU_COMPARE_INCOMPATIBLE;
+}
+
+if (!(*guestData = ppcMakeCPUData(arch, guest_model-data)))
+goto error;
+}
+
+ret = VIR_CPU_COMPARE_IDENTICAL;
+
+out:
+ppcMapFree(map);
+ppcModelFree(host_model);
+ppcModelFree(guest_model);
+return ret;
+
+error:
+ret = VIR_CPU_COMPARE_ERROR;
+goto out;
+}
+
static virCPUCompareResult
ppcCompare(virCPUDefPtr host,
virCPUDefPtr cpu)
@@ -369,11 +514,36 @@ ppcNodeData(void)
}
#endif
+static virCPUCompareResult
+ppcGuestData(virCPUDefPtr host,
+
[libvirt] [PATCH v2 3/3] cpu: Add cpu test cases for PPC CPU driver.
From: Li Zhang zhlci...@linux.vnet.ibm.com
This patch is to add cpu test casses for PPC CPU driver.
Signed-off-by: Li Zhang zhlci...@linux.vnet.ibm.com
---
tests/cputest.c | 9 +
tests/cputestdata/ppc64-baseline-1-result.xml | 3 +++
.../ppc64-baseline-incompatible-vendors.xml | 14 ++
.../cputestdata/ppc64-baseline-no-vendor-result.xml | 3 +++
tests/cputestdata/ppc64-baseline-no-vendor.xml | 7 +++
tests/cputestdata/ppc64-exact.xml | 3 +++
tests/cputestdata/ppc64-guest-nofallback.xml| 4
tests/cputestdata/ppc64-guest.xml | 4
.../ppc64-host+guest,ppc_models-result.xml | 5 +
...est-nofallback,ppc_models,POWER7_v2.1-result.xml | 5 +
tests/cputestdata/ppc64-host.xml| 6 ++
tests/cputestdata/ppc64-strict.xml | 3 +++
.../qemuxml2argv-pseries-cpu-exact.args | 7 +++
.../qemuxml2argv-pseries-cpu-exact.xml | 21 +
tests/qemuxml2argvtest.c| 1 +
15 files changed, 95 insertions(+)
create mode 100644 tests/cputestdata/ppc64-baseline-1-result.xml
create mode 100644 tests/cputestdata/ppc64-baseline-incompatible-vendors.xml
create mode 100644 tests/cputestdata/ppc64-baseline-no-vendor-result.xml
create mode 100644 tests/cputestdata/ppc64-baseline-no-vendor.xml
create mode 100644 tests/cputestdata/ppc64-exact.xml
create mode 100644 tests/cputestdata/ppc64-guest-nofallback.xml
create mode 100644 tests/cputestdata/ppc64-guest.xml
create mode 100644 tests/cputestdata/ppc64-host+guest,ppc_models-result.xml
create mode 100644
tests/cputestdata/ppc64-host+guest-nofallback,ppc_models,POWER7_v2.1-result.xml
create mode 100644 tests/cputestdata/ppc64-host.xml
create mode 100644 tests/cputestdata/ppc64-strict.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pseries-cpu-exact.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pseries-cpu-exact.xml
diff --git a/tests/cputest.c b/tests/cputest.c
index 959cb9f..408a510 100644
--- a/tests/cputest.c
+++ b/tests/cputest.c
@@ -493,6 +493,7 @@ cpuTestRun(const char *name, const struct data *data)
static const char *model486[] = { 486 };
static const char *nomodel[]= { nomodel };
static const char *models[] = { qemu64, core2duo, Nehalem };
+static const char *ppc_models[] = { POWER7, POWER7_v2.1,
POWER8_v1.0};
static int
mymain(void)
@@ -584,6 +585,9 @@ mymain(void)
DO_TEST_COMPARE(x86, host-worse, nehalem-force,
VIR_CPU_COMPARE_IDENTICAL);
DO_TEST_COMPARE(x86, host-SandyBridge, exact-force-Haswell,
VIR_CPU_COMPARE_IDENTICAL);
+DO_TEST_COMPARE(ppc64, host, strict, VIR_CPU_COMPARE_IDENTICAL);
+DO_TEST_COMPARE(ppc64, host, exact, VIR_CPU_COMPARE_INCOMPATIBLE);
+
/* guest updates for migration
* automatically compares host CPU with the result */
DO_TEST_UPDATE(x86, host, min, VIR_CPU_COMPARE_IDENTICAL);
@@ -601,6 +605,8 @@ mymain(void)
DO_TEST_BASELINE(x86, 2, 0, 0);
DO_TEST_BASELINE(x86, 3, VIR_CONNECT_BASELINE_CPU_EXPAND_FEATURES, 0);
+DO_TEST_BASELINE(ppc64, incompatible-vendors, 0, -1);
+DO_TEST_BASELINE(ppc64, no-vendor, 0, 0);
/* CPU features */
DO_TEST_HASFEATURE(x86, host, vmx, YES);
DO_TEST_HASFEATURE(x86, host, lm, YES);
@@ -627,6 +633,9 @@ mymain(void)
DO_TEST_GUESTDATA(x86, host, host+host-model-nofallback,
models, Penryn, -1);
+DO_TEST_GUESTDATA(ppc64, host, guest, ppc_models, NULL, 0);
+DO_TEST_GUESTDATA(ppc64, host, guest-nofallback, ppc_models,
POWER7_v2.1, -1);
+
VIR_FREE(map);
return ret == 0 ? EXIT_SUCCESS : EXIT_FAILURE;
}
diff --git a/tests/cputestdata/ppc64-baseline-1-result.xml
b/tests/cputestdata/ppc64-baseline-1-result.xml
new file mode 100644
index 000..cbdd9bc
--- /dev/null
+++ b/tests/cputestdata/ppc64-baseline-1-result.xml
@@ -0,0 +1,3 @@
+cpu mode='custom' match='exact'
+ model fallback='allow'POWER7+_v2.1/model
+/cpu
diff --git a/tests/cputestdata/ppc64-baseline-incompatible-vendors.xml
b/tests/cputestdata/ppc64-baseline-incompatible-vendors.xml
new file mode 100644
index 000..97d3c9c
--- /dev/null
+++ b/tests/cputestdata/ppc64-baseline-incompatible-vendors.xml
@@ -0,0 +1,14 @@
+cpuTest
+cpu
+ archppc64/arch
+ modelPOWER7+_v2.1/model
+ vendorIntel/vendor
+ topology sockets='2' cores='4' threads='1'/
+/cpu
+cpu
+ archppc64/arch
+ modelPOWER8_v1.0/model
+ vendorIntel/vendor
+ topology sockets='1' cores='1' threads='1'/
+/cpu
+/cpuTest
diff --git a/tests/cputestdata/ppc64-baseline-no-vendor-result.xml
b/tests/cputestdata/ppc64-baseline-no-vendor-result.xml
new file mode 100644
index 000..36bae52
--- /dev/null
+++ b/tests/cputestdata/ppc64-baseline-no-vendor-result.xml
@@ -0,0 +1,3 @@
+cpu mode='custom' match='exact'
+ model fallback='allow'POWER7_v2.3/model
+/cpu
diff --git
Re: [libvirt] [PATCHv5 2/5] domifaddr: Implement the remote protocol
On Mon, Sep 2, 2013 at 5:11 PM, Daniel P. Berrange berra...@redhat.com wrote:
On Sun, Sep 01, 2013 at 07:13:32PM +0530, Nehal J Wani wrote:
daemon/remote.c
* Define remoteSerializeDomainInterface,
remoteDispatchDomainInterfaceAddresses
src/remote/remote_driver.c
* Define remoteDomainInterfaceAddresses
src/remote/remote_protocol.x
* New RPC procedure: REMOTE_PROC_DOMAIN_INTERFACE_ADDRESSES
* Define structs remote_domain_ip_addr, remote_domain_interface,
remote_domain_interfaces_addresse_args,
remote_domain_interface_addresses_ret
* Introduce upper bounds (to handle DDoS attacks):
REMOTE_DOMAIN_INTERFACE_MAX = 2048
REMOTE_DOMAIN_IP_ADDR_MAX = 2048
Restrictions on the maximum number of aliases per interface were
removed after kernel v2.0, and theoretically, at present, there
are no upper limits on number of interfaces per virtual machine
and on the number of IP addresses per interface.
src/remote_protocol-structs
* New structs added
---
daemon/remote.c | 131
+++
src/remote/remote_driver.c | 99
src/remote/remote_protocol.x | 40 -
src/remote_protocol-structs | 24
4 files changed, 293 insertions(+), 1 deletion(-)
diff --git a/daemon/remote.c b/daemon/remote.c
index 6ace7af..7091cab 100644
--- a/daemon/remote.c
+++ b/daemon/remote.c
@@ -5144,7 +5144,138 @@ cleanup:
+
+static int
+remoteDispatchDomainInterfaceAddresses(
+virNetServerPtr server ATTRIBUTE_UNUSED,
+virNetServerClientPtr client,
+virNetMessagePtr msg ATTRIBUTE_UNUSED,
+virNetMessageErrorPtr rerr,
+remote_domain_interface_addresses_args *args,
+remote_domain_interface_addresses_ret *ret)
Normal practice for this file is to layout args thus:
static int
remoteDispatchDomainInterfaceAddresses(virNetServerPtr server
ATTRIBUTE_UNUSED,
virNetServerClientPtr client,
virNetMessagePtr msg ATTRIBUTE_UNUSED,
virNetMessageErrorPtr rerr,
remote_domain_interface_addresses_args *args,
remote_domain_interface_addresses_ret
*ret)
ACK if the style issue is fixed
Style issue fix (File attached):
diff --git a/daemon/remote.c b/daemon/remote.c
index 7091cab..d46e3ea 100644
--- a/daemon/remote.c
+++ b/daemon/remote.c
@@ -5230,13 +5230,12 @@ cleanup:
}
static int
-remoteDispatchDomainInterfaceAddresses(
-virNetServerPtr server ATTRIBUTE_UNUSED,
-virNetServerClientPtr client,
-virNetMessagePtr msg ATTRIBUTE_UNUSED,
-virNetMessageErrorPtr rerr,
-remote_domain_interface_addresses_args *args,
-remote_domain_interface_addresses_ret *ret)
+remoteDispatchDomainInterfaceAddresses(virNetServerPtr server ATTRIBUTE_UNUSED,
+ virNetServerClientPtr client,
+ virNetMessagePtr msg ATTRIBUTE_UNUSED,
+ virNetMessageErrorPtr rerr,
+
remote_domain_interface_addresses_args *args,
+
remote_domain_interface_addresses_ret *ret)
{
size_t i;
int rv = -1;
PS: IMO, other functions like remoteDispatchDomainCreateWithFiles,
remoteDispatchDomainCreateXMLWithFiles,
remoteDispatchDomainMigrateFinish3Params, etc also need same style
change
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 :|
--
Nehal J Wani
UG3, BTech CS+MS(CL)
IIIT-Hyderabad
http://commandlinewani.blogspot.com
2.diff
Description: Binary data
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Docs: fix a typo in virt-login-shell.pod
On 09/03/13 05:52, Alex Jia wrote: Signed-off-by: Alex Jia a...@redhat.com --- tools/virt-login-shell.pod |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/tools/virt-login-shell.pod b/tools/virt-login-shell.pod index e27d500..bcd7855 100644 --- a/tools/virt-login-shell.pod +++ b/tools/virt-login-shell.pod @@ -11,7 +11,7 @@ Bvirt-login-shell The Bvirt-login-shell program is a setuid shell that is used to join an LXC container that matches the user's name. If the container is not running, virt-login-shell will attempt to start the container. -virt-sandbox-shell is not allowed to be run by root. Normal users will get +virt-login-shell is not allowed to be run by root. Normal users will get added to a container that matches their username, if it exists, and they are configured in /etc/libvirt/virt-login-shell.conf. ACK. Peter signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 3/5] qemu: add usb-bot support from disks points of view
On Mo, 2013-09-02 at 13:57 +0100, Daniel P. Berrange wrote: On Mon, Sep 02, 2013 at 05:38:42PM +0800, Guannan Ren wrote: usb-bot only supports 16 luns(0~15) and they must be contiguous, (using lun 0 and 2 without 1 doesn't work). In this case qemu doesn't throw an error, we can not find the lun 2 in guests. So Adding a checking function in libvirt to prevent from this case. Hmm, this seems like a problematic restriction. It's how the hardware works. How does this work if we start off a guest with 3 disks attached to the usb-bot SCSI controller. Then hot-unplug the 2nd disk. You can't hotplug individual luns anyway. cheers, Gerd -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 3/3] virsh-domain: Avoid killing ssh transport tunnels when cancelling job
On 29.08.2013 17:52, Peter Krempa wrote: The vshWatchJob function registers a SIGINT handler that is used to abort the active job and does not terminate virsh. Unfortunately, this breaks when using the ssh transport as SIGINT is sent to the foreground process group including the ssh transport processes which terminate. This breaks the connection and migration is left in a insane state. With this patch the terminal is modified to ignore key binding that sends SIGINT and does the handling manually. Resoves: https://bugzilla.redhat.com/show_bug.cgi?id=983348 --- tools/virsh-domain.c | 45 - 1 file changed, 32 insertions(+), 13 deletions(-) ACK Michal -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 3/3] virsh-domain: Avoid killing ssh transport tunnels when cancelling job
On 09/03/13 09:53, Michal Privoznik wrote: On 29.08.2013 17:52, Peter Krempa wrote: The vshWatchJob function registers a SIGINT handler that is used to abort the active job and does not terminate virsh. Unfortunately, this breaks when using the ssh transport as SIGINT is sent to the foreground process group including the ssh transport processes which terminate. This breaks the connection and migration is left in a insane state. With this patch the terminal is modified to ignore key binding that sends SIGINT and does the handling manually. Resoves: https://bugzilla.redhat.com/show_bug.cgi?id=983348 --- tools/virsh-domain.c | 45 - 1 file changed, 32 insertions(+), 13 deletions(-) ACK Michal Thanks for the reviews, I've pushed 2/3 and 3/3 now. Peter signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Libvirt multi queue support
On 03.09.2013 06:42, Naor Shlomo wrote: Hi Michal First of all I want to let you know that I really appreciate your guidance. Second thing, after I successfully installed the kernel headers I was able to compile libvirt again, this time it let me start the Guest with queues='5' The Guest runs Kernel 3.9.7 but for some reason virtio_has_feature(vdev, VIRTIO_NET_F_MQ) returns false for multi queue. Could you please tell me what am I missing? Unfortunately no, I am not that familiar with KVM internals to give any useful answer. But maybe you can ask on the qemu list. Michal -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv5 3/5] domifaddr: Implement the API for qemu
Updated tests + corrections in qemu_agent.c (Diff attached):
diff --git a/src/qemu/qemu_agent.c b/src/qemu/qemu_agent.c
index 009ed77..3c0c541 100644
--- a/src/qemu/qemu_agent.c
+++ b/src/qemu/qemu_agent.c
@@ -1344,6 +1344,7 @@ qemuAgentGetInterfaces(qemuAgentPtr mon,
size_t addrs_count = 0;
virDomainInterfacePtr *ifaces_ret = NULL;
virHashTablePtr ifaces_store = NULL;
+char **ifname = NULL;
/* Initially the bag of ifaces is empty */
if (!(ifaces_store = virHashCreate(ifaces_count, NULL)))
@@ -1373,7 +1374,6 @@ qemuAgentGetInterfaces(qemuAgentPtr mon,
virJSONValuePtr tmp_iface = virJSONValueArrayGet(ret_array, i);
virJSONValuePtr ip_addr_arr = NULL;
const char *hwaddr, *ifname_s, *name = NULL;
-char **ifname = NULL;
int ip_addr_arr_size;
virDomainInterfacePtr iface = NULL;
@@ -1416,9 +1416,15 @@ qemuAgentGetInterfaces(qemuAgentPtr mon,
if (VIR_STRDUP(iface-name, ifname_s) 0)
goto error;
-/* hwaddr might be omitted */
hwaddr = virJSONValueObjectGetString(tmp_iface,
hardware-address);
-if (hwaddr VIR_STRDUP(iface-hwaddr, hwaddr) 0)
+if (!hwaddr) {
+virReportError(VIR_ERR_INTERNAL_ERROR, %s,
+ _(qemu agent didn't provide
+ 'hardware-address' field));
+goto error;
+}
+
+if (VIR_STRDUP(iface-hwaddr, hwaddr) 0)
goto error;
}
@@ -1433,7 +1439,7 @@ qemuAgentGetInterfaces(qemuAgentPtr mon,
if ((ip_addr_arr_size = virJSONValueArraySize(ip_addr_arr)) 0)
/* Mmm, empty 'ip-address'? */
-continue;
+goto error;
/* If current iface already exists, continue with the count */
addrs_count = iface-naddrs;
@@ -1508,6 +1514,7 @@ error:
virDomainInterfaceFree(ifaces_ret[i]);
}
VIR_FREE(ifaces_ret);
+virStringFreeList(ifname);
goto cleanup;
}
diff --git a/tests/qemuagenttest.c b/tests/qemuagenttest.c
index 4014a09..ddca48c 100644
--- a/tests/qemuagenttest.c
+++ b/tests/qemuagenttest.c
@@ -579,32 +579,35 @@ cleanup:
static const char testQemuAgentGetInterfacesResponse[] =
{\return\:
[
- {\name\:\lo\,
+ {\name\:\eth2\,
+\hardware-address\:\52:54:00:36:2a:e5\
+ },
+ {\name\:\eth1:0\,
\ip-addresses\:
[
{\ip-address-type\:\ipv4\,
- \ip-address\:\127.0.0.1\,
- \prefix\:8
+ \ip-address\:\192.168.10.91\,
+ \prefix\:24
},
{\ip-address-type\:\ipv6\,
- \ip-address\:\::1\,
- \prefix\:128
+ \ip-address\:\fe80::fc54:ff:fefe:4c4f\,
+ \prefix\:64
}
],
-\hardware-address\:\00:00:00:00:00:00\
+\hardware-address\:\52:54:00:d3:39:ee\
},
{\name\:\eth0\,
\ip-addresses\:
[
- {\ip-address-type\:\ipv4\,
- \ip-address\:\192.168.102.142\,
- \prefix\:24
- },
{\ip-address-type\:\ipv6\,
\ip-address\:\fe80::5054:ff:fe89:ad35\,
\prefix\:64
},
{\ip-address-type\:\ipv4\,
+ \ip-address\:\192.168.102.142\,
+ \prefix\:24
+ },
+ {\ip-address-type\:\ipv4\,
\ip-address\:\192.168.234.152\,
\prefix\:16
},
@@ -620,7 +623,7 @@ static const char testQemuAgentGetInterfacesResponse[] =
[
{\ip-address-type\:\ipv4\,
\ip-address\:\192.168.103.83\,
- \prefix\:24
+ \prefix\:32
},
{\ip-address-type\:\ipv6\,
\ip-address\:\fe80::5054:ff:fed3:39ee\,
@@ -629,22 +632,19 @@ static const char testQemuAgentGetInterfacesResponse[] =
],
\hardware-address\:\52:54:00:d3:39:ee\
},
- {\name\:\eth1:0\,
+ {\name\:\lo\,
\ip-addresses\:
[
{\ip-address-type\:\ipv4\,
- \ip-address\:\192.168.10.91\,
- \prefix\:24
+ \ip-address\:\127.0.0.1\,
+ \prefix\:8
},
{\ip-address-type\:\ipv6\,
- \ip-address\:\fe80::fc54:ff:fefe:4c4f\,
- \prefix\:64
+ \ip-address\:\::1\,
+ \prefix\:128
}
],
-\hardware-address\:\52:54:00:d3:39:ee\
- },
- {\name\:\eth2\,
-
Re: [libvirt] [PATCH] Drop ChangeLog generation
On Mon, Sep 02, 2013 at 04:58:20PM -0400, Cole Robinson wrote: Fedora is perpetually low on space for its live cd, and a bug was filed asking libvirt to drop the rather large ChangeLog from the RPM: https://bugzilla.redhat.com/show_bug.cgi?id=977099 Really though, what's the point of a static ChangeLog these days? git has won, and is far more useful for querying log info than a large static blob. Well the point of the ChangeLog file is that the tar.gz should be self-contained. The tar.gz release archives will essentially live forever. I wouldn't want to make the same bet of any online services, including git. It doesn't really need to be part of the libvirt-client RPM though. It would be fine in the -devel package alongside the rest of the docs, so it wouldn't pollute the live cd. 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 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2] kvm: warn if num cpus is greater than num recommended
On Fri, Aug 23, 2013 at 03:24:37PM +0200, Andrew Jones wrote:
The comment in kvm_max_vcpus() states that it's using the recommended
procedure from the kernel API documentation to get the max number
of vcpus that kvm supports. It is, but by always returning the
maximum number supported. The maximum number should only be used
for development purposes. qemu should check KVM_CAP_NR_VCPUS for
the recommended number of vcpus. This patch adds a warning if a user
specifies a number of cpus between the recommended and max.
v2:
Incorporate tests for max_cpus, which specifies the maximum number
of hotpluggable cpus. An additional note is that the message for
the fail case was slightly changed, 'exceeds max cpus' to
'exceeds the maximum cpus'. If this is unacceptable change for
users like libvirt, then I'll need to spin a v3.
Signed-off-by: Andrew Jones drjo...@redhat.com
Applied, thanks.
---
kvm-all.c | 69
---
1 file changed, 40 insertions(+), 29 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index a2d49786365e3..021f5f47e53da 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -1322,24 +1322,20 @@ static int kvm_irqchip_create(KVMState *s)
return 0;
}
-static int kvm_max_vcpus(KVMState *s)
+/* Find number of supported CPUs using the recommended
+ * procedure from the kernel API documentation to cope with
+ * older kernels that may be missing capabilities.
+ */
+static int kvm_recommended_vcpus(KVMState *s)
{
-int ret;
-
-/* Find number of supported CPUs using the recommended
- * procedure from the kernel API documentation to cope with
- * older kernels that may be missing capabilities.
- */
-ret = kvm_check_extension(s, KVM_CAP_MAX_VCPUS);
-if (ret) {
-return ret;
-}
-ret = kvm_check_extension(s, KVM_CAP_NR_VCPUS);
-if (ret) {
-return ret;
-}
+int ret = kvm_check_extension(s, KVM_CAP_NR_VCPUS);
+return (ret) ? ret : 4;
+}
-return 4;
+static int kvm_max_vcpus(KVMState *s)
+{
+int ret = kvm_check_extension(s, KVM_CAP_MAX_VCPUS);
+return (ret) ? ret : kvm_recommended_vcpus(s);
}
int kvm_init(void)
@@ -1347,11 +1343,19 @@ int kvm_init(void)
static const char upgrade_note[] =
Please upgrade to at least kernel 2.6.29 or recent kvm-kmod\n
(see http://sourceforge.net/projects/kvm).\n;
+struct {
+const char *name;
+int num;
+} num_cpus[] = {
+{ SMP, smp_cpus },
+{ hotpluggable, max_cpus },
+{ NULL, }
+}, *nc = num_cpus;
+int soft_vcpus_limit, hard_vcpus_limit;
KVMState *s;
const KVMCapabilityInfo *missing_cap;
int ret;
int i;
-int max_vcpus;
s = g_malloc0(sizeof(KVMState));
@@ -1392,19 +1396,26 @@ int kvm_init(void)
goto err;
}
-max_vcpus = kvm_max_vcpus(s);
-if (smp_cpus max_vcpus) {
-ret = -EINVAL;
-fprintf(stderr, Number of SMP cpus requested (%d) exceeds max cpus
-supported by KVM (%d)\n, smp_cpus, max_vcpus);
-goto err;
-}
+/* check the vcpu limits */
+soft_vcpus_limit = kvm_recommended_vcpus(s);
+hard_vcpus_limit = kvm_max_vcpus(s);
-if (max_cpus max_vcpus) {
-ret = -EINVAL;
-fprintf(stderr, Number of hotpluggable cpus requested (%d) exceeds
max cpus
-supported by KVM (%d)\n, max_cpus, max_vcpus);
-goto err;
+while (nc-name) {
+if (nc-num soft_vcpus_limit) {
+fprintf(stderr,
+Warning: Number of %s cpus requested (%d) exceeds
+the recommended cpus supported by KVM (%d)\n,
+nc-name, nc-num, soft_vcpus_limit);
+
+if (nc-num hard_vcpus_limit) {
+ret = -EINVAL;
+fprintf(stderr, Number of %s cpus requested (%d) exceeds
+the maximum cpus supported by KVM (%d)\n,
+nc-name, nc-num, hard_vcpus_limit);
+goto err;
+}
+}
+nc++;
}
s-vmfd = kvm_ioctl(s, KVM_CREATE_VM, 0);
--
1.8.1.4
--
Gleb.
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Is it a problem that after virEventRegisterDefaultImpl we have handlers leaked
On Mon, Sep 02, 2013 at 07:44:39AM +, Wangyufei (A) wrote:
Hello,
When I ran programme event-test compiled from event-test.c, I found a problem
that, after virEventRegisterDefaultImpl I do virConnectOpenAuth and
virConnectClose, there will be handlers of socket and pipe opened by
virConnectOpenAuth leaked after virConnectClose. So I did some analysis, and
I found the fact following:
In the condition that we only have one connection here
int virNetSocketAddIOCallback(virNetSocketPtr sock,
int events,
virNetSocketIOFunc func,
void *opaque,
virFreeCallback ff)
{
int ret = -1;
virObjectRef(sock); //Here we add sock refers once, then we will get
refers equal 2 after
virObjectLock(sock);
if (sock-watch 0) {
VIR_DEBUG(Watch already registered on socket %p, sock);
goto cleanup;
}
if ((sock-watch = virEventAddHandle(sock-fd, //If we have called
virEventRegisterDefaultImpl, then here we'll get a sock watch non negative
and will not go to cleanup.
events,
virNetSocketEventHandle,
sock,
virNetSocketEventFree)) 0) {
VIR_DEBUG(Failed to register watch on socket %p, sock);
goto cleanup;
}
sock-func = func;
sock-opaque = opaque;
sock-ff = ff;
ret = 0;
cleanup:
virObjectUnlock(sock);
if (ret != 0)
virObjectUnref(sock); //If we haven't called
virEventRegisterDefaultImpl, we'll be here after virEventAddHandle, and sock
refers will decrease to 1
return ret;
}
Condition with virEventRegisterDefaultImpl, we'll do unrefer action in two
places:
1. virEventRunDefaultImpl -virEventPollRunOnce
-virEventRunDefaultImpl -virEventPollRunOnce -virEventPollCleanupHandles
- virNetSocketEventFree - virObjectUnref
2. virConnectClose -virObjectUnref -virConnectDispose
-remoteConnectClose -doRemoteClose -virNetClientClose
-virNetClientCloseInternal - virNetClientIOEventLoopPassTheBuck -
virNetClientCloseLocked - virObjectUnref
When event dealing loop is alive, everything work fine, we'll get sock refers
2
after virConnectOpenAuth and unrefer twice in two places above after
virConnectClose.
But If some accidents happened like we quit event dealing loop or
virEventRunDefaultImpl
suspended, then sock refers will never be zero, and handlers will never be
freed.
Do not stop running the event loop. It is a requirement of the API that once
you have
called virEventRegisterDefaultImpl, you *must* always execute the event loop
forever
after until your application exits.
I consider to add something like virEventDeregisterDefaultImpl to set
addHandleImpl and his buddy NULL. Apparently it is far away from fixing it
completely.
No, stopping or de-registering event loop impls is a non-goal.
At last I have two questions here:
1. Is it a problem that after virEventRegisterDefaultImpl we have
handlers leaked?
There are no handlers leaked if you run the event loop, which is a requirement
of the API.
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 :|
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] examples: Add script to parse topology from capabilities output
On 09/02/2013 04:57 PM, Peter Krempa wrote:
Add a demo script originally written by Amador Pahim to parse topology
of the host from data provided in the capabilities XML.
---
examples/python/topology.py | 45
+
1 file changed, 45 insertions(+)
create mode 100755 examples/python/topology.py
diff --git a/examples/python/topology.py b/examples/python/topology.py
new file mode 100755
index 000..1b678bc
--- /dev/null
+++ b/examples/python/topology.py
@@ -0,0 +1,45 @@
+#!/usr/bin/env python
+# Parse topology information from the capabilities XML and use
+# them to calculate host topology
+#
+# Authors:
+# Amador Pahim apa...@redhat.com
+# Peter Krempa pkre...@redhat.com
+
+import libvirt
+import sys
+from xml.dom import minidom
+
+try:
+conn = libvirt.openReadOnly(None)
+except libvirt.libvirtError:
+print 'Failed to connect to the hypervisor'
+sys.exit(1)
+
+try:
+capsXML = conn.getCapabilities()
+except libvirt.libvirtError:
+print 'Failed to request capabilities'
+sys.exit(1)
+
+caps = minidom.parseString(capsXML)
+host = caps.getElementsByTagName('host')[0]
+cells = host.getElementsByTagName('cells')[0]
+total_cpus = cells.getElementsByTagName('cpu').length
+
+socketIds = []
+siblingsIds = []
+
+socketIds = [ proc.getAttribute('socket_id')
+ for proc in cells.getElementsByTagName('cpu')
+ if proc.getAttribute('socket_id') not in socketIds ]
+
+siblingsIds = [ proc.getAttribute('siblings')
+for proc in cells.getElementsByTagName('cpu')
+if proc.getAttribute('siblings') not in siblingsIds ]
+
+print Host topology
+print NUMA nodes:, cells.getAttribute('num')
+printSockets:,len(set(socketIds))
+print Cores:,len(set(siblingsIds))
+printThreads:,total_cpus
I won't get into details like len() vs. .length, string formatting, etc.
;-) But please add a space after these commas.
Even though I don't know how this will turn out on those weird
multi-processor per core and similar architectures/processors, it should
turn out OK since you're the one who should know how those will look in
the capabilities XML.
It would be also worth adding it into specfile like other python
examples (I'm guessing those are in libvirt-python).
ACK with those two things fixed,
Martin
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] qemu: Handle huge number of queues correctly
On 09/02/2013 04:25 PM, Michal Privoznik wrote:
Currently, kernel supports up to 8 queues for a multiqueue tap device.
However, if user tries to enter a huge number (e.g. one million) the tap
allocation fails, as expected. But what is not expected is the log full
of warnings:
warning : virFileClose:83 : Tried to close invalid fd 0
The problem is, upon error we iterate over an array of FDs (handlers to
queues) and VIR_FORCE_CLOSE() over each item. However, the array is
pre-filled with zeros. Hence, we repeatedly close stdin. Ouch.
But there's more. The queues allocation is done in virNetDevTapCreate()
which cleans up the FDs in case of error. Then, its caller, the
virNetDevTapCreateInBridgePort() iterates over the FD array and tries to
close them too. And so does qemuNetworkIfaceConnect() and
qemuBuildInterfaceCommandLine().
Signed-off-by: Michal Privoznik mpriv...@redhat.com
---
src/qemu/qemu_command.c | 10 +++---
src/util/virnetdevtap.c | 4 ++--
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index f8fccea..73a13b3 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -405,7 +405,7 @@ qemuNetworkIfaceConnect(virDomainDefPtr def,
cleanup:
if (ret 0) {
size_t i;
-for (i = 0; i *tapfdSize; i++)
+for (i = 0; i *tapfdSize tapfd[i] = 0; i++)
VIR_FORCE_CLOSE(tapfd[i]);
if (template_ifname)
VIR_FREE(net-ifname);
@@ -7241,6 +7241,8 @@ qemuBuildInterfaceCommandLine(virCommandPtr cmd,
VIR_ALLOC_N(tapfdName, tapfdSize) 0)
goto cleanup;
+memset(tapfd, -1, tapfdSize * sizeof(tapfd[0]));
+
if (qemuNetworkIfaceConnect(def, conn, driver, net,
qemuCaps, tapfd, tapfdSize) 0)
goto cleanup;
@@ -7268,6 +7270,8 @@ qemuBuildInterfaceCommandLine(virCommandPtr cmd,
VIR_ALLOC_N(vhostfdName, vhostfdSize))
goto cleanup;
+memset(vhostfd, -1, vhostfdSize * sizeof(vhostfd[0]));
+
Just a question; are these non-standard settings necessary when we close
only non-zero fds?
if (qemuOpenVhostNet(def, net, qemuCaps, vhostfd, vhostfdSize) 0)
goto cleanup;
}
@@ -7329,13 +7333,13 @@ qemuBuildInterfaceCommandLine(virCommandPtr cmd,
cleanup:
if (ret 0)
virDomainConfNWFilterTeardown(net);
-for (i = 0; tapfd i tapfdSize; i++) {
+for (i = 0; tapfd i tapfdSize tapfd[i] = 0; i++) {
if (ret 0)
VIR_FORCE_CLOSE(tapfd[i]);
if (tapfdName)
VIR_FREE(tapfdName[i]);
}
-for (i = 0; vhostfd i vhostfdSize; i++) {
+for (i = 0; vhostfd i vhostfdSize vhostfd[i] = 0; i++) {
if (ret 0)
VIR_FORCE_CLOSE(vhostfd[i]);
if (vhostfdName)
diff --git a/src/util/virnetdevtap.c b/src/util/virnetdevtap.c
index 42e8dfe..dc2c224 100644
--- a/src/util/virnetdevtap.c
+++ b/src/util/virnetdevtap.c
@@ -498,8 +498,8 @@ int virNetDevTapCreateInBridgePort(const char *brname,
return 0;
error:
-while (tapfdSize)
-VIR_FORCE_CLOSE(tapfd[--tapfdSize]);
+while (tapfdSize tapfd[--tapfdSize] = 0)
+VIR_FORCE_CLOSE(tapfd[tapfdSize]);
This will not close anything in case the array looks like this:
[ 4, 5, 6, 7, 0, 0, 0, 0 ]
I suggest modifying it to the same for as in those other cases.
ACK with that fixed,
Martin
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 3/5] qemu: add usb-bot support from disks points of view
On Tue, Sep 03, 2013 at 09:51:52AM +0200, Gerd Hoffmann wrote: On Mo, 2013-09-02 at 13:57 +0100, Daniel P. Berrange wrote: On Mon, Sep 02, 2013 at 05:38:42PM +0800, Guannan Ren wrote: usb-bot only supports 16 luns(0~15) and they must be contiguous, (using lun 0 and 2 without 1 doesn't work). In this case qemu doesn't throw an error, we can not find the lun 2 in guests. So Adding a checking function in libvirt to prevent from this case. Hmm, this seems like a problematic restriction. It's how the hardware works. How does this work if we start off a guest with 3 disks attached to the usb-bot SCSI controller. Then hot-unplug the 2nd disk. You can't hotplug individual luns anyway. How does hotplug/unplug work in the context of usb-bot ? AFAIK we need to be able to run device_add usb_bot drive_add file... device_add scsi-hd And the reverse, to unplug it, if we're to have feature parity with usb-storage. 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 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/5]qemu: add usb-bot scsi controller support
On Mon, Sep 02, 2013 at 05:38:39PM +0800, Guannan Ren wrote:
BZ:https://bugzilla.redhat.com/show_bug.cgi?id=917702
qemu patch:http://lists.gnu.org/archive/html/qemu-devel/2013-01/msg02200.html
These patch aims to add usb-bot SCSI controller support for libvirt.
As usb-storage libvirt already supported, usb-bot only supports one
SCSI target with SCSI ID 0.
The difference is that usb-storage creates SCSI HBA and additionaly
either a scsi-disk or a scsi-generic device, usb-bot only creates the
SCSI HBA. we can attach a SCSI device to it with another -device.
usb-bot supports a single target and a number of luns. The limit is
15 luns (0~15 LUN ID) and they must be contiguous(using lun 0 and 2
without 1 doesn't work).
Athought usb-bot is a SCSI controller it needs to be attached to a
exsiting USB controller for work. So it has to use address of usb type.
Libvirt XML:
devices
...
disk type='file' device='disk'
driver name='qemu' type='raw'/
source file='/var/lib/libvirt/images/disk.qcow2'/
target dev='sdc' bus='scsi'/
address type='drive' controller='0' bus='0' target='0' unit='0'/
/disk
controller type='usb' index='0'/
controller type='scsi' index='0' model='usb-bot'
address type='usb' bus='0' port='1'/
/controller
...
/devices
How does this work from a hotplug POV. With usb-storage you could
just hotplug the disk device. Now it seems we need two separate
hotplug calls one of the controller and one for the disk and
the reverse.
The QEMU commandline:
qemu ${other_vm_args} \
-device piix3-usb-uhci,id=usb \
-device usb-bot,id=scsi0,bus=usb.0,port=1 \
-drive
file=/var/lib/libvirt/images/disk.qcow2,if=none,id=drive-scsi0-0-0-0,format=raw
\
-device
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0
As the usb-storage creates scsi disk automatically which doesn't let
you set scsi-disk properties such as vendor, product, wwn, channel,
scsi-id and lun. So QEMU guys prefer usb-bot to usb-storage.
So this is the first part of the whole work. Next step will replace
usb-storage with usb-bot when disk in xml uses usb bus like
disk ...
...
target bus='usb'
/disk
I'm not really a fan of introducing 2 different ways to configure
the exact same device.
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 :|
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/3] Fix and clean up multiple issues in virsh console handling
On 29.08.2013 18:36, Peter Krempa wrote:
This series has to be applied on top of virsh: Handle interrupting of jobs
manually.
Peter Krempa (3):
tools: rename console.[ch] to virsh-console.[ch] and fix coding style
virsh: Rename vshMakeStdinRaw to vshTTYMakeRaw and move it to virsh.c
virsh-console: Avoid using signal() in multithreaded application
cfg.mk | 2 +-
po/POTFILES.in | 2 +-
tools/Makefile.am| 2 +-
tools/{console.c = virsh-console.c} | 153
+++
tools/{console.h = virsh-console.h} | 11 ++-
tools/virsh-domain.c | 4 +-
tools/virsh.c| 50 +++-
tools/virsh.h| 1 +
8 files changed, 123 insertions(+), 102 deletions(-)
rename tools/{console.c = virsh-console.c} (76%)
rename tools/{console.h = virsh-console.h} (81%)
ACK series, but see my comments to 1/3.
Michal
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/3] tools: rename console.[ch] to virsh-console.[ch] and fix coding style
On 29.08.2013 18:36, Peter Krempa wrote:
---
cfg.mk | 2 +-
po/POTFILES.in | 2 +-
tools/Makefile.am| 2 +-
tools/{console.c = virsh-console.c} | 73
++--
tools/{console.h = virsh-console.h} | 4 +-
tools/virsh-domain.c | 2 +-
tools/virsh.c| 2 +-
7 files changed, 52 insertions(+), 35 deletions(-)
rename tools/{console.c = virsh-console.c} (90%)
rename tools/{console.h = virsh-console.h} (91%)
diff --git a/cfg.mk b/cfg.mk
index 23564f1..5c3f3ab 100644
--- a/cfg.mk
+++ b/cfg.mk
@@ -907,7 +907,7 @@ exclude_file_name_regexp--sc_avoid_strcase =
^tools/virsh\.h$$
_src1=libvirt|fdstream|qemu/qemu_monitor|util/(vircommand|virfile)|xen/xend_internal|rpc/virnetsocket|lxc/lxc_controller|locking/lock_daemon
_test1=shunloadtest|virnettlscontexttest|virnettlssessiontest|vircgroupmock
exclude_file_name_regexp--sc_avoid_write = \
- ^(src/($(_src1))|daemon/libvirtd|tools/console|tests/($(_test1)))\.c$$
+
^(src/($(_src1))|daemon/libvirtd|tools/virsh-console|tests/($(_test1)))\.c$$
exclude_file_name_regexp--sc_bindtextdomain = ^(tests|examples)/
diff --git a/po/POTFILES.in b/po/POTFILES.in
index 9a83069..aa604fd 100644
--- a/po/POTFILES.in
+++ b/po/POTFILES.in
@@ -213,10 +213,10 @@ src/xenapi/xenapi_driver.c
src/xenapi/xenapi_utils.c
src/xenxs/xen_sxpr.c
src/xenxs/xen_xm.c
-tools/console.c
tools/libvirt-guests.sh.in
tools/virsh.c
tools/virsh.h
+tools/virsh-console.c
tools/virsh-domain-monitor.c
tools/virsh-domain.c
tools/virsh-edit.c
diff --git a/tools/Makefile.am b/tools/Makefile.am
index 74fae2d..cd4cb31 100644
--- a/tools/Makefile.am
+++ b/tools/Makefile.am
@@ -161,8 +161,8 @@ virt_login_shell_CFLAGS =
\
$(COVERAGE_CFLAGS)
virsh_SOURCES = \
- console.c console.h \
virsh.c virsh.h \
+ virsh-console.c virsh-console.h \
virsh-domain.c virsh-domain.h \
virsh-domain-monitor.c virsh-domain-monitor.h \
virsh-host.c virsh-host.h \
diff --git a/tools/console.c b/tools/virsh-console.c
similarity index 90%
rename from tools/console.c
rename to tools/virsh-console.c
index 6c24fcf..debf12c 100644
--- a/tools/console.c
+++ b/tools/virsh-console.c
@@ -1,7 +1,7 @@
/*
- * console.c: A dumb serial console client
+ * virsh-console.c: A dumb serial console client
*
- * Copyright (C) 2007-2008, 2010-2012 Red Hat, Inc.
+ * Copyright (C) 2007-2008, 2010-2013 Red Hat, Inc.
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
Not shown in the context, but there should be 'Authors:' line just above
Dan's name.
@@ -37,7 +37,7 @@
# include c-ctype.h
# include internal.h
-# include console.h
+# include virsh-console.h
# include virlog.h
# include virfile.h
# include viralloc.h
@@ -58,6 +58,7 @@ struct virConsoleBuffer {
char *data;
};
+
typedef struct virConsole virConsole;
typedef virConsole *virConsolePtr;
struct virConsole {
@@ -75,11 +76,15 @@ struct virConsole {
char escapeChar;
};
+
static int got_signal = 0;
-static void do_signal(int sig ATTRIBUTE_UNUSED) {
+static void
+virConsoleHandleSignal(int sig ATTRIBUTE_UNUSED)
+{
got_signal = 1;
}
+
# ifndef HAVE_CFMAKERAW
static void
cfmakeraw(struct termios *attr)
@@ -93,6 +98,7 @@ cfmakeraw(struct termios *attr)
}
# endif /* !HAVE_CFMAKERAW */
+
static void
virConsoleShutdown(virConsolePtr con)
{
@@ -114,6 +120,21 @@ virConsoleShutdown(virConsolePtr con)
virCondSignal(con-cond);
}
+
+static void
+virConsoleFree(virConsolePtr con)
+{
+if (!con)
+return;
+
+if (con-st)
+virStreamFree(con-st);
+virMutexDestroy(con-lock);
+virCondDestroy(con-cond);
+VIR_FREE(con);
+}
+
+
static void
virConsoleEventOnStream(virStreamPtr st,
int events, void *opaque)
@@ -171,9 +192,8 @@ virConsoleEventOnStream(virStreamPtr st,
avail = con-terminalToStream.length - con-terminalToStream.offset;
if (avail 1024) {
-if (VIR_REALLOC_N(con-terminalToStream.data,
- con-terminalToStream.offset + 1024) 0)
-{}
+ignore_value(VIR_REALLOC_N(con-terminalToStream.data,
+ con-terminalToStream.offset + 1024));
con-terminalToStream.length = con-terminalToStream.offset +
1024;
I don't think this is quite right. If the VIR_REALLOC fails, why are we
increasing the .lenght? I know this is
Re: [libvirt] [PATCH 1/3] tools: rename console.[ch] to virsh-console.[ch] and fix coding style
On 08/29/2013 06:36 PM, Peter Krempa wrote:
---
cfg.mk | 2 +-
po/POTFILES.in | 2 +-
tools/Makefile.am| 2 +-
tools/{console.c = virsh-console.c} | 73
++--
tools/{console.h = virsh-console.h} | 4 +-
tools/virsh-domain.c | 2 +-
tools/virsh.c| 2 +-
7 files changed, 52 insertions(+), 35 deletions(-)
rename tools/{console.c = virsh-console.c} (90%)
rename tools/{console.h = virsh-console.h} (91%)
ACK
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/3] virsh: Rename vshMakeStdinRaw to vshTTYMakeRaw and move it to virsh.c
On 08/29/2013 06:36 PM, Peter Krempa wrote:
Move the function to virsh.c to the rest of the TTY managing functions
and change the code so that it mirrors the rest.
---
tools/virsh-console.c | 50 +-
tools/virsh-console.h | 7 +++
tools/virsh-domain.c | 2 +-
tools/virsh.c | 48 +---
tools/virsh.h | 1 +
5 files changed, 55 insertions(+), 53 deletions(-)
diff --git a/tools/virsh-console.c b/tools/virsh-console.c
index debf12c..cc9cc6a 100644
--- a/tools/virsh-console.c
+++ b/tools/virsh-console.c
[...]
@@ -319,40 +306,13 @@ vshGetEscapeChar(const char *s)
int
-vshMakeStdinRaw(struct termios *ttyattr, bool report_errors)
-{
-struct termios rawattr;
-char ebuf[1024];
-
-if (tcgetattr(STDIN_FILENO, ttyattr) 0) {
-if (report_errors)
-VIR_ERROR(_(unable to get tty attributes: %s),
- virStrerror(errno, ebuf, sizeof(ebuf)));
-return -1;
-}
-
-rawattr = *ttyattr;
-cfmakeraw(rawattr);
-
-if (tcsetattr(STDIN_FILENO, TCSAFLUSH, rawattr) 0) {
-if (report_errors)
-VIR_ERROR(_(unable to set tty attributes: %s),
- virStrerror(errno, ebuf, sizeof(ebuf)));
-return -1;
-}
-
-return 0;
-}
-
-
-int
-vshRunConsole(virDomainPtr dom,
+vshRunConsole(vshControl *ctl,
+ virDomainPtr dom,
const char *dev_name,
const char *escape_seq,
You can get rid of this one since we call it with ctl-excapeChar only.
The rest looks ok, but Michal already ACK'd it, so...
Martin
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Add forwarders attribute to dns / element.
On 09/02/2013 07:50 AM, Diego Woitasen wrote: Useful to set custom forwarders instead of using the contents of /etc/resolv.conf. It helps me to setup dnsmasq as local nameserver to resolv VM domain names from domain 0, when domain option is used. Signed-off-by: Diego Woitasen diego.woita...@vhgroup.net --- src/conf/network_conf.c| 34 +- src/conf/network_conf.h| 1 + src/network/bridge_driver.c| 8 + .../nat-network-dns-forwarders.conf| 15 ++ .../nat-network-dns-forwarders.xml | 9 ++ tests/networkxml2conftest.c| 1 + 6 files changed, 67 insertions(+), 1 deletion(-) create mode 100644 tests/networkxml2confdata/nat-network-dns-forwarders.conf create mode 100644 tests/networkxml2confdata/nat-network-dns-forwarders.xml You also need to add documentation describing the new element (I agree with danpb's suggestion) to docs/formatnetwork.html.in, and expand the grammar in docs/schemas/network.rng. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Is it a problem that after virEventRegisterDefaultImpl we have handlers leaked
-Original Message-
From: Daniel P. Berrange [mailto:berra...@redhat.com]
Sent: Tuesday, September 03, 2013 5:14 PM
To: Wangyufei (A)
Cc: libvir-list@redhat.com; Wangrui (K)
Subject: Re: [libvirt] Is it a problem that after virEventRegisterDefaultImpl
we
have handlers leaked
On Mon, Sep 02, 2013 at 07:44:39AM +, Wangyufei (A) wrote:
Hello,
When I ran programme event-test compiled from event-test.c, I found a
problem that, after virEventRegisterDefaultImpl I do virConnectOpenAuth
and virConnectClose, there will be handlers of socket and pipe opened by
virConnectOpenAuth leaked after virConnectClose. So I did some analysis,
and I found the fact following:
In the condition that we only have one connection here
int virNetSocketAddIOCallback(virNetSocketPtr sock,
int events,
virNetSocketIOFunc func,
void *opaque,
virFreeCallback ff)
{
int ret = -1;
virObjectRef(sock); //Here we add sock refers once, then we will get
refers equal 2 after
virObjectLock(sock);
if (sock-watch 0) {
VIR_DEBUG(Watch already registered on socket %p, sock);
goto cleanup;
}
if ((sock-watch = virEventAddHandle(sock-fd, //If we have called
virEventRegisterDefaultImpl, then here we'll get a sock watch non negative
and will not go to cleanup.
events,
virNetSocketEventHandle,
sock,
virNetSocketEventFree))
0) {
VIR_DEBUG(Failed to register watch on socket %p, sock);
goto cleanup;
}
sock-func = func;
sock-opaque = opaque;
sock-ff = ff;
ret = 0;
cleanup:
virObjectUnlock(sock);
if (ret != 0)
virObjectUnref(sock); //If we haven't called
virEventRegisterDefaultImpl, we'll be here after virEventAddHandle, and
sock refers will decrease to 1
return ret;
}
Condition with virEventRegisterDefaultImpl, we'll do unrefer action in two
places:
1. virEventRunDefaultImpl -virEventPollRunOnce
-virEventRunDefaultImpl -virEventPollRunOnce
-virEventPollCleanupHandles - virNetSocketEventFree - virObjectUnref
2. virConnectClose -virObjectUnref -virConnectDispose
-remoteConnectClose -doRemoteClose -virNetClientClose
-virNetClientCloseInternal - virNetClientIOEventLoopPassTheBuck -
virNetClientCloseLocked - virObjectUnref
When event dealing loop is alive, everything work fine, we'll get sock
refers 2
after virConnectOpenAuth and unrefer twice in two places above after
virConnectClose.
But If some accidents happened like we quit event dealing loop or
virEventRunDefaultImpl
suspended, then sock refers will never be zero, and handlers will never be
freed.
Do not stop running the event loop. It is a requirement of the API that once
you have
called virEventRegisterDefaultImpl, you *must* always execute the event
loop forever
after until your application exits.
I consider to add something like virEventDeregisterDefaultImpl to set
addHandleImpl and his buddy NULL. Apparently it is far away from fixing it
completely.
No, stopping or de-registering event loop impls is a non-goal.
At last I have two questions here:
1. Is it a problem that after virEventRegisterDefaultImpl we have
handlers leaked?
There are no handlers leaked if you run the event loop, which is a
requirement
of the API.
Well, Is there any tiny chance that event loop stopped?
If that happened now, the handlers leak will affect the whole host OS, maybe no
handlers to use at last.
Is that what we expect?
Can we do something to reduce the impact even if something impossible happened?
Thanks a lot.
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 :|
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Is it a problem that after virEventRegisterDefaultImpl we have handlers leaked
On Tue, Sep 03, 2013 at 10:25:45AM +, Wangyufei (A) wrote:
-Original Message-
From: Daniel P. Berrange [mailto:berra...@redhat.com]
Sent: Tuesday, September 03, 2013 5:14 PM
To: Wangyufei (A)
Cc: libvir-list@redhat.com; Wangrui (K)
Subject: Re: [libvirt] Is it a problem that after
virEventRegisterDefaultImpl we
have handlers leaked
On Mon, Sep 02, 2013 at 07:44:39AM +, Wangyufei (A) wrote:
Hello,
When I ran programme event-test compiled from event-test.c, I found a
problem that, after virEventRegisterDefaultImpl I do virConnectOpenAuth
and virConnectClose, there will be handlers of socket and pipe opened by
virConnectOpenAuth leaked after virConnectClose. So I did some analysis,
and I found the fact following:
In the condition that we only have one connection here
int virNetSocketAddIOCallback(virNetSocketPtr sock,
int events,
virNetSocketIOFunc func,
void *opaque,
virFreeCallback ff)
{
int ret = -1;
virObjectRef(sock); //Here we add sock refers once, then we will get
refers equal 2 after
virObjectLock(sock);
if (sock-watch 0) {
VIR_DEBUG(Watch already registered on socket %p, sock);
goto cleanup;
}
if ((sock-watch = virEventAddHandle(sock-fd, //If we have called
virEventRegisterDefaultImpl, then here we'll get a sock watch non negative
and will not go to cleanup.
events,
virNetSocketEventHandle,
sock,
virNetSocketEventFree))
0) {
VIR_DEBUG(Failed to register watch on socket %p, sock);
goto cleanup;
}
sock-func = func;
sock-opaque = opaque;
sock-ff = ff;
ret = 0;
cleanup:
virObjectUnlock(sock);
if (ret != 0)
virObjectUnref(sock); //If we haven't called
virEventRegisterDefaultImpl, we'll be here after virEventAddHandle, and
sock refers will decrease to 1
return ret;
}
Condition with virEventRegisterDefaultImpl, we'll do unrefer action in two
places:
1. virEventRunDefaultImpl -virEventPollRunOnce
-virEventRunDefaultImpl -virEventPollRunOnce
-virEventPollCleanupHandles - virNetSocketEventFree - virObjectUnref
2. virConnectClose -virObjectUnref -virConnectDispose
-remoteConnectClose -doRemoteClose -virNetClientClose
-virNetClientCloseInternal - virNetClientIOEventLoopPassTheBuck -
virNetClientCloseLocked - virObjectUnref
When event dealing loop is alive, everything work fine, we'll get sock
refers 2
after virConnectOpenAuth and unrefer twice in two places above after
virConnectClose.
But If some accidents happened like we quit event dealing loop or
virEventRunDefaultImpl
suspended, then sock refers will never be zero, and handlers will never be
freed.
Do not stop running the event loop. It is a requirement of the API that once
you have
called virEventRegisterDefaultImpl, you *must* always execute the event
loop forever
after until your application exits.
I consider to add something like virEventDeregisterDefaultImpl to set
addHandleImpl and his buddy NULL. Apparently it is far away from fixing it
completely.
No, stopping or de-registering event loop impls is a non-goal.
At last I have two questions here:
1. Is it a problem that after virEventRegisterDefaultImpl we have
handlers leaked?
There are no handlers leaked if you run the event loop, which is a
requirement
of the API.
Well, Is there any tiny chance that event loop stopped?
If that happened now, the handlers leak will affect the whole host OS, maybe
no handlers to use at last.
Is that what we expect?
Can we do something to reduce the impact even if something impossible
happened?
If the event loop has bugs which cause it to stop then those
should be fixed. This isn't something we need / want to work
around elsewhere.
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 :|
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] test failure on rawhide
On 08/30/2013 11:26 PM, Eric Blake wrote: Just noticed this on latest rawhide (Fedora 21): Looks like the bug might not be libvirt's fault (as the assertion failure is not in our source file), but I'm out of time to investigate further today. $ VIR_TEST_DEBUG=1 ./virdrivermoduletest TEST: virdrivermoduletest 1) Test driver network ... OK 2) Test driver storage ... OK 3) Test driver nodedev ... OK 4) Test driver secret ... OK 5) Test driver nwfilter... OK 6) Test driver interface ... lt-virdrivermoduletest: route/tc.c:973: rtnl_tc_register: Assertion `0' failed. During the switch from libnl-1 to libnl-3, a similar (the same?) error meant that version of libnl used for the netcf build didn't match the version used for the libvirt build. That should be a thing of the distant past now though... -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Fix leaks in python bindings
https://bugzilla.redhat.com/show_bug.cgi?id=1003828 --- python/libvirt-lxc-override.c | 1 + python/libvirt-qemu-override.c | 3 +++ 2 files changed, 4 insertions(+) diff --git a/python/libvirt-lxc-override.c b/python/libvirt-lxc-override.c index fa7e963..f76ff4b 100644 --- a/python/libvirt-lxc-override.c +++ b/python/libvirt-lxc-override.c @@ -92,6 +92,7 @@ libvirt_lxc_virDomainLxcOpenNamespace(PyObject *self ATTRIBUTE_UNUSED, goto error; } } +VIR_FREE(fdlist); return py_retval; error: diff --git a/python/libvirt-qemu-override.c b/python/libvirt-qemu-override.c index 8f1ce5e..6249031 100644 --- a/python/libvirt-qemu-override.c +++ b/python/libvirt-qemu-override.c @@ -21,6 +21,7 @@ #include libvirt/virterror.h #include typewrappers.h #include libvirt-qemu.h +#include viralloc.h #ifndef __CYGWIN__ extern void initlibvirtmod_qemu(void); @@ -79,6 +80,7 @@ libvirt_qemu_virDomainQemuMonitorCommand(PyObject *self ATTRIBUTE_UNUSED, return VIR_PY_NONE; py_retval = PyString_FromString(result); +VIR_FREE(result); return py_retval; } @@ -108,6 +110,7 @@ libvirt_qemu_virDomainQemuAgentCommand(PyObject *self ATTRIBUTE_UNUSED, PyObject return VIR_PY_NONE; py_retval = PyString_FromString(result); +VIR_FREE(result); return py_retval; } / -- 1.8.1.5 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Add forwarders attribute to dns / element.
Yes, sorry. I've update that yesterday. Resent the patch but forgot to add the v2 suffix to the mail subject :( I'll resend it later this week with the v2 suffix if I don't receive feedback. May be it was discarded by that reason. Regards, Diego On Tue, Sep 3, 2013 at 7:15 AM, Laine Stump la...@laine.org wrote: On 09/02/2013 07:50 AM, Diego Woitasen wrote: Useful to set custom forwarders instead of using the contents of /etc/resolv.conf. It helps me to setup dnsmasq as local nameserver to resolv VM domain names from domain 0, when domain option is used. Signed-off-by: Diego Woitasen diego.woita...@vhgroup.net --- src/conf/network_conf.c| 34 +- src/conf/network_conf.h| 1 + src/network/bridge_driver.c| 8 + .../nat-network-dns-forwarders.conf| 15 ++ .../nat-network-dns-forwarders.xml | 9 ++ tests/networkxml2conftest.c| 1 + 6 files changed, 67 insertions(+), 1 deletion(-) create mode 100644 tests/networkxml2confdata/nat-network-dns-forwarders.conf create mode 100644 tests/networkxml2confdata/nat-network-dns-forwarders.xml You also need to add documentation describing the new element (I agree with danpb's suggestion) to docs/formatnetwork.html.in, and expand the grammar in docs/schemas/network.rng. -- Diego Woitasen VHGroup - Lead Linux and open source solutions architect www.vhgroup.net -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Re: RFC: Splitting python binding out into a separate repo ading to PyPi
The 29/08/13, Eric Blake wrote: On 08/29/2013 05:24 AM, Daniel P. Berrange wrote: I don't think these issues are going to go away, in fact I think they will likely become more pressing, until the point where some 3rd party takes the step of providing libvirt python bindings themselves. I don't think we want to let ourselves drift into the situation where we loose control over releasing libvirt python bindings. Splitting the python bindings into their own project makes sense to me. We've got enough interest in python on this list that I'm not too worried about enforcing that new APIs to the main project be accompanied with patches to libvirt-python.git, and keep up with a release of the bindings for each upstream release. I'm a bit out of topic but I feel good benefits with the APIs having its own releases. Notice I'm talking about the APIs. What makes it hard for small projects to use the python bindings are the API changes (up to the point that I don't use them). I guess this issue will stand as long as the APIs keep highly tied to the python bindings. In order to get smart backward and forward compatible APIs, I guess it would make sense to decorelate them from the low level bindings. Introducing a new interface API - bindings could do the job of checking the bindings version and make the correct bindings calls. Perhaps it would worth the trouble to initiate a new project for such a public API? I think this is another way to solve the issues of this request, plus the benefits of provinding a very stable public API. -- Nicolas Sebrecht -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Fix leaks in python bindings
On 09/03/13 13:19, Ján Tomko wrote: https://bugzilla.redhat.com/show_bug.cgi?id=1003828 --- python/libvirt-lxc-override.c | 1 + python/libvirt-qemu-override.c | 3 +++ 2 files changed, 4 insertions(+) ACK. Peter signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Fix leaks in python bindings
On 09/03/2013 01:35 PM, Peter Krempa wrote: On 09/03/13 13:19, Ján Tomko wrote: https://bugzilla.redhat.com/show_bug.cgi?id=1003828 --- python/libvirt-lxc-override.c | 1 + python/libvirt-qemu-override.c | 3 +++ 2 files changed, 4 insertions(+) ACK. Peter Thanks, pushed. Jan -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] RFC: Splitting python binding out into a separate repo ading to PyPi
On Tue, Sep 03, 2013 at 01:27:50PM +0200, Nicolas Sebrecht wrote: The 29/08/13, Eric Blake wrote: On 08/29/2013 05:24 AM, Daniel P. Berrange wrote: I don't think these issues are going to go away, in fact I think they will likely become more pressing, until the point where some 3rd party takes the step of providing libvirt python bindings themselves. I don't think we want to let ourselves drift into the situation where we loose control over releasing libvirt python bindings. Splitting the python bindings into their own project makes sense to me. We've got enough interest in python on this list that I'm not too worried about enforcing that new APIs to the main project be accompanied with patches to libvirt-python.git, and keep up with a release of the bindings for each upstream release. I'm a bit out of topic but I feel good benefits with the APIs having its own releases. Notice I'm talking about the APIs. What makes it hard for small projects to use the python bindings are the API changes (up to the point that I don't use them). I guess this issue will stand as long as the APIs keep highly tied to the python bindings. Err, what API changes are you talking about ? Both the libvirt C API, and any language bindings, including the python, are intended to be long term stable APIs. We only ever add new APIs or flags - never change existing APis. 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 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Add forwarders attribute to dns / element.
On 09/03/2013 07:21 AM, Diego Woitasen wrote: Yes, sorry. I've update that yesterday. Resent the patch but forgot to add the v2 suffix to the mail subject :( I'll resend it later this week with the v2 suffix if I don't receive feedback. May be it was discarded by that reason. Nah, I was just catching up on 5 days of vacation mail, and didn't notice the newer version of the patch until after I'd already replied to the first. It's of course better to put Patchv2 on the V2 of a patch, but not necessary to resend just for that reason. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 2/2] esx_driver: Resolve Coverity RESOURCE_LEAK on error paths
New Coverity release found a couple of error paths where memory would be
leaked in an error/goto path before being properly handled.
---
src/esx/esx_driver.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/esx/esx_driver.c b/src/esx/esx_driver.c
index 3ea2dd1..13423d0 100644
--- a/src/esx/esx_driver.c
+++ b/src/esx/esx_driver.c
@@ -3393,7 +3393,6 @@ esxDomainSetAutostart(virDomainPtr domain, int autostart)
esxVI_AutoStartPowerInfo *powerInfoList = NULL;
esxVI_AutoStartPowerInfo *powerInfo = NULL;
esxVI_AutoStartPowerInfo *newPowerInfo = NULL;
-bool newPowerInfo_isAppended = false;
if (esxVI_EnsureSession(priv-primary) 0) {
return -1;
@@ -3468,7 +3467,7 @@ esxDomainSetAutostart(virDomainPtr domain, int autostart)
goto cleanup;
}
-newPowerInfo_isAppended = true;
+newPowerInfo = NULL;
if (esxVI_ReconfigureAutostart
(priv-primary,
@@ -3491,9 +3490,7 @@ esxDomainSetAutostart(virDomainPtr domain, int autostart)
esxVI_AutoStartDefaults_Free(defaults);
esxVI_AutoStartPowerInfo_Free(powerInfoList);
-if (!newPowerInfo_isAppended) {
-esxVI_AutoStartPowerInfo_Free(newPowerInfo);
-}
+esxVI_AutoStartPowerInfo_Free(newPowerInfo);
return result;
}
@@ -3640,6 +3637,7 @@ esxDomainGetSchedulerParametersFlags(virDomainPtr domain,
virReportError(VIR_ERR_INTERNAL_ERROR,
_(Shares level has unknown value %d),
(int)sharesInfo-level);
+esxVI_SharesInfo_Free(sharesInfo);
goto cleanup;
}
@@ -3743,6 +3741,7 @@ esxDomainSetSchedulerParametersFlags(virDomainPtr domain,
}
spec-cpuAllocation-shares = sharesInfo;
+sharesInfo = NULL;
if (params[i].value.i = 0) {
spec-cpuAllocation-shares-level = esxVI_SharesLevel_Custom;
@@ -3796,6 +3795,7 @@ esxDomainSetSchedulerParametersFlags(virDomainPtr domain,
result = 0;
cleanup:
+esxVI_SharesInfo_Free(sharesInfo);
esxVI_ObjectContent_Free(virtualMachine);
esxVI_VirtualMachineConfigSpec_Free(spec);
esxVI_ManagedObjectReference_Free(task);
--
1.8.3.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 0/2] Handle a couple of new Coverity warnings
Coverity 6.6.1 was recently made available - installed it and a couple more RESOURCE_LEAK's were found in error paths. John Ferlan (2): esx_vi: Resolve Coverity RESOURCE_LEAK in error path esx_driver: Resolve Coverity RESOURCE_LEAK on error paths src/esx/esx_driver.c | 10 +- src/esx/esx_vi.c | 14 ++ 2 files changed, 19 insertions(+), 5 deletions(-) -- 1.8.3.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 1/2] esx_vi: Resolve Coverity RESOURCE_LEAK in error path
New coverity installation determined that the muliple if condition for
*Alloc and *AppendToList could fail during AppendToList thus leaking
memory.
---
src/esx/esx_vi.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/src/esx/esx_vi.c b/src/esx/esx_vi.c
index 1187bf3..ad1b5dc 100644
--- a/src/esx/esx_vi.c
+++ b/src/esx/esx_vi.c
@@ -3524,6 +3524,7 @@ esxVI_LookupFileInfoByDatastorePath(esxVI_Context *ctx,
esxVI_FileQuery_DynamicCast(folderFileQuery)) 0) {
goto cleanup;
}
+folderFileQuery = NULL;
} else {
if (esxVI_VmDiskFileQuery_Alloc(vmDiskFileQuery) 0 ||
esxVI_VmDiskFileQueryFlags_Alloc(vmDiskFileQuery-details) 0 ||
@@ -3538,6 +3539,7 @@ esxVI_LookupFileInfoByDatastorePath(esxVI_Context *ctx,
vmDiskFileQuery-details-hardwareVersion = esxVI_Boolean_False;
vmDiskFileQuery-details-controllerType = esxVI_Boolean_True;
vmDiskFileQuery-details-diskExtents = esxVI_Boolean_False;
+vmDiskFileQuery = NULL;
if (esxVI_IsoImageFileQuery_Alloc(isoImageFileQuery) 0 ||
esxVI_FileQuery_AppendToList
@@ -3545,6 +3547,7 @@ esxVI_LookupFileInfoByDatastorePath(esxVI_Context *ctx,
esxVI_FileQuery_DynamicCast(isoImageFileQuery)) 0) {
goto cleanup;
}
+isoImageFileQuery = NULL;
if (esxVI_FloppyImageFileQuery_Alloc(floppyImageFileQuery) 0 ||
esxVI_FileQuery_AppendToList
@@ -3552,6 +3555,7 @@ esxVI_LookupFileInfoByDatastorePath(esxVI_Context *ctx,
esxVI_FileQuery_DynamicCast(floppyImageFileQuery)) 0) {
goto cleanup;
}
+floppyImageFileQuery = NULL;
}
if (esxVI_String_Alloc(searchSpec-matchPattern) 0) {
@@ -3621,6 +3625,10 @@ esxVI_LookupFileInfoByDatastorePath(esxVI_Context *ctx,
VIR_FREE(taskInfoErrorMessage);
esxVI_TaskInfo_Free(taskInfo);
esxVI_HostDatastoreBrowserSearchResults_Free(searchResults);
+esxVI_FolderFileQuery_Free(folderFileQuery);
+esxVI_VmDiskFileQuery_Free(vmDiskFileQuery);
+esxVI_IsoImageFileQuery_Free(isoImageFileQuery);
+esxVI_FloppyImageFileQuery_Free(floppyImageFileQuery);
return result;
}
@@ -3685,6 +3693,7 @@ esxVI_LookupDatastoreContentByDatastoreName
vmDiskFileQuery-details-hardwareVersion = esxVI_Boolean_False;
vmDiskFileQuery-details-controllerType = esxVI_Boolean_True;
vmDiskFileQuery-details-diskExtents = esxVI_Boolean_False;
+vmDiskFileQuery = NULL;
if (esxVI_IsoImageFileQuery_Alloc(isoImageFileQuery) 0 ||
esxVI_FileQuery_AppendToList
@@ -3692,6 +3701,7 @@ esxVI_LookupDatastoreContentByDatastoreName
esxVI_FileQuery_DynamicCast(isoImageFileQuery)) 0) {
goto cleanup;
}
+isoImageFileQuery = NULL;
if (esxVI_FloppyImageFileQuery_Alloc(floppyImageFileQuery) 0 ||
esxVI_FileQuery_AppendToList
@@ -3699,6 +3709,7 @@ esxVI_LookupDatastoreContentByDatastoreName
esxVI_FileQuery_DynamicCast(floppyImageFileQuery)) 0) {
goto cleanup;
}
+floppyImageFileQuery = NULL;
/* Search datastore for files */
if (virAsprintf(datastorePath, [%s], datastoreName) 0)
@@ -3737,6 +3748,9 @@ esxVI_LookupDatastoreContentByDatastoreName
esxVI_ManagedObjectReference_Free(task);
VIR_FREE(taskInfoErrorMessage);
esxVI_TaskInfo_Free(taskInfo);
+esxVI_VmDiskFileQuery_Free(vmDiskFileQuery);
+esxVI_IsoImageFileQuery_Free(isoImageFileQuery);
+esxVI_FloppyImageFileQuery_Free(floppyImageFileQuery);
return result;
}
--
1.8.3.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 3/5] qemu: add usb-bot support from disks points of view
Hi,
How does this work if we start off a guest with 3 disks
attached to the usb-bot SCSI controller. Then hot-unplug
the 2nd disk.
You can't hotplug individual luns anyway.
How does hotplug/unplug work in the context of usb-bot ?
AFAIK we need to be able to run
device_add usb_bot
drive_add file...
device_add scsi-hd
And the reverse, to unplug it, if we're to have feature parity with
usb-storage.
Hot-unplug is easy. You can remove the usb-bot device which will also
remove all child devices.
Hot-plug doesn't work at the moment, and I don't see any obvious way to
fix that properly :-(
We need some way to hotplug a *group* of devices (usb-bot + all
children) as usb-bot itself is hotpluggable but the individual scsi
devices connected to it are not.
I could allow hotplug on usb-bot as workaround, then you can do
stop
device_add usb_bot
device_add scsi-{hd,cd,whatever}
cont
but that would be more a gross hack than a solution ...
cheers,
Gerd
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/3] tools: rename console.[ch] to virsh-console.[ch] and fix coding style
On 09/03/13 11:44, Michal Privoznik wrote:
On 29.08.2013 18:36, Peter Krempa wrote:
---
cfg.mk | 2 +-
po/POTFILES.in | 2 +-
tools/Makefile.am| 2 +-
tools/{console.c = virsh-console.c} | 73
++--
tools/{console.h = virsh-console.h} | 4 +-
tools/virsh-domain.c | 2 +-
tools/virsh.c| 2 +-
7 files changed, 52 insertions(+), 35 deletions(-)
rename tools/{console.c = virsh-console.c} (90%)
rename tools/{console.h = virsh-console.h} (91%)
...
diff --git a/tools/console.c b/tools/virsh-console.c
similarity index 90%
rename from tools/console.c
rename to tools/virsh-console.c
index 6c24fcf..debf12c 100644
--- a/tools/console.c
+++ b/tools/virsh-console.c
@@ -1,7 +1,7 @@
/*
- * console.c: A dumb serial console client
+ * virsh-console.c: A dumb serial console client
*
- * Copyright (C) 2007-2008, 2010-2012 Red Hat, Inc.
+ * Copyright (C) 2007-2008, 2010-2013 Red Hat, Inc.
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
Not shown in the context, but there should be 'Authors:' line just above
Dan's name.
Okay, added.
...
@@ -171,9 +192,8 @@ virConsoleEventOnStream(virStreamPtr st,
avail = con-terminalToStream.length - con-terminalToStream.offset;
if (avail 1024) {
-if (VIR_REALLOC_N(con-terminalToStream.data,
- con-terminalToStream.offset + 1024) 0)
-{}
+ignore_value(VIR_REALLOC_N(con-terminalToStream.data,
+ con-terminalToStream.offset +
1024));
con-terminalToStream.length = con-terminalToStream.offset +
1024;
I don't think this is quite right. If the VIR_REALLOC fails, why are we
increasing the .lenght? I know this is pre-existing, but if we are
touching this we should fix this.
This is actually decreasing the size of the allocated memory. It's hard
to see here, but if there's more than 1024 bytes left free in the
buffer, the size is decreased to exactly 1024 extra bytes. Thus this
call should be always safe and I just changed the way the result from
VIR_REALLOC is ignored.
}
}
...
diff --git a/tools/console.h b/tools/virsh-console.h
similarity index 91%
rename from tools/console.h
rename to tools/virsh-console.h
index 46255b8..96ef235 100644
--- a/tools/console.h
+++ b/tools/virsh-console.h
@@ -1,7 +1,7 @@
/*
- * console.c: A dumb serial console client
+ * virsh-console.h: A dumb serial console client
*
- * Copyright (C) 2007, 2010, 2012 Red Hat, Inc.
+ * Copyright (C) 2007, 2010, 2012-2013 Red Hat, Inc.
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
Not shown in the context, but there should be 'Authors:' line just above
Dan's name.
Okay, done.
diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c
index c87cf6a..60eed51 100644
--- a/tools/virsh-domain.c
+++ b/tools/virsh-domain.c
@@ -41,7 +41,7 @@
#include virbuffer.h
#include c-ctype.h
#include conf/domain_conf.h
-#include console.h
+#include virsh-console.h
This should go a few lines down, just before the line:
Fixed.
#include virsh-domain-monitor.h
#include viralloc.h
#include vircommand.h
#include virfile.h
diff --git a/tools/virsh.c b/tools/virsh.c
index 2f04e6a..0cc9bdd 100644
--- a/tools/virsh.c
+++ b/tools/virsh.c
@@ -57,7 +57,6 @@
#include virerror.h
#include base64.h
#include virbuffer.h
-#include console.h
#include viralloc.h
#include virxml.h
#include libvirt/libvirt-qemu.h
@@ -73,6 +72,7 @@
#include virtypedparam.h
#include virstring.h
+#include virsh-console.h
#include virsh-domain.h
#include virsh-domain-monitor.h
#include virsh-host.h
I've pointed a few issues but I believe that you will fix them right so
I don't need to see a v2.
ACK
Michal
And pushed.
Peter
signature.asc
Description: OpenPGP digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/3] virsh: Rename vshMakeStdinRaw to vshTTYMakeRaw and move it to virsh.c
On 09/03/13 12:02, Martin Kletzander wrote:
On 08/29/2013 06:36 PM, Peter Krempa wrote:
Move the function to virsh.c to the rest of the TTY managing functions
and change the code so that it mirrors the rest.
---
tools/virsh-console.c | 50
+-
tools/virsh-console.h | 7 +++
tools/virsh-domain.c | 2 +-
tools/virsh.c | 48 +---
tools/virsh.h | 1 +
5 files changed, 55 insertions(+), 53 deletions(-)
diff --git a/tools/virsh-console.c b/tools/virsh-console.c
index debf12c..cc9cc6a 100644
--- a/tools/virsh-console.c
+++ b/tools/virsh-console.c
[...]
@@ -319,40 +306,13 @@ vshGetEscapeChar(const char *s)
int
-vshMakeStdinRaw(struct termios *ttyattr, bool report_errors)
-{
-struct termios rawattr;
-char ebuf[1024];
-
-if (tcgetattr(STDIN_FILENO, ttyattr) 0) {
-if (report_errors)
-VIR_ERROR(_(unable to get tty attributes: %s),
- virStrerror(errno, ebuf, sizeof(ebuf)));
-return -1;
-}
-
-rawattr = *ttyattr;
-cfmakeraw(rawattr);
-
-if (tcsetattr(STDIN_FILENO, TCSAFLUSH, rawattr) 0) {
-if (report_errors)
-VIR_ERROR(_(unable to set tty attributes: %s),
- virStrerror(errno, ebuf, sizeof(ebuf)));
-return -1;
-}
-
-return 0;
-}
-
-
-int
-vshRunConsole(virDomainPtr dom,
+vshRunConsole(vshControl *ctl,
+ virDomainPtr dom,
const char *dev_name,
const char *escape_seq,
You can get rid of this one since we call it with ctl-excapeChar only.
The rest looks ok, but Michal already ACK'd it, so...
Right, I removed the parameter and pushed the rest of the series. Thanks.
Peter
signature.asc
Description: OpenPGP digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Is it a problem that after virEventRegisterDefaultImpl we have handlers leaked
-Original Message-
From: Daniel P. Berrange [mailto:berra...@redhat.com]
Sent: Tuesday, September 03, 2013 6:30 PM
To: Wangyufei (A)
Cc: libvir-list@redhat.com; Wangrui (K)
Subject: Re: [libvirt] Is it a problem that after virEventRegisterDefaultImpl
we
have handlers leaked
On Tue, Sep 03, 2013 at 10:25:45AM +, Wangyufei (A) wrote:
-Original Message-
From: Daniel P. Berrange [mailto:berra...@redhat.com]
Sent: Tuesday, September 03, 2013 5:14 PM
To: Wangyufei (A)
Cc: libvir-list@redhat.com; Wangrui (K)
Subject: Re: [libvirt] Is it a problem that after
virEventRegisterDefaultImpl
we
have handlers leaked
On Mon, Sep 02, 2013 at 07:44:39AM +, Wangyufei (A) wrote:
Hello,
When I ran programme event-test compiled from event-test.c, I found
a
problem that, after virEventRegisterDefaultImpl I do
virConnectOpenAuth
and virConnectClose, there will be handlers of socket and pipe opened by
virConnectOpenAuth leaked after virConnectClose. So I did some
analysis,
and I found the fact following:
In the condition that we only have one connection here
int virNetSocketAddIOCallback(virNetSocketPtr sock,
int events,
virNetSocketIOFunc func,
void *opaque,
virFreeCallback ff)
{
int ret = -1;
virObjectRef(sock); //Here we add sock refers once, then we will
get
refers equal 2 after
virObjectLock(sock);
if (sock-watch 0) {
VIR_DEBUG(Watch already registered on socket %p, sock);
goto cleanup;
}
if ((sock-watch = virEventAddHandle(sock-fd, //If we have
called
virEventRegisterDefaultImpl, then here we'll get a sock watch non
negative
and will not go to cleanup.
events,
virNetSocketEventHandle,
sock,
virNetSocketEventFree))
0) {
VIR_DEBUG(Failed to register watch on socket %p, sock);
goto cleanup;
}
sock-func = func;
sock-opaque = opaque;
sock-ff = ff;
ret = 0;
cleanup:
virObjectUnlock(sock);
if (ret != 0)
virObjectUnref(sock); //If we haven't called
virEventRegisterDefaultImpl, we'll be here after virEventAddHandle, and
sock refers will decrease to 1
return ret;
}
Condition with virEventRegisterDefaultImpl, we'll do unrefer action in
two
places:
1. virEventRunDefaultImpl -virEventPollRunOnce
-virEventRunDefaultImpl -virEventPollRunOnce
-virEventPollCleanupHandles - virNetSocketEventFree -
virObjectUnref
2. virConnectClose -virObjectUnref -virConnectDispose
-remoteConnectClose -doRemoteClose -virNetClientClose
-virNetClientCloseInternal - virNetClientIOEventLoopPassTheBuck -
virNetClientCloseLocked - virObjectUnref
When event dealing loop is alive, everything work fine, we'll get sock
refers 2
after virConnectOpenAuth and unrefer twice in two places above after
virConnectClose.
But If some accidents happened like we quit event dealing loop or
virEventRunDefaultImpl
suspended, then sock refers will never be zero, and handlers will never
be
freed.
Do not stop running the event loop. It is a requirement of the API that
once
you have
called virEventRegisterDefaultImpl, you *must* always execute the
event
loop forever
after until your application exits.
I consider to add something like virEventDeregisterDefaultImpl to set
addHandleImpl and his buddy NULL. Apparently it is far away from fixing
it
completely.
No, stopping or de-registering event loop impls is a non-goal.
At last I have two questions here:
1. Is it a problem that after virEventRegisterDefaultImpl we
have
handlers leaked?
There are no handlers leaked if you run the event loop, which is a
requirement
of the API.
Well, Is there any tiny chance that event loop stopped?
If that happened now, the handlers leak will affect the whole host OS,
maybe no handlers to use at last.
Is that what we expect?
Can we do something to reduce the impact even if something impossible
happened?
If the event loop has bugs which cause it to stop then those
should be fixed. This isn't something we need / want to work
around elsewhere.
Fine, thanks a lot.
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 :|
--
libvir-list mailing list
libvir-list@redhat.com
Re: [libvirt] RFC: Splitting python binding out into a separate repo ading to PyPi
On Tue, Sep 03, 2013 at 02:13:58PM +0200, Nicolas Sebrecht wrote: The 03/09/13, Daniel P. Berrange wrote: Err, what API changes are you talking about ? Both the libvirt C API, and any language bindings, including the python, are intended to be long term stable APIs. We only ever add new APIs or flags - never change existing APis. I can't give a precise example, sorry. I had a wrong surprise in the late 2010 and since kept far from the python bindings. I might change to rely on the bindings if you actually think APIs are long term stable. They have always been stable will continue to be stable. Of course sometimes there may be bugs in particular releases that get fixed, but that's normal would not be changing the semantics of the APIs in an backwards-incompatible manner. 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 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/2] esx_vi: Resolve Coverity RESOURCE_LEAK in error path
2013/9/3 John Ferlan jfer...@redhat.com: New coverity installation determined that the muliple if condition for *Alloc and *AppendToList could fail during AppendToList thus leaking memory. --- src/esx/esx_vi.c | 14 ++ 1 file changed, 14 insertions(+) ACK. -- Matthias Bolte http://photron.blogspot.com -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Re: RFC: Splitting python binding out into a separate repo ading to PyPi
The 03/09/13, Daniel P. Berrange wrote: Err, what API changes are you talking about ? Both the libvirt C API, and any language bindings, including the python, are intended to be long term stable APIs. We only ever add new APIs or flags - never change existing APis. I can't give a precise example, sorry. I had a wrong surprise in the late 2010 and since kept far from the python bindings. I might change to rely on the bindings if you actually think APIs are long term stable. -- Nicolas Sebrecht -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/2] esx_driver: Resolve Coverity RESOURCE_LEAK on error paths
2013/9/3 John Ferlan jfer...@redhat.com: New Coverity release found a couple of error paths where memory would be leaked in an error/goto path before being properly handled. --- src/esx/esx_driver.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) ACK. -- Matthias Bolte http://photron.blogspot.com -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] examples: Add script to parse topology from capabilities output
On 09/03/13 11:15, Martin Kletzander wrote:
On 09/02/2013 04:57 PM, Peter Krempa wrote:
Add a demo script originally written by Amador Pahim to parse topology
of the host from data provided in the capabilities XML.
---
examples/python/topology.py | 45
+
1 file changed, 45 insertions(+)
create mode 100755 examples/python/topology.py
diff --git a/examples/python/topology.py b/examples/python/topology.py
new file mode 100755
index 000..1b678bc
--- /dev/null
+++ b/examples/python/topology.py
...
+
+print Host topology
+print NUMA nodes:, cells.getAttribute('num')
+printSockets:,len(set(socketIds))
+print Cores:,len(set(siblingsIds))
+printThreads:,total_cpus
I won't get into details like len() vs. .length, string formatting, etc.
;-) But please add a space after these commas.
Hmmm, yeah. My python skills are very weak :/. But as an example, this
should be kind of okay :/
I've added the spaces
Even though I don't know how this will turn out on those weird
multi-processor per core and similar architectures/processors, it should
turn out OK since you're the one who should know how those will look in
the capabilities XML.
It would be also worth adding it into specfile like other python
examples (I'm guessing those are in libvirt-python).
and added the script to examples/python/Makefile.am. The specfile seems
to automatically add all the example python scripts.
ACK with those two things fixed,
Pushed; Thanks.
Martin
Peter
signature.asc
Description: OpenPGP digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv5 1/5] domifaddr: Implement the public APIs
On 01/09/13 21:43, Nehal J Wani wrote: Define a new API virDomainInterfaceAddresses, which returns the address information of a running domain's interfaces(s). If no interface name is specified, it returns the information of all interfaces, otherwise it only returns the information of the specificed interface. The address information includes the MAC and IP addresses. This API only returns all of the interfaces' address info, it doesn't take an argument to specify an interface. My bad though, didn't find it out in previous reviewing. ACK with the commit log fixed. Osier -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv5 2/5] domifaddr: Implement the remote protocol
On 03/09/13 15:00, Nehal J Wani wrote:
On Mon, Sep 2, 2013 at 5:11 PM, Daniel P. Berrange berra...@redhat.com wrote:
On Sun, Sep 01, 2013 at 07:13:32PM +0530, Nehal J Wani wrote:
daemon/remote.c
* Define remoteSerializeDomainInterface,
remoteDispatchDomainInterfaceAddresses
src/remote/remote_driver.c
* Define remoteDomainInterfaceAddresses
src/remote/remote_protocol.x
* New RPC procedure: REMOTE_PROC_DOMAIN_INTERFACE_ADDRESSES
* Define structs remote_domain_ip_addr, remote_domain_interface,
remote_domain_interfaces_addresse_args,
remote_domain_interface_addresses_ret
* Introduce upper bounds (to handle DDoS attacks):
REMOTE_DOMAIN_INTERFACE_MAX = 2048
REMOTE_DOMAIN_IP_ADDR_MAX = 2048
Restrictions on the maximum number of aliases per interface were
removed after kernel v2.0, and theoretically, at present, there
are no upper limits on number of interfaces per virtual machine
and on the number of IP addresses per interface.
src/remote_protocol-structs
* New structs added
---
daemon/remote.c | 131 +++
src/remote/remote_driver.c | 99
src/remote/remote_protocol.x | 40 -
src/remote_protocol-structs | 24
4 files changed, 293 insertions(+), 1 deletion(-)
diff --git a/daemon/remote.c b/daemon/remote.c
index 6ace7af..7091cab 100644
--- a/daemon/remote.c
+++ b/daemon/remote.c
@@ -5144,7 +5144,138 @@ cleanup:
+
+static int
+remoteDispatchDomainInterfaceAddresses(
+virNetServerPtr server ATTRIBUTE_UNUSED,
+virNetServerClientPtr client,
+virNetMessagePtr msg ATTRIBUTE_UNUSED,
+virNetMessageErrorPtr rerr,
+remote_domain_interface_addresses_args *args,
+remote_domain_interface_addresses_ret *ret)
Normal practice for this file is to layout args thus:
static int
remoteDispatchDomainInterfaceAddresses(virNetServerPtr server
ATTRIBUTE_UNUSED,
virNetServerClientPtr client,
virNetMessagePtr msg ATTRIBUTE_UNUSED,
virNetMessageErrorPtr rerr,
remote_domain_interface_addresses_args
*args,
remote_domain_interface_addresses_ret
*ret)
ACK if the style issue is fixed
Style issue fix (File attached):
diff --git a/daemon/remote.c b/daemon/remote.c
index 7091cab..d46e3ea 100644
--- a/daemon/remote.c
+++ b/daemon/remote.c
@@ -5230,13 +5230,12 @@ cleanup:
}
static int
-remoteDispatchDomainInterfaceAddresses(
-virNetServerPtr server ATTRIBUTE_UNUSED,
-virNetServerClientPtr client,
-virNetMessagePtr msg ATTRIBUTE_UNUSED,
-virNetMessageErrorPtr rerr,
-remote_domain_interface_addresses_args *args,
-remote_domain_interface_addresses_ret *ret)
+remoteDispatchDomainInterfaceAddresses(virNetServerPtr server ATTRIBUTE_UNUSED,
+ virNetServerClientPtr client,
+ virNetMessagePtr msg ATTRIBUTE_UNUSED,
+ virNetMessageErrorPtr rerr,
+
remote_domain_interface_addresses_args *args,
+
remote_domain_interface_addresses_ret *ret)
{
size_t i;
int rv = -1;
PS: IMO, other functions like remoteDispatchDomainCreateWithFiles,
remoteDispatchDomainCreateXMLWithFiles,
remoteDispatchDomainMigrateFinish3Params, etc also need same style
change
I don't see problem with the diff applied. Patch is welcomed for the other
style problems.
Osier
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 3/5] qemu: add usb-bot support from disks points of view
On 09/03/2013 08:06 AM, Gerd Hoffmann wrote:
Hi,
How does this work if we start off a guest with 3 disks
attached to the usb-bot SCSI controller. Then hot-unplug
the 2nd disk.
You can't hotplug individual luns anyway.
How does hotplug/unplug work in the context of usb-bot ?
AFAIK we need to be able to run
device_add usb_bot
drive_add file...
device_add scsi-hd
And the reverse, to unplug it, if we're to have feature parity with
usb-storage.
Hot-unplug is easy. You can remove the usb-bot device which will also
remove all child devices.
Hot-plug doesn't work at the moment, and I don't see any obvious way to
fix that properly :-(
We need some way to hotplug a *group* of devices (usb-bot + all
children) as usb-bot itself is hotpluggable but the individual scsi
devices connected to it are not.
There is another case where hot-plug/unplug of a group of devices would
be useful - if you want to hotplug/unplug a pci passthrough device using
vfio *and* that device is a part of an iommu group that contains other
devices *and* you're okay with having those other devices assigned to
the guest as well *AND* you want to use managed='yes' (where libvirt
automatically unbinds the devices from the host driver and binds them to
vfio-pci before passing them off to the guest), then you need to be able
to plug and unplug all the devices in that iommu group in a single
operation, otherwise the plug fails (due to attempting to assign one
device in a group when the other devices haven't been bound to vfio-pci
or pci-stub). As it stands now you can only hot-plug/unplug with vfio if
a device is in an iommu group all by itself, or if you don't use
managed='yes', and instead deal with binding the devices to vfio-pci
manually.
If none of that makes sense, consider yourself lucky :-)
I could allow hotplug on usb-bot as workaround, then you can do
stop
device_add usb_bot
device_add scsi-{hd,cd,whatever}
cont
but that would be more a gross hack than a solution ...
cheers,
Gerd
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] qemu: Make domain renaming work during migration
https://bugzilla.redhat.com/show_bug.cgi?id=999352
Since commit v1.0.5-56-g449e6b1 (Pull parsing of migration xml up into
QEMU driver APIs) any attempt to rename a domain during migration fails
with the following error message:
internal error Incoming cookie data had unexpected name DOM vs DOM2
This is because migration cookies always use the original domain name
and the mentioned commit failed to propagate the name back to
qemuMigrationPrepareAny.
---
src/qemu/qemu_driver.c| 36
src/qemu/qemu_migration.c | 31 +++
src/qemu/qemu_migration.h | 5 -
3 files changed, 47 insertions(+), 25 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index ed29373..52ca906 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -9973,6 +9973,7 @@ qemuDomainMigratePrepareTunnel(virConnectPtr dconn,
{
virQEMUDriverPtr driver = dconn-privateData;
virDomainDefPtr def = NULL;
+char *origname = NULL;
int ret = -1;
virCheckFlags(QEMU_MIGRATION_FLAGS, -1);
@@ -9990,7 +9991,7 @@ qemuDomainMigratePrepareTunnel(virConnectPtr dconn,
goto cleanup;
}
-if (!(def = qemuMigrationPrepareDef(driver, dom_xml, dname)))
+if (!(def = qemuMigrationPrepareDef(driver, dom_xml, dname, origname)))
goto cleanup;
if (virDomainMigratePrepareTunnelEnsureACL(dconn, def) 0)
@@ -9998,9 +,10 @@ qemuDomainMigratePrepareTunnel(virConnectPtr dconn,
ret = qemuMigrationPrepareTunnel(driver, dconn,
NULL, 0, NULL, NULL, /* No cookies in v2
*/
- st, def, flags);
+ st, def, origname, flags);
cleanup:
+VIR_FREE(origname);
virDomainDefFree(def);
return ret;
}
@@ -10022,6 +10024,7 @@ qemuDomainMigratePrepare2(virConnectPtr dconn,
{
virQEMUDriverPtr driver = dconn-privateData;
virDomainDefPtr def = NULL;
+char *origname = NULL;
int ret = -1;
virCheckFlags(QEMU_MIGRATION_FLAGS, -1);
@@ -10043,7 +10046,7 @@ qemuDomainMigratePrepare2(virConnectPtr dconn,
goto cleanup;
}
-if (!(def = qemuMigrationPrepareDef(driver, dom_xml, dname)))
+if (!(def = qemuMigrationPrepareDef(driver, dom_xml, dname, origname)))
goto cleanup;
if (virDomainMigratePrepare2EnsureACL(dconn, def) 0)
@@ -10056,9 +10059,10 @@ qemuDomainMigratePrepare2(virConnectPtr dconn,
ret = qemuMigrationPrepareDirect(driver, dconn,
NULL, 0, NULL, NULL, /* No cookies */
uri_in, uri_out,
- def, flags);
+ def, origname, flags);
cleanup:
+VIR_FREE(origname);
virDomainDefFree(def);
return ret;
}
@@ -10235,6 +10239,7 @@ qemuDomainMigratePrepare3(virConnectPtr dconn,
{
virQEMUDriverPtr driver = dconn-privateData;
virDomainDefPtr def = NULL;
+char *origname = NULL;
int ret = -1;
virCheckFlags(QEMU_MIGRATION_FLAGS, -1);
@@ -10249,7 +10254,7 @@ qemuDomainMigratePrepare3(virConnectPtr dconn,
goto cleanup;
}
-if (!(def = qemuMigrationPrepareDef(driver, dom_xml, dname)))
+if (!(def = qemuMigrationPrepareDef(driver, dom_xml, dname, origname)))
goto cleanup;
if (virDomainMigratePrepare3EnsureACL(dconn, def) 0)
@@ -10259,9 +10264,10 @@ qemuDomainMigratePrepare3(virConnectPtr dconn,
cookiein, cookieinlen,
cookieout, cookieoutlen,
uri_in, uri_out,
- def, flags);
+ def, origname, flags);
cleanup:
+VIR_FREE(origname);
virDomainDefFree(def);
return ret;
}
@@ -10282,6 +10288,7 @@ qemuDomainMigratePrepare3Params(virConnectPtr dconn,
const char *dom_xml = NULL;
const char *dname = NULL;
const char *uri_in = NULL;
+char *origname = NULL;
int ret = -1;
virCheckFlags(QEMU_MIGRATION_FLAGS, -1);
@@ -10309,7 +10316,7 @@ qemuDomainMigratePrepare3Params(virConnectPtr dconn,
goto cleanup;
}
-if (!(def = qemuMigrationPrepareDef(driver, dom_xml, dname)))
+if (!(def = qemuMigrationPrepareDef(driver, dom_xml, dname, origname)))
goto cleanup;
if (virDomainMigratePrepare3ParamsEnsureACL(dconn, def) 0)
@@ -10319,9 +10326,10 @@ qemuDomainMigratePrepare3Params(virConnectPtr dconn,
cookiein, cookieinlen,
cookieout, cookieoutlen,
uri_in, uri_out,
- def, flags);
+ def, origname, flags);
cleanup:
+VIR_FREE(origname);
virDomainDefFree(def);
return ret;
}
@@ -10341,6
Re: [libvirt] [PATCHv5 3/5] domifaddr: Implement the API for qemu
Except what Daniel pointed out:
On 01/09/13 21:43, Nehal J Wani wrote:
By querying the qemu guest agent with the QMP command
guest-network-get-interfaces and converting the received JSON
output to structured objects.
Although ifconfig is deprecated, IP aliases created by ifconfig
are supported by this API. The legacy syntax of an IP alias is:
ifname:alias-name. Since we want all aliases to be clubbed
under parent interface, simply stripping :alias-name suffices.
s/suffices/suffixes/,
Note that IP aliases formed by ip aren't visible to ifconfig,
and aliases created by ip do not have any specific name. But
we are lucky, as qemuga detects aliases created by both.
s/qemuga/qemu guest agent/, or s/qemuga/qemu-ga/,
src/qemu/qemu_agent.h:
* Define qemuAgentGetInterfaces
src/qemu/qemu_agent.c:
* Implement qemuAgentGetInterface
src/qemu/qemu_driver.c:
* New function qemuDomainInterfaceAddresses
src/remote_protocol-sructs:
* Define new structs
tests/qemuagenttest.c:
* Add new test: testQemuAgentGetInterfaces
Test cases for IP aliases, 0 or multiple ipv4/ipv6 address(es)
---
src/qemu/qemu_agent.c | 193 +
src/qemu/qemu_agent.h | 3 +
src/qemu/qemu_driver.c | 55 ++
tests/qemuagenttest.c | 149 ++
4 files changed, 400 insertions(+)
diff --git a/src/qemu/qemu_agent.c b/src/qemu/qemu_agent.c
index 2cd0ccc..009ed77 100644
--- a/src/qemu/qemu_agent.c
+++ b/src/qemu/qemu_agent.c
@@ -1320,6 +1320,199 @@ cleanup:
}
/*
+ * qemuAgentGetInterfaces:
+ * @mon: Agent
s/Agent/Agent monitor/,
+ * @ifaces: pointer to an array of pointers pointing to interface objects
+ *
+ * Issue guest-network-get-interfaces to guest agent, which returns the
s/the/a/,
+ * list of a interfaces of a running domain along with their IP and MAC
s/of a/of/,
+ * addresses.
+ *
+ * Returns: number of interfaces on success, -1 on error.
+ */
+int
+qemuAgentGetInterfaces(qemuAgentPtr mon,
+ virDomainInterfacePtr **ifaces)
+{
+int ret = -1;
+size_t i, j;
+int size = -1;
+virJSONValuePtr cmd = NULL;
+virJSONValuePtr reply = NULL;
+virJSONValuePtr ret_array = NULL;
+size_t ifaces_count = 0;
+size_t addrs_count = 0;
+virDomainInterfacePtr *ifaces_ret = NULL;
+virHashTablePtr ifaces_store = NULL;
+
+/* Initially the bag of ifaces is empty */
bag is magic here, how about:
/* Hash table to handle the interface alias */
+if (!(ifaces_store = virHashCreate(ifaces_count, NULL)))
+return -1;
+
+if (!(cmd = qemuAgentMakeCommand(guest-network-get-interfaces, NULL)))
+ return -1;
You should free the created hash table.
+
+if (qemuAgentCommand(mon, cmd, reply, VIR_DOMAIN_QEMU_AGENT_COMMAND_BLOCK)
0 ||
+qemuAgentCheckError(cmd, reply) 0) {
+goto cleanup;
+}
+
+if (!(ret_array = virJSONValueObjectGet(reply, return))) {
+virReportError(VIR_ERR_INTERNAL_ERROR, %s,
+ _(qemu agent didn't provide 'return' field));
+goto cleanup;
+}
+
+if ((size = virJSONValueArraySize(ret_array)) 0) {
+virReportError(VIR_ERR_INTERNAL_ERROR, %s,
+ _(qemu agent didn't return an array of interfaces));
+goto cleanup;
+}
+
+for (i = 0; i size; i++) {
+virJSONValuePtr tmp_iface = virJSONValueArrayGet(ret_array, i);
+virJSONValuePtr ip_addr_arr = NULL;
+const char *hwaddr, *ifname_s, *name = NULL;
+char **ifname = NULL;
+int ip_addr_arr_size;
+virDomainInterfacePtr iface = NULL;
+
+/* Shouldn't happen but doesn't hurt to check neither */
+if (!tmp_iface) {
+virReportError(VIR_ERR_INTERNAL_ERROR, %s,
+ _(something has went really wrong));
+goto error;
+}
+
+/* interface name is required to be presented */
+name = virJSONValueObjectGetString(tmp_iface, name);
+if (!name) {
+virReportError(VIR_ERR_INTERNAL_ERROR, %s,
+ _(qemu agent didn't provide 'name' field));
+goto error;
+}
+
+/* Handle aliases of type ifname:alias-name */
I think no need to mention the type here, since it only can be
ifname:alias. So how about:
/* Handle interface alias (ifname:alias
+ifname = virStringSplit(name, :, 2);
+ifname_s = ifname[0];
+
+iface = virHashLookup(ifaces_store, ifname_s);
+
+/* If the storage bag doesn't contain this iface, add it */
s/storage bag/hash table/,
+if (!iface) {
+if (VIR_EXPAND_N(ifaces_ret, ifaces_count, 1) 0)
+goto cleanup;
goto error;
+
+if (VIR_ALLOC(ifaces_ret[ifaces_count - 1]) 0)
+goto cleanup;
goto error;
+
+if (virHashAddEntry(ifaces_store, ifname_s,
+
Re: [libvirt] [PATCHv5 3/5] domifaddr: Implement the API for qemu
On Tue, Sep 3, 2013 at 7:46 PM, Osier Yang jy...@redhat.com wrote:
Except what Daniel pointed out:
On 01/09/13 21:43, Nehal J Wani wrote:
By querying the qemu guest agent with the QMP command
guest-network-get-interfaces and converting the received JSON
output to structured objects.
Although ifconfig is deprecated, IP aliases created by ifconfig
are supported by this API. The legacy syntax of an IP alias is:
ifname:alias-name. Since we want all aliases to be clubbed
under parent interface, simply stripping :alias-name suffices.
s/suffices/suffixes/,
Here, I by suffices, I meant: Be enough or adequate.
Note that IP aliases formed by ip aren't visible to ifconfig,
and aliases created by ip do not have any specific name. But
we are lucky, as qemuga detects aliases created by both.
s/qemuga/qemu guest agent/, or s/qemuga/qemu-ga/,
src/qemu/qemu_agent.h:
* Define qemuAgentGetInterfaces
src/qemu/qemu_agent.c:
* Implement qemuAgentGetInterface
src/qemu/qemu_driver.c:
* New function qemuDomainInterfaceAddresses
src/remote_protocol-sructs:
* Define new structs
tests/qemuagenttest.c:
* Add new test: testQemuAgentGetInterfaces
Test cases for IP aliases, 0 or multiple ipv4/ipv6 address(es)
---
src/qemu/qemu_agent.c | 193
+
src/qemu/qemu_agent.h | 3 +
src/qemu/qemu_driver.c | 55 ++
tests/qemuagenttest.c | 149 ++
4 files changed, 400 insertions(+)
diff --git a/src/qemu/qemu_agent.c b/src/qemu/qemu_agent.c
index 2cd0ccc..009ed77 100644
--- a/src/qemu/qemu_agent.c
+++ b/src/qemu/qemu_agent.c
@@ -1320,6 +1320,199 @@ cleanup:
}
/*
+ * qemuAgentGetInterfaces:
+ * @mon: Agent
s/Agent/Agent monitor/,
+ * @ifaces: pointer to an array of pointers pointing to interface objects
+ *
+ * Issue guest-network-get-interfaces to guest agent, which returns the
s/the/a/,
+ * list of a interfaces of a running domain along with their IP and MAC
s/of a/of/,
+ * addresses.
+ *
+ * Returns: number of interfaces on success, -1 on error.
+ */
+int
+qemuAgentGetInterfaces(qemuAgentPtr mon,
+ virDomainInterfacePtr **ifaces)
+{
+int ret = -1;
+size_t i, j;
+int size = -1;
+virJSONValuePtr cmd = NULL;
+virJSONValuePtr reply = NULL;
+virJSONValuePtr ret_array = NULL;
+size_t ifaces_count = 0;
+size_t addrs_count = 0;
+virDomainInterfacePtr *ifaces_ret = NULL;
+virHashTablePtr ifaces_store = NULL;
+
+/* Initially the bag of ifaces is empty */
bag is magic here, how about:
/* Hash table to handle the interface alias */
+if (!(ifaces_store = virHashCreate(ifaces_count, NULL)))
+return -1;
+
+if (!(cmd = qemuAgentMakeCommand(guest-network-get-interfaces,
NULL)))
+ return -1;
You should free the created hash table.
In the label cleanup, I have freed the has table.
+
+if (qemuAgentCommand(mon, cmd, reply,
VIR_DOMAIN_QEMU_AGENT_COMMAND_BLOCK) 0 ||
+qemuAgentCheckError(cmd, reply) 0) {
+goto cleanup;
+}
+
+if (!(ret_array = virJSONValueObjectGet(reply, return))) {
+virReportError(VIR_ERR_INTERNAL_ERROR, %s,
+ _(qemu agent didn't provide 'return' field));
+goto cleanup;
+}
+
+if ((size = virJSONValueArraySize(ret_array)) 0) {
+virReportError(VIR_ERR_INTERNAL_ERROR, %s,
+ _(qemu agent didn't return an array of
interfaces));
+goto cleanup;
+}
+
+for (i = 0; i size; i++) {
+virJSONValuePtr tmp_iface = virJSONValueArrayGet(ret_array, i);
+virJSONValuePtr ip_addr_arr = NULL;
+const char *hwaddr, *ifname_s, *name = NULL;
+char **ifname = NULL;
+int ip_addr_arr_size;
+virDomainInterfacePtr iface = NULL;
+
+/* Shouldn't happen but doesn't hurt to check neither */
+if (!tmp_iface) {
+virReportError(VIR_ERR_INTERNAL_ERROR, %s,
+ _(something has went really wrong));
+goto error;
+}
+
+/* interface name is required to be presented */
+name = virJSONValueObjectGetString(tmp_iface, name);
+if (!name) {
+virReportError(VIR_ERR_INTERNAL_ERROR, %s,
+ _(qemu agent didn't provide 'name' field));
+goto error;
+}
+
+/* Handle aliases of type ifname:alias-name */
I think no need to mention the type here, since it only can be
ifname:alias. So how about:
/* Handle interface alias (ifname:alias
+ifname = virStringSplit(name, :, 2);
+ifname_s = ifname[0];
+
+iface = virHashLookup(ifaces_store, ifname_s);
+
+/* If the storage bag doesn't contain this iface, add it */
s/storage bag/hash table/,
+if (!iface) {
+
[libvirt] Is virsh blockcommit supported? Thanks a lot
I had test the command virsh blockcommit, but it failed, with the libvirt version 1.1.0, and qemu version 1.6.0. Is this feature being developing? Thanks root@cvk-31:/vms/images# virsh -v 1.1.0 root@cvk-31:/vms/images# qemu-img -V qemu-img version 1.6.0, Copyright (c) 2004-2008 Fabrice Bellard usage: qemu-img command [command options] root@cvk-31:/vms/images# virsh blockcommit Vmtest /vms/images/Vmtest1 --base /vms/image s/Vmtest1_base --top /vms/images/Vmtest1_base_1 --wait --verbose ;echo $? error: invalid argument: top '/vms/images/Vmtest1_base_1' in chain for '/vms/images/Vmtest1' has no backing file 1 root@cvk-31:/vms/images# qemu-img info /vms/images/Vmtest1_base_1 image: /vms/images/Vmtest1_base_1 file format: qcow2 virtual size: 9.8G (1048576 bytes) disk size: 6.0M cluster_size: 2097152 backing file: /vms/images/Vmtest1_base root@cvk-31:/vms/images# qemu-img info --backing-chain /vms/images/Vmtest1 image: /vms/images/Vmtest1 file format: qcow2 virtual size: 9.8G (1048576 bytes) disk size: 140M cluster_size: 2097152 backing file: /vms/images/Vmtest1_base_1 image: /vms/images/Vmtest1_base_1 file format: qcow2 virtual size: 9.8G (1048576 bytes) disk size: 6.0M cluster_size: 2097152 backing file: /vms/images/Vmtest1_base image: /vms/images/Vmtest1_base file format: qcow2 virtual size: 9.8G (1048576 bytes) disk size: 3.4G cluster_size: 2097152 root@cvk-31:/vms/images# virsh blockcommit Vmtest /vms/images/Vmtest1 --base /vms/image s/Vmtest1_base --wait --verbose ;echo $? error: invalid argument: could not find base '/vms/images/Vmtest1_base' below '/vms/images/Vmtest1' in chain for '/vms/images/Vmtest1' 1 root@cvk-31:/vms/images# ls -al /vms/images/Vmtest1_base -rw--- 1 root root 3705667584 Aug 23 10:19 /vms/images/Vmtest1_base root@cvk-31:/vms/images# qemu-img info /vms/images/Vmtest1_base image: /vms/images/Vmtest1_base file format: qcow2 virtual size: 9.8G (1048576 bytes) disk size: 3.4G cluster_size: 2097152 - ??? This e-mail and its attachments contain confidential information from H3C, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv5 3/5] domifaddr: Implement the API for qemu
On 03/09/13 22:37, Nehal J Wani wrote:
On Tue, Sep 3, 2013 at 7:46 PM, Osier Yang jy...@redhat.com wrote:
Except what Daniel pointed out:
On 01/09/13 21:43, Nehal J Wani wrote:
By querying the qemu guest agent with the QMP command
guest-network-get-interfaces and converting the received JSON
output to structured objects.
Although ifconfig is deprecated, IP aliases created by ifconfig
are supported by this API. The legacy syntax of an IP alias is:
ifname:alias-name. Since we want all aliases to be clubbed
under parent interface, simply stripping :alias-name suffices.
s/suffices/suffixes/,
Here, I by suffices, I meant: Be enough or adequate.
Note that IP aliases formed by ip aren't visible to ifconfig,
and aliases created by ip do not have any specific name. But
we are lucky, as qemuga detects aliases created by both.
s/qemuga/qemu guest agent/, or s/qemuga/qemu-ga/,
src/qemu/qemu_agent.h:
* Define qemuAgentGetInterfaces
src/qemu/qemu_agent.c:
* Implement qemuAgentGetInterface
src/qemu/qemu_driver.c:
* New function qemuDomainInterfaceAddresses
src/remote_protocol-sructs:
* Define new structs
tests/qemuagenttest.c:
* Add new test: testQemuAgentGetInterfaces
Test cases for IP aliases, 0 or multiple ipv4/ipv6 address(es)
---
src/qemu/qemu_agent.c | 193
+
src/qemu/qemu_agent.h | 3 +
src/qemu/qemu_driver.c | 55 ++
tests/qemuagenttest.c | 149 ++
4 files changed, 400 insertions(+)
diff --git a/src/qemu/qemu_agent.c b/src/qemu/qemu_agent.c
index 2cd0ccc..009ed77 100644
--- a/src/qemu/qemu_agent.c
+++ b/src/qemu/qemu_agent.c
@@ -1320,6 +1320,199 @@ cleanup:
}
/*
+ * qemuAgentGetInterfaces:
+ * @mon: Agent
s/Agent/Agent monitor/,
+ * @ifaces: pointer to an array of pointers pointing to interface objects
+ *
+ * Issue guest-network-get-interfaces to guest agent, which returns the
s/the/a/,
+ * list of a interfaces of a running domain along with their IP and MAC
s/of a/of/,
+ * addresses.
+ *
+ * Returns: number of interfaces on success, -1 on error.
+ */
+int
+qemuAgentGetInterfaces(qemuAgentPtr mon,
+ virDomainInterfacePtr **ifaces)
+{
+int ret = -1;
+size_t i, j;
+int size = -1;
+virJSONValuePtr cmd = NULL;
+virJSONValuePtr reply = NULL;
+virJSONValuePtr ret_array = NULL;
+size_t ifaces_count = 0;
+size_t addrs_count = 0;
+virDomainInterfacePtr *ifaces_ret = NULL;
+virHashTablePtr ifaces_store = NULL;
+
+/* Initially the bag of ifaces is empty */
bag is magic here, how about:
/* Hash table to handle the interface alias */
+if (!(ifaces_store = virHashCreate(ifaces_count, NULL)))
+return -1;
+
+if (!(cmd = qemuAgentMakeCommand(guest-network-get-interfaces,
NULL)))
+ return -1;
You should free the created hash table.
In the label cleanup, I have freed the has table.
But you returns -1 here.
+
+if (qemuAgentCommand(mon, cmd, reply,
VIR_DOMAIN_QEMU_AGENT_COMMAND_BLOCK) 0 ||
+qemuAgentCheckError(cmd, reply) 0) {
+goto cleanup;
+}
+
+if (!(ret_array = virJSONValueObjectGet(reply, return))) {
+virReportError(VIR_ERR_INTERNAL_ERROR, %s,
+ _(qemu agent didn't provide 'return' field));
+goto cleanup;
+}
+
+if ((size = virJSONValueArraySize(ret_array)) 0) {
+virReportError(VIR_ERR_INTERNAL_ERROR, %s,
+ _(qemu agent didn't return an array of
interfaces));
+goto cleanup;
+}
+
+for (i = 0; i size; i++) {
+virJSONValuePtr tmp_iface = virJSONValueArrayGet(ret_array, i);
+virJSONValuePtr ip_addr_arr = NULL;
+const char *hwaddr, *ifname_s, *name = NULL;
+char **ifname = NULL;
+int ip_addr_arr_size;
+virDomainInterfacePtr iface = NULL;
+
+/* Shouldn't happen but doesn't hurt to check neither */
+if (!tmp_iface) {
+virReportError(VIR_ERR_INTERNAL_ERROR, %s,
+ _(something has went really wrong));
+goto error;
+}
+
+/* interface name is required to be presented */
+name = virJSONValueObjectGetString(tmp_iface, name);
+if (!name) {
+virReportError(VIR_ERR_INTERNAL_ERROR, %s,
+ _(qemu agent didn't provide 'name' field));
+goto error;
+}
+
+/* Handle aliases of type ifname:alias-name */
I think no need to mention the type here, since it only can be
ifname:alias. So how about:
/* Handle interface alias (ifname:alias
+ifname = virStringSplit(name, :, 2);
+ifname_s = ifname[0];
+
+iface = virHashLookup(ifaces_store, ifname_s);
+
+/* If the storage bag doesn't contain this iface, add it */
s/storage bag/hash table/,
+if (!iface) {
+if (VIR_EXPAND_N(ifaces_ret, ifaces_count, 1) 0)
+
Re: [libvirt] [PATCHv5 3/5] domifaddr: Implement the API for qemu
On Tue, Sep 3, 2013 at 8:21 PM, Osier Yang jy...@redhat.com wrote:
On 03/09/13 22:37, Nehal J Wani wrote:
On Tue, Sep 3, 2013 at 7:46 PM, Osier Yang jy...@redhat.com wrote:
Except what Daniel pointed out:
On 01/09/13 21:43, Nehal J Wani wrote:
By querying the qemu guest agent with the QMP command
guest-network-get-interfaces and converting the received JSON
output to structured objects.
Although ifconfig is deprecated, IP aliases created by ifconfig
are supported by this API. The legacy syntax of an IP alias is:
ifname:alias-name. Since we want all aliases to be clubbed
under parent interface, simply stripping :alias-name suffices.
s/suffices/suffixes/,
Here, I by suffices, I meant: Be enough or adequate.
Note that IP aliases formed by ip aren't visible to ifconfig,
and aliases created by ip do not have any specific name. But
we are lucky, as qemuga detects aliases created by both.
s/qemuga/qemu guest agent/, or s/qemuga/qemu-ga/,
src/qemu/qemu_agent.h:
* Define qemuAgentGetInterfaces
src/qemu/qemu_agent.c:
* Implement qemuAgentGetInterface
src/qemu/qemu_driver.c:
* New function qemuDomainInterfaceAddresses
src/remote_protocol-sructs:
* Define new structs
tests/qemuagenttest.c:
* Add new test: testQemuAgentGetInterfaces
Test cases for IP aliases, 0 or multiple ipv4/ipv6 address(es)
---
src/qemu/qemu_agent.c | 193
+
src/qemu/qemu_agent.h | 3 +
src/qemu/qemu_driver.c | 55 ++
tests/qemuagenttest.c | 149 ++
4 files changed, 400 insertions(+)
diff --git a/src/qemu/qemu_agent.c b/src/qemu/qemu_agent.c
index 2cd0ccc..009ed77 100644
--- a/src/qemu/qemu_agent.c
+++ b/src/qemu/qemu_agent.c
@@ -1320,6 +1320,199 @@ cleanup:
}
/*
+ * qemuAgentGetInterfaces:
+ * @mon: Agent
s/Agent/Agent monitor/,
+ * @ifaces: pointer to an array of pointers pointing to interface
objects
+ *
+ * Issue guest-network-get-interfaces to guest agent, which returns the
s/the/a/,
+ * list of a interfaces of a running domain along with their IP and MAC
s/of a/of/,
+ * addresses.
+ *
+ * Returns: number of interfaces on success, -1 on error.
+ */
+int
+qemuAgentGetInterfaces(qemuAgentPtr mon,
+ virDomainInterfacePtr **ifaces)
+{
+int ret = -1;
+size_t i, j;
+int size = -1;
+virJSONValuePtr cmd = NULL;
+virJSONValuePtr reply = NULL;
+virJSONValuePtr ret_array = NULL;
+size_t ifaces_count = 0;
+size_t addrs_count = 0;
+virDomainInterfacePtr *ifaces_ret = NULL;
+virHashTablePtr ifaces_store = NULL;
+
+/* Initially the bag of ifaces is empty */
bag is magic here, how about:
/* Hash table to handle the interface alias */
+if (!(ifaces_store = virHashCreate(ifaces_count, NULL)))
+return -1;
+
+if (!(cmd = qemuAgentMakeCommand(guest-network-get-interfaces,
NULL)))
+ return -1;
You should free the created hash table.
In the label cleanup, I have freed the has table.
But you returns -1 here.
+
+if (qemuAgentCommand(mon, cmd, reply,
VIR_DOMAIN_QEMU_AGENT_COMMAND_BLOCK) 0 ||
+qemuAgentCheckError(cmd, reply) 0) {
+goto cleanup;
+}
+
+if (!(ret_array = virJSONValueObjectGet(reply, return))) {
+virReportError(VIR_ERR_INTERNAL_ERROR, %s,
+ _(qemu agent didn't provide 'return' field));
+goto cleanup;
+}
+
+if ((size = virJSONValueArraySize(ret_array)) 0) {
+virReportError(VIR_ERR_INTERNAL_ERROR, %s,
+ _(qemu agent didn't return an array of
interfaces));
+goto cleanup;
+}
+
+for (i = 0; i size; i++) {
+virJSONValuePtr tmp_iface = virJSONValueArrayGet(ret_array, i);
+virJSONValuePtr ip_addr_arr = NULL;
+const char *hwaddr, *ifname_s, *name = NULL;
+char **ifname = NULL;
+int ip_addr_arr_size;
+virDomainInterfacePtr iface = NULL;
+
+/* Shouldn't happen but doesn't hurt to check neither */
+if (!tmp_iface) {
+virReportError(VIR_ERR_INTERNAL_ERROR, %s,
+ _(something has went really wrong));
+goto error;
+}
+
+/* interface name is required to be presented */
+name = virJSONValueObjectGetString(tmp_iface, name);
+if (!name) {
+virReportError(VIR_ERR_INTERNAL_ERROR, %s,
+ _(qemu agent didn't provide 'name' field));
+goto error;
+}
+
+/* Handle aliases of type ifname:alias-name */
I think no need to mention the type here, since it only can be
ifname:alias. So how about:
/* Handle interface alias (ifname:alias
+ifname = virStringSplit(name, :, 2);
+ifname_s = ifname[0];
+
+iface = virHashLookup(ifaces_store,
Re: [libvirt] [PATCH] test_virtlockd.aug.in: Use the correct file
On 03/09/13 22:50, Michal Privoznik wrote:
The test should refer to Virtlockd.lns, which is the name of
the module + lens in virtlockd.aug.
Signed-off-by: Michal Privoznik mpriv...@redhat.com
---
src/locking/test_virtlockd.aug.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/locking/test_virtlockd.aug.in
b/src/locking/test_virtlockd.aug.in
index dcd47c3..799818e 100644
--- a/src/locking/test_virtlockd.aug.in
+++ b/src/locking/test_virtlockd.aug.in
@@ -5,7 +5,7 @@ log_outputs=\3:syslog:libvirtd\
log_buffer_size = 64
- test Libvirtd.lns get conf =
+ test Virtlockd.lns get conf =
{ log_level = 3 }
{ log_filters = 3:remote 4:event }
{ log_outputs = 3:syslog:libvirtd }
ACK
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] qemu: Make domain renaming work during migration
On 09/03/2013 07:46 AM, Jiri Denemark wrote: https://bugzilla.redhat.com/show_bug.cgi?id=999352 Since commit v1.0.5-56-g449e6b1 (Pull parsing of migration xml up into QEMU driver APIs) any attempt to rename a domain during migration fails with the following error message: internal error Incoming cookie data had unexpected name DOM vs DOM2 This is because migration cookies always use the original domain name and the mentioned commit failed to propagate the name back to qemuMigrationPrepareAny. --- src/qemu/qemu_driver.c| 36 src/qemu/qemu_migration.c | 31 +++ src/qemu/qemu_migration.h | 5 - 3 files changed, 47 insertions(+), 25 deletions(-) Bummer of a regression; and it takes quite a bit of code to restore documented functionality. ACK. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv5 3/5] domifaddr: Implement the API for qemu
On 03/09/13 23:00, Nehal J Wani wrote:
On Tue, Sep 3, 2013 at 8:21 PM, Osier Yang jy...@redhat.com wrote:
On 03/09/13 22:37, Nehal J Wani wrote:
On Tue, Sep 3, 2013 at 7:46 PM, Osier Yang jy...@redhat.com wrote:
Except what Daniel pointed out:
On 01/09/13 21:43, Nehal J Wani wrote:
By querying the qemu guest agent with the QMP command
guest-network-get-interfaces and converting the received JSON
output to structured objects.
Although ifconfig is deprecated, IP aliases created by ifconfig
are supported by this API. The legacy syntax of an IP alias is:
ifname:alias-name. Since we want all aliases to be clubbed
under parent interface, simply stripping :alias-name suffices.
s/suffices/suffixes/,
Here, I by suffices, I meant: Be enough or adequate.
Note that IP aliases formed by ip aren't visible to ifconfig,
and aliases created by ip do not have any specific name. But
we are lucky, as qemuga detects aliases created by both.
s/qemuga/qemu guest agent/, or s/qemuga/qemu-ga/,
src/qemu/qemu_agent.h:
* Define qemuAgentGetInterfaces
src/qemu/qemu_agent.c:
* Implement qemuAgentGetInterface
src/qemu/qemu_driver.c:
* New function qemuDomainInterfaceAddresses
src/remote_protocol-sructs:
* Define new structs
tests/qemuagenttest.c:
* Add new test: testQemuAgentGetInterfaces
Test cases for IP aliases, 0 or multiple ipv4/ipv6 address(es)
---
src/qemu/qemu_agent.c | 193
+
src/qemu/qemu_agent.h | 3 +
src/qemu/qemu_driver.c | 55 ++
tests/qemuagenttest.c | 149 ++
4 files changed, 400 insertions(+)
diff --git a/src/qemu/qemu_agent.c b/src/qemu/qemu_agent.c
index 2cd0ccc..009ed77 100644
--- a/src/qemu/qemu_agent.c
+++ b/src/qemu/qemu_agent.c
@@ -1320,6 +1320,199 @@ cleanup:
}
/*
+ * qemuAgentGetInterfaces:
+ * @mon: Agent
s/Agent/Agent monitor/,
+ * @ifaces: pointer to an array of pointers pointing to interface
objects
+ *
+ * Issue guest-network-get-interfaces to guest agent, which returns the
s/the/a/,
+ * list of a interfaces of a running domain along with their IP and MAC
s/of a/of/,
+ * addresses.
+ *
+ * Returns: number of interfaces on success, -1 on error.
+ */
+int
+qemuAgentGetInterfaces(qemuAgentPtr mon,
+ virDomainInterfacePtr **ifaces)
+{
+int ret = -1;
+size_t i, j;
+int size = -1;
+virJSONValuePtr cmd = NULL;
+virJSONValuePtr reply = NULL;
+virJSONValuePtr ret_array = NULL;
+size_t ifaces_count = 0;
+size_t addrs_count = 0;
+virDomainInterfacePtr *ifaces_ret = NULL;
+virHashTablePtr ifaces_store = NULL;
+
+/* Initially the bag of ifaces is empty */
bag is magic here, how about:
/* Hash table to handle the interface alias */
+if (!(ifaces_store = virHashCreate(ifaces_count, NULL)))
+return -1;
+
+if (!(cmd = qemuAgentMakeCommand(guest-network-get-interfaces,
NULL)))
+ return -1;
You should free the created hash table.
In the label cleanup, I have freed the has table.
But you returns -1 here.
+
+if (qemuAgentCommand(mon, cmd, reply,
VIR_DOMAIN_QEMU_AGENT_COMMAND_BLOCK) 0 ||
+qemuAgentCheckError(cmd, reply) 0) {
+goto cleanup;
+}
+
+if (!(ret_array = virJSONValueObjectGet(reply, return))) {
+virReportError(VIR_ERR_INTERNAL_ERROR, %s,
+ _(qemu agent didn't provide 'return' field));
+goto cleanup;
+}
+
+if ((size = virJSONValueArraySize(ret_array)) 0) {
+virReportError(VIR_ERR_INTERNAL_ERROR, %s,
+ _(qemu agent didn't return an array of
interfaces));
+goto cleanup;
+}
+
+for (i = 0; i size; i++) {
+virJSONValuePtr tmp_iface = virJSONValueArrayGet(ret_array, i);
+virJSONValuePtr ip_addr_arr = NULL;
+const char *hwaddr, *ifname_s, *name = NULL;
+char **ifname = NULL;
+int ip_addr_arr_size;
+virDomainInterfacePtr iface = NULL;
+
+/* Shouldn't happen but doesn't hurt to check neither */
+if (!tmp_iface) {
+virReportError(VIR_ERR_INTERNAL_ERROR, %s,
+ _(something has went really wrong));
+goto error;
+}
+
+/* interface name is required to be presented */
+name = virJSONValueObjectGetString(tmp_iface, name);
+if (!name) {
+virReportError(VIR_ERR_INTERNAL_ERROR, %s,
+ _(qemu agent didn't provide 'name' field));
+goto error;
+}
+
+/* Handle aliases of type ifname:alias-name */
I think no need to mention the type here, since it only can be
ifname:alias. So how about:
/* Handle interface alias (ifname:alias
+ifname = virStringSplit(name, :, 2);
+ifname_s = ifname[0];
+
+iface = virHashLookup(ifaces_store, ifname_s);
+
+/* If the storage bag doesn't contain this iface, add it */
Re: [libvirt] [PATCHv5 1/5] domifaddr: Implement the public APIs
On 09/02/2013 03:41 AM, Nehal J Wani wrote:
In agreement with Guido's suggestion on 5/5 of the previous version
(https://www.redhat.com/archives/libvir-list/2013-August/msg01271.html),
the enums are also to exposed to python bindings, for which,
/include/libvirt/libvirt.h.in will have to be modified a bit. Diff has
been attached.
Yes, the constants need to be exposed in python bindings. However,
typedef enum {
-VIR_IP_ADDR_TYPE_IPV4,
-VIR_IP_ADDR_TYPE_IPV6,
+VIR_IP_ADDR_TYPE_IPV4 = (1 0),
+VIR_IP_ADDR_TYPE_IPV6 = (1 1),
This is not the correct way to do so. These are not bitmasks, but
should be sequential:
VIR_IP_ADDR_TYPE_IPV4 = 0,
VIR_IP_ADDR_TYPE_IPV6 = 1,
/* next one would be 2, ... */
#ifdef VIR_ENUM_SENTINELS
-VIR_IP_ADDR_TYPE_LAST
+VIR_IP_ADDR_TYPE_LAST = (1 2),
and this should NOT have an explicit value (the _LAST enum is magic, and
should always be 1 more than the previous value; it is also protected
behind #ifdef because there are some contexts that should not be exposed
to the _LAST value). I don't remember off the top of my head, but think
that python bindings are one of the places where we intentionally don't
expose _LAST values.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] test_virtlockd.aug.in: Use the correct file
On 09/03/2013 08:50 AM, Michal Privoznik wrote:
The test should refer to Virtlockd.lns, which is the name of
the module + lens in virtlockd.aug.
Signed-off-by: Michal Privoznik mpriv...@redhat.com
---
src/locking/test_virtlockd.aug.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Hmm, it looks like this was missed during Guido's commit 3e325448.
ACK.
diff --git a/src/locking/test_virtlockd.aug.in
b/src/locking/test_virtlockd.aug.in
index dcd47c3..799818e 100644
--- a/src/locking/test_virtlockd.aug.in
+++ b/src/locking/test_virtlockd.aug.in
@@ -5,7 +5,7 @@ log_outputs=\3:syslog:libvirtd\
log_buffer_size = 64
- test Libvirtd.lns get conf =
+ test Virtlockd.lns get conf =
{ log_level = 3 }
{ log_filters = 3:remote 4:event }
{ log_outputs = 3:syslog:libvirtd }
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Stop calling virAllocN directly from ESX code
From: Daniel P. Berrange berra...@redhat.com
The ESX code has a method esxVI_Alloc which would call
virAllocN directly, instead of using the VIR_ALLOC_N
macro. Remove this method and make the callers just
use VIR_ALLOC as is normal practice.
Signed-off-by: Daniel P. Berrange berra...@redhat.com
---
src/esx/esx_vi.c | 25 -
src/esx/esx_vi.h | 3 ---
src/esx/esx_vi_types.c | 11 +++
3 files changed, 15 insertions(+), 24 deletions(-)
diff --git a/src/esx/esx_vi.c b/src/esx/esx_vi.c
index 1187bf3..255d0f4 100644
--- a/src/esx/esx_vi.c
+++ b/src/esx/esx_vi.c
@@ -51,8 +51,14 @@
int \
esxVI_##_type##_Alloc(esxVI_##_type **ptrptr) \
{ \
-return esxVI_Alloc((void **)ptrptr, sizeof(esxVI_##_type),\
- __FILE__, __FUNCTION__, __LINE__); \
+if (ptrptr == NULL || *ptrptr != NULL) { \
+virReportError(VIR_ERR_INTERNAL_ERROR, %s, _(Invalid
argument)); \
+return -1; \
+} \
+\
+if (VIR_ALLOC(*ptrptr) 0) \
+return -1; \
+return 0; \
}
@@ -1736,21 +1742,6 @@ esxVI_List_Deserialize(xmlNodePtr node, esxVI_List
**list,
*/
int
-esxVI_Alloc(void **ptrptr, size_t size, const char *file,
-const char *function, size_t linenr)
-{
-if (ptrptr == NULL || *ptrptr != NULL) {
-virReportError(VIR_ERR_INTERNAL_ERROR, %s, _(Invalid argument));
-return -1;
-}
-
-return virAllocN(ptrptr, size, 1, true, VIR_FROM_THIS,
- file, function, linenr);
-}
-
-
-
-int
esxVI_BuildSelectSet(esxVI_SelectionSpec **selectSet,
const char *name, const char *type,
const char *path, const char *selectSetNames)
diff --git a/src/esx/esx_vi.h b/src/esx/esx_vi.h
index c1612e2..aeee953 100644
--- a/src/esx/esx_vi.h
+++ b/src/esx/esx_vi.h
@@ -330,9 +330,6 @@ int esxVI_List_Deserialize(xmlNodePtr node, esxVI_List
**list,
* - 'get' functions get information from a local object
*/
-int esxVI_Alloc(void **ptrptr, size_t size, const char *file,
-const char *function, size_t linenr);
-
int esxVI_BuildSelectSet
(esxVI_SelectionSpec **selectSet, const char *name,
const char *type, const char *path, const char *selectSetNames);
diff --git a/src/esx/esx_vi_types.c b/src/esx/esx_vi_types.c
index 14caeeb..03df444 100644
--- a/src/esx/esx_vi_types.c
+++ b/src/esx/esx_vi_types.c
@@ -43,10 +43,13 @@
int \
esxVI_##__type##_Alloc(esxVI_##__type **ptrptr) \
{ \
-if (esxVI_Alloc((void **)ptrptr, sizeof(esxVI_##__type), \
-__FILE__, __FUNCTION__, __LINE__) 0) { \
-return -1;\
-} \
+if (ptrptr == NULL || *ptrptr != NULL) { \
+virReportError(VIR_ERR_INTERNAL_ERROR, %s, _(Invalid
argument)); \
+return -1; \
+} \
+\
+if (VIR_ALLOC(*ptrptr) 0) \
+return -1; \
\
(*ptrptr)-_type = esxVI_Type_##__type; \
\
--
1.8.3.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv5 3/5] domifaddr: Implement the API for qemu
On Tue, Sep 03, 2013 at 10:16:05PM +0800, Osier Yang wrote:
Except what Daniel pointed out:
On 01/09/13 21:43, Nehal J Wani wrote:
+static const char testQemuAgentGetInterfacesResponse[] =
+{\return\:
+[
+ {\name\:\lo\,
+\ip-addresses\:
+ [
+ {\ip-address-type\:\ipv4\,
+ \ip-address\:\127.0.0.1\,
+ \prefix\:8
+ },
+ {\ip-address-type\:\ipv6\,
+ \ip-address\:\::1\,
+ \prefix\:128
+ }
+ ],
+\hardware-address\:\00:00:00:00:00:00\
+ },
+ {\name\:\eth0\,
+\ip-addresses\:
+ [
+ {\ip-address-type\:\ipv4\,
+ \ip-address\:\192.168.102.142\,
+ \prefix\:24
+ },
+ {\ip-address-type\:\ipv6\,
+ \ip-address\:\fe80::5054:ff:fe89:ad35\,
+ \prefix\:64
+ },
+ {\ip-address-type\:\ipv4\,
+ \ip-address\:\192.168.234.152\,
+ \prefix\:16
+ },
+ {\ip-address-type\:\ipv6\,
+ \ip-address\:\fe80::5054:ff:fec3:68bb\,
+ \prefix\:64
Can qemu guest agent really returns mutiple same type IP addresses?
Isn't it returning
the other IP addresses as iface:alias ?
iface:alias has only ever existed for IPv4. It is never used
for IPv6 interfaces. It is possible to have multiple IPv4
addrs, without them appearing in :alias format
eg:
# ifconfig
em1: flags=4163UP,BROADCAST,RUNNING,MULTICAST mtu 1500
inet 10.33.1.228 netmask 255.255.254.0 broadcast 10.33.1.255
inet6 200::200 prefixlen 64 scopeid 0x0global
inet6 fe80::3e97:eff:fe95:800c prefixlen 64 scopeid 0x20link
lo: flags=73UP,LOOPBACK,RUNNING mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10host
virbr0: flags=4099UP,BROADCAST,MULTICAST mtu 1500
inet 192.168.122.1 netmask 255.255.255.0 broadcast 192.168.122.255
ether 52:54:00:54:95:2a txqueuelen 0 (Ethernet)
# ip addr show
1: lo: LOOPBACK,UP,LOWER_UP mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet 128.0.0.1/24 scope global lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: em1: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP
qlen 1000
link/ether 3c:97:0e:95:80:0c brd ff:ff:ff:ff:ff:ff
inet 10.33.1.228/23 brd 10.33.1.255 scope global em1
valid_lft forever preferred_lft forever
inet 128.0.0.1/24 scope global em1
valid_lft forever preferred_lft forever
inet6 200::200/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::3e97:eff:fe95:800c/64 scope link
valid_lft forever preferred_lft forever
4: virbr0: NO-CARRIER,BROADCAST,MULTICAST,UP mtu 1500 qdisc noqueue state
DOWN
link/ether 52:54:00:54:95:2a brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
valid_lft forever preferred_lft forever
Notice no em1:alias device exists even though it has multiple addrs
+ }
+ ],
+\hardware-address\:\52:54:00:89:ad:35\
+ },
+ {\name\:\eth1\,
+\ip-addresses\:
+ [
+ {\ip-address-type\:\ipv4\,
+ \ip-address\:\192.168.103.83\,
+ \prefix\:24
+ },
+ {\ip-address-type\:\ipv6\,
+ \ip-address\:\fe80::5054:ff:fed3:39ee\,
+ \prefix\:64
+ }
+ ],
+\hardware-address\:\52:54:00:d3:39:ee\
+ },
+ {\name\:\eth1:0\,
+\ip-addresses\:
+ [
+ {\ip-address-type\:\ipv4\,
+ \ip-address\:\192.168.10.91\,
+ \prefix\:24
+ },
+ {\ip-address-type\:\ipv6\,
+ \ip-address\:\fe80::fc54:ff:fefe:4c4f\,
+ \prefix\:64
+ }
+ ],
+\hardware-address\:\52:54:00:d3:39:ee\
+ },
+ {\name\:\eth2\,
+\hardware-address\:\52:54:00:36:2a:e5\
+ }
+]
+};
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 :|
--
libvir-list mailing
[libvirt] [PATCH] conf: Remove the actual hostdev when removing a network
Commit 50348e6edfa reused the code to remove the hostdev portion of a
network definition on multiple places but forgot to take into account
that sometimes the actual network is passed and in some cases the
parent of that.
This patch uses the virDomainNetGetActualHostdev() helper to acquire the
correct pointer all the time while removing the hostdev portion from the
list.
---
src/conf/domain_conf.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index e412f28..cef4cf9 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -10002,14 +10002,14 @@ void
virDomainNetRemoveHostdev(virDomainDefPtr def,
virDomainNetDefPtr net)
{
-if (net-type == VIR_DOMAIN_NET_TYPE_HOSTDEV) {
-/* hostdev net devices are normally also be in the hostdevs
- * array, but might have already been removed by the time we
- * get here.
- */
-virDomainHostdevDefPtr hostdev = net-data.hostdev.def;
-size_t i;
+/* hostdev net devices are normally also be in the hostdevs
+ * array, but might have already been removed by the time we
+ * get here.
+ */
+virDomainHostdevDefPtr hostdev = virDomainNetGetActualHostdev(net);
+size_t i;
+if (hostdev) {
for (i = 0; i def-nhostdevs; i++) {
if (def-hostdevs[i] == hostdev) {
virDomainHostdevRemove(def, i);
--
1.8.3.2
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Fix crash in virDomainGetVcpuPinInfo python wrapper
From: Daniel P. Berrange berra...@redhat.com It is possible to jump to the cleanup block before the cpumaps variable gets initialized. This will result in a VIR_FREE of an uninitializer pointer Signed-off-by: Daniel P. Berrange berra...@redhat.com --- python/libvirt-override.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/python/libvirt-override.c b/python/libvirt-override.c index d16b9a2..cc76c47 100644 --- a/python/libvirt-override.c +++ b/python/libvirt-override.c @@ -1769,7 +1769,7 @@ libvirt_virDomainGetVcpuPinInfo(PyObject *self ATTRIBUTE_UNUSED, virDomainPtr domain; PyObject *pyobj_domain, *pycpumaps = NULL; virDomainInfo dominfo; -unsigned char *cpumaps; +unsigned char *cpumaps = NULL; size_t cpumaplen, vcpu, pcpu; unsigned int flags; int i_retval, cpunum; -- 1.8.3.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv3 2/6] virsh: Add vshCmdCompleter and vshOptCompleter
On 09/01/2013 01:22 PM, Tomas Meszaros wrote: No, it should work like this: virsh# vol-key TAB vol1 vol2 --vol --pool virsh# vol-key --pool TAB pool1 pool2 Another twist to remember - options can be spelled with '=' in one argument, instead of two arguments. This means you have a choice in display between: virsh# vol-key --pool=TAB --pool=pool1 --pool=pool2 or virsh# vol-key --pool=TAB pool1 pool2 when there is an ambiguity, but the resolution of the tab completion must be the full option=value (that is, don't lose the --pool= prefix by expanding to just the value). Yeah, It makes more sense. I'm now rewriting the whole stuff to just use opt completers. Looking forward to another round of review - this is interesting code from the UI point of view. And I am still working on the './configure --disable-readline' patch from my side. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/5]qemu: add usb-bot scsi controller support
- Original Message -
From: Daniel P. Berrange berra...@redhat.com
To: Guannan Ren g...@redhat.com
Cc: libvir-list@redhat.com
Sent: Tuesday, September 3, 2013 5:38:08 AM
Subject: Re: [libvirt] [PATCH 0/5]qemu: add usb-bot scsi controller support
On Mon, Sep 02, 2013 at 05:38:39PM +0800, Guannan Ren wrote:
BZ:https://bugzilla.redhat.com/show_bug.cgi?id=917702
qemu patch:http://lists.gnu.org/archive/html/qemu-devel/2013-01/msg02200.html
These patch aims to add usb-bot SCSI controller support for libvirt.
As usb-storage libvirt already supported, usb-bot only supports one
SCSI target with SCSI ID 0.
The difference is that usb-storage creates SCSI HBA and additionaly
either a scsi-disk or a scsi-generic device, usb-bot only creates the
SCSI HBA. we can attach a SCSI device to it with another -device.
usb-bot supports a single target and a number of luns. The limit is
15 luns (0~15 LUN ID) and they must be contiguous(using lun 0 and 2
without 1 doesn't work).
Athought usb-bot is a SCSI controller it needs to be attached to a
exsiting USB controller for work. So it has to use address of usb type.
Libvirt XML:
devices
...
disk type='file' device='disk'
driver name='qemu' type='raw'/
source file='/var/lib/libvirt/images/disk.qcow2'/
target dev='sdc' bus='scsi'/
address type='drive' controller='0' bus='0' target='0' unit='0'/
/disk
controller type='usb' index='0'/
controller type='scsi' index='0' model='usb-bot'
address type='usb' bus='0' port='1'/
/controller
...
/devices
How does this work from a hotplug POV. With usb-storage you could
just hotplug the disk device. Now it seems we need two separate
hotplug calls one of the controller and one for the disk and
the reverse.
Yes, I will think about the hotplug.
The QEMU commandline:
qemu ${other_vm_args} \
-device piix3-usb-uhci,id=usb \
-device usb-bot,id=scsi0,bus=usb.0,port=1 \
-drive
file=/var/lib/libvirt/images/disk.qcow2,if=none,id=drive-scsi0-0-0-0,format=raw
\
-device
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0
As the usb-storage creates scsi disk automatically which doesn't let
you set scsi-disk properties such as vendor, product, wwn, channel,
scsi-id and lun. So QEMU guys prefer usb-bot to usb-storage.
So this is the first part of the whole work. Next step will replace
usb-storage with usb-bot when disk in xml uses usb bus like
disk ...
...
target bus='usb'
/disk
I'm not really a fan of introducing 2 different ways to configure
the exact same device.
The idea is to use usb-bot instead of usb-storage in this case if usb-bot
capability is available.
usb-storage automatically expands into two devices, a SCSI controller and a
SCSI device. And user
cannot set any property values to this SCSI device such as vendor, product,
wwn, channel, scsi-id
and lun. usb-bot gives the more flexible configurations.
I think it is to use usb-bot if usb-bot is supported, otherwise still use
usb-storage. The xml
will not change at all.
Guannan
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] build: only create virt-login-shell for lxc builds
On 09/02/2013 05:35 AM, Daniel P. Berrange wrote:
On Fri, Aug 30, 2013 at 02:37:20PM -0600, Eric Blake wrote:
I noticed from an ./autobuild.sh run that we were installing a
virt-login-shell.exe binary when cross-building for mingw,
even though such a binary is necessarily worthless since the
code depends on lxc which is a Linux-only concept.
* tools/Makefile.am (conf_DATA, bin_PROGRAMS, dist_man1_MANS):
Make virt-login-shell installation conditional.
Signed-off-by: Eric Blake ebl...@redhat.com
---
I'm debating about pushing this under the build-breaker rule.
tools/Makefile.am | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
Unfortunately this will now break the libvirt.spec.in if
%{with_lxc} is set to 0. Fortunately we don't do that by
default for any platforms we support but still nice to
fix it
Okay, I'll post a followup patch later today.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Fix crash in virDomainGetVcpuPinInfo python wrapper
ACK - Original Message - From: Daniel P. Berrange berra...@redhat.com To: libvir-list@redhat.com Sent: Tuesday, September 3, 2013 11:37:44 AM Subject: [libvirt] [PATCH] Fix crash in virDomainGetVcpuPinInfo python wrapper From: Daniel P. Berrange berra...@redhat.com It is possible to jump to the cleanup block before the cpumaps variable gets initialized. This will result in a VIR_FREE of an uninitializer pointer Signed-off-by: Daniel P. Berrange berra...@redhat.com --- python/libvirt-override.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/python/libvirt-override.c b/python/libvirt-override.c index d16b9a2..cc76c47 100644 --- a/python/libvirt-override.c +++ b/python/libvirt-override.c @@ -1769,7 +1769,7 @@ libvirt_virDomainGetVcpuPinInfo(PyObject *self ATTRIBUTE_UNUSED, virDomainPtr domain; PyObject *pyobj_domain, *pycpumaps = NULL; virDomainInfo dominfo; -unsigned char *cpumaps; +unsigned char *cpumaps = NULL; size_t cpumaplen, vcpu, pcpu; unsigned int flags; int i_retval, cpunum; -- 1.8.3.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Add missing 'libvirt_lxc_api' variable in pkg-config file
From: Daniel P. Berrange berra...@redhat.com The 'libvirt_lxc_api' variable is intended to allow apps to query the location of the API XML file for libvirt_lxc.so Signed-off-by: Daniel P. Berrange berra...@redhat.com --- libvirt.pc.in | 1 + 1 file changed, 1 insertion(+) diff --git a/libvirt.pc.in b/libvirt.pc.in index 616575d..d456a88 100644 --- a/libvirt.pc.in +++ b/libvirt.pc.in @@ -6,6 +6,7 @@ datarootdir=@datarootdir@ libvirt_api=@datadir@/libvirt/api/libvirt-api.xml libvirt_qemu_api=@datadir@/libvirt/api/libvirt-qemu-api.xml +libvirt_lxc_api=@datadir@/libvirt/api/libvirt-lxc-api.xml Name: libvirt Version: @VERSION@ -- 1.8.3.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Stop free'ing 'const char *' strings
From: Daniel P. Berrange berra...@redhat.com
The VIR_FREE() macro will cast away any const-ness. This masked a
number of places where we passed a 'const char *' string to
VIR_FREE. Fortunately in all of these cases, the variable was not
in fact const data, but a heap allocated string. Fix all the
variable declarations to reflect this.
Signed-off-by: Daniel P. Berrange berra...@redhat.com
---
src/conf/domain_conf.c | 30 +++---
src/conf/netdev_vlan_conf.c| 4 ++--
src/conf/nwfilter_conf.c | 3 ++-
src/node_device/node_device_udev.c | 2 +-
src/nwfilter/nwfilter_gentech_driver.c | 2 +-
src/qemu/qemu_command.c| 33 +++--
src/qemu/qemu_domain.c | 2 +-
src/qemu/qemu_driver.c | 4 ++--
src/rpc/virnetsshsession.c | 34 +-
src/storage/storage_backend.c | 2 +-
src/storage/storage_driver.c | 2 +-
src/util/vircommand.c | 9 -
src/util/virlog.c | 4 ++--
tools/virsh-domain.c | 19 ++-
14 files changed, 82 insertions(+), 68 deletions(-)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index f8fbf79..678f8ca 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -6745,9 +6745,9 @@ virDomainChrDefParseTargetXML(virDomainChrDefPtr def,
{
int ret = -1;
unsigned int port;
-const char *targetType = virXMLPropString(cur, type);
-const char *addrStr = NULL;
-const char *portStr = NULL;
+char *targetType = virXMLPropString(cur, type);
+char *addrStr = NULL;
+char *portStr = NULL;
if ((def-targetType =
virDomainChrTargetTypeFromString(def, def-deviceType,
@@ -8161,7 +8161,7 @@ virDomainGraphicsDefParseXML(xmlNodePtr node,
while (cur != NULL) {
if (cur-type == XML_ELEMENT_NODE) {
if (xmlStrEqual(cur-name, BAD_CAST channel)) {
-const char *name, *mode;
+char *name, *mode;
int nameval, modeval;
name = virXMLPropString(cur, name);
mode = virXMLPropString(cur, mode);
@@ -8195,7 +8195,7 @@ virDomainGraphicsDefParseXML(xmlNodePtr node,
def-data.spice.channels[nameval] = modeval;
} else if (xmlStrEqual(cur-name, BAD_CAST image)) {
-const char *compression = virXMLPropString(cur,
compression);
+char *compression = virXMLPropString(cur, compression);
int compressionVal;
if (!compression) {
@@ -8216,7 +8216,7 @@ virDomainGraphicsDefParseXML(xmlNodePtr node,
def-data.spice.image = compressionVal;
} else if (xmlStrEqual(cur-name, BAD_CAST jpeg)) {
-const char *compression = virXMLPropString(cur,
compression);
+char *compression = virXMLPropString(cur, compression);
int compressionVal;
if (!compression) {
@@ -8237,7 +8237,7 @@ virDomainGraphicsDefParseXML(xmlNodePtr node,
def-data.spice.jpeg = compressionVal;
} else if (xmlStrEqual(cur-name, BAD_CAST zlib)) {
-const char *compression = virXMLPropString(cur,
compression);
+char *compression = virXMLPropString(cur, compression);
int compressionVal;
if (!compression) {
@@ -8258,7 +8258,7 @@ virDomainGraphicsDefParseXML(xmlNodePtr node,
def-data.spice.zlib = compressionVal;
} else if (xmlStrEqual(cur-name, BAD_CAST playback)) {
-const char *compression = virXMLPropString(cur,
compression);
+char *compression = virXMLPropString(cur, compression);
int compressionVal;
if (!compression) {
@@ -8279,7 +8279,7 @@ virDomainGraphicsDefParseXML(xmlNodePtr node,
def-data.spice.playback = compressionVal;
} else if (xmlStrEqual(cur-name, BAD_CAST streaming)) {
-const char *mode = virXMLPropString(cur, mode);
+char *mode = virXMLPropString(cur, mode);
int modeVal;
if (!mode) {
@@ -8299,7 +8299,7 @@ virDomainGraphicsDefParseXML(xmlNodePtr node,
def-data.spice.streaming = modeVal;
} else if (xmlStrEqual(cur-name, BAD_CAST clipboard)) {
-const char *copypaste = virXMLPropString(cur, copypaste);
+char *copypaste = virXMLPropString(cur, copypaste);
int copypasteVal;
if (!copypaste) {
@@ -8319,7 +8319,7 @@ virDomainGraphicsDefParseXML(xmlNodePtr node,
Re: [libvirt] [PATCHv5 5/5] domifaddr: Expose python binding
On 02/09/13 18:01, Nehal J Wani wrote:
On Sun, Sep 1, 2013 at 7:13 PM, Nehal J Wani nehaljw.k...@gmail.com wrote:
Expose virDomainInterfaceAddresses to python binding
examples/python/Makefile.am:
* Add new file domipaddrs.py
examples/python/README:
* Add documentation for the python example
python/libvirt-override-api.xml:
* Add new symbol for virDomainInterfaceAddresses
python/libvirt-override.c:
* Hand written python api
Example:
$ ./run python ./examples/python/domipaddrs.py f18
Interface MAC address Protocol Address
lo 00:00:00:00:00:00ipv4 127.0.0.1/8
lo 00:00:00:00:00:00ipv6 ::1/128
eth2 52:54:00:36:2a:e5
eth1 52:54:00:b1:70:19ipv4 192.168.105.201/16
eth1 52:54:00:b1:70:19ipv4 192.168.201.195/16
eth1 52:54:00:b1:70:19ipv6 fe80::5054:ff:feb1:7019/64
eth0 52:54:00:2e:45:ceipv4 10.1.33.188/24
eth0 52:54:00:2e:45:ceipv6 2001:db8:0:f101::2/64
eth0 52:54:00:2e:45:ceipv6 fe80::5054:ff:fe2e:45ce/64
---
examples/python/Makefile.am | 2 +-
examples/python/README | 1 +
examples/python/domipaddrs.py | 50 ++
python/libvirt-override-api.xml | 8 ++-
python/libvirt-override.c | 111
5 files changed, 170 insertions(+), 2 deletions(-)
create mode 100755 examples/python/domipaddrs.py
diff --git a/examples/python/Makefile.am b/examples/python/Makefile.am
index 2cacfa1..d33ee17 100644
--- a/examples/python/Makefile.am
+++ b/examples/python/Makefile.am
@@ -17,4 +17,4 @@
EXTRA_DIST=\
README \
consolecallback.py \
- dominfo.py domrestore.py domsave.py domstart.py esxlist.py
+ dominfo.py domrestore.py domsave.py domstart.py esxlist.py domipaddrs.py
diff --git a/examples/python/README b/examples/python/README
index f4db76c..1285d52 100644
--- a/examples/python/README
+++ b/examples/python/README
@@ -10,6 +10,7 @@ domsave.py - save all running domU's into a directory
domrestore.py - restore domU's from their saved files in a directory
esxlist.py - list active domains of an VMware ESX host and print some info.
also demonstrates how to use the libvirt.openAuth() method
+domipaddrs.py - print domain interfaces along with their MAC and IP addresses
The XML files in this directory are examples of the XML format that libvirt
expects, and will have to be adapted for your setup. They are only needed
diff --git a/examples/python/domipaddrs.py b/examples/python/domipaddrs.py
new file mode 100755
index 000..679e0bf
--- /dev/null
+++ b/examples/python/domipaddrs.py
@@ -0,0 +1,50 @@
+#!/usr/bin/env python
+# domipaddrds - print domain interfaces along with their MAC and IP addresses
+
+import libvirt
+import sys
+
+def usage():
+print Usage: %s [URI] DOMAIN % sys.argv[0]
+print Print domain interfaces along with their MAC and IP
addresses
+
+uri = None
+name = None
+args = len(sys.argv)
+
+if args == 2:
+name = sys.argv[1]
+elif args == 3:
+uri = sys.argv[1]
+name = sys.argv[2]
+else:
+usage()
+sys.exit(2)
+
+conn = libvirt.openReadOnly(uri)
+if conn == None:
+print Unable to open connection to libvirt
+sys.exit(1)
+
+try:
+dom = conn.lookupByName(name)
+except libvirt.libvirtError:
+print Domain %s not found % name
+sys.exit(0)
+
+ifaces = dom.interfaceAddresses(0)
+if (ifaces == None):
+print Failed to get domain interfaces
+sys.exit(0)
+
+print {0:10} {1:20} {2:12} {3}.format(Interface, MAC address, Protocol,
Address)
+
+for (name, val) in ifaces.iteritems():
+if val['ip_addrs']:
+for addr in val['ip_addrs']:
+ print {0:10} {1:19}.format(name, val['hwaddr']),
+ print {0:12} {1}/{2} .format(addr['type'], addr['addr'],
addr['prefix']),
+ print
+else:
+print {0:10} {1:19}.format(name, val['hwaddr']),
+print
diff --git a/python/libvirt-override-api.xml b/python/libvirt-override-api.xml
index 9a88215..60491de 100644
--- a/python/libvirt-override-api.xml
+++ b/python/libvirt-override-api.xml
@@ -602,5 +602,11 @@
arg name='conn' type='virConnectPtr' info='pointer to the hypervisor
connection'/
arg name='flags' type='int' info='unused, pass 0'/
/function
- /symbols
+function name='virDomainInterfaceAddresses' file='python'
+ inforeturns a dictionary of domain interfaces along with their MAC and IP
addresses/info
+ arg name='dom' type='virDomainPtr' info='pointer to the domain'/
+ arg name='flags' type='unsigned int' info='extra flags; not used yet, so
callers should always pass 0'/
+ return type='virDomainInterfacePtr' info=dictionary of domain interfaces along
with their MAC
Re: [libvirt] [PATCHv5 4/5] domifaddr: Add virsh support
On 01/09/13 21:43, Nehal J Wani wrote:
Use virDomainInterfaceAddresses in virsh
tools/virsh-domain-monitor.c
* Introduce new command : domifaddr
Usage: domifaddr domain [interface] [full]
As Daniel pointed out, it should be [--full]
Example output:
virsh # domifaddr f18
Name MAC address Protocol IP Address
---
lo 00:00:00:00:00:00ipv4 127.0.0.1/8
- -ipv6 ::1/128
eth0 52:54:00:2e:45:ceipv4 10.1.33.188/24
- -ipv6 2001:db8:0:f101::2/64
- -ipv6 fe80::5054:ff:fe2e:45ce/64
eth1 52:54:00:b1:70:19ipv4 192.168.105.201/16
- -ipv4 192.168.201.195/16
- -ipv6 fe80::5054:ff:feb1:7019/64
eth2 52:54:00:36:2a:e5
tools/virsh.pod
* Document new command
---
tools/virsh-domain-monitor.c | 119 +++
tools/virsh.pod | 11
2 files changed, 130 insertions(+)
diff --git a/tools/virsh-domain-monitor.c b/tools/virsh-domain-monitor.c
index b29b82a..cd1df7a 100644
--- a/tools/virsh-domain-monitor.c
+++ b/tools/virsh-domain-monitor.c
@@ -1871,6 +1871,119 @@ cleanup:
}
#undef FILTER
+/* domifaddr command
+ */
+static const vshCmdInfo info_domifaddr[] = {
+{help, N_(Get network interfaces' addresses for a running domain)},
+{desc, N_(Get network interfaces' addresses for a running domain)},
+{NULL, NULL}
+};
+
+static const vshCmdOptDef opts_domifaddr[] = {
+{domain, VSH_OT_DATA, VSH_OFLAG_REQ, N_(domain name, id or uuid)},
+{interface, VSH_OT_DATA, VSH_OFLAG_NONE, N_(network interface name)},
+{full, VSH_OT_BOOL, VSH_OFLAG_NONE, N_(display full fields)},
+{NULL, 0, 0, NULL}
+};
+
+static bool
+cmdDomIfAddr(vshControl *ctl, const vshCmd *cmd)
+{
+virDomainPtr dom = NULL;
+const char *interface = NULL;
+virDomainInterfacePtr *ifaces = NULL;
+size_t i, j;
+int ifaces_count = 0;
+unsigned int flags = 0;
+bool ret = false;
+bool optFull = vshCommandOptBool(cmd, full);
s/optFull/full/,
+
+if (!(dom = vshCommandOptDomain(ctl, cmd, NULL)))
+return false;
+
+if (vshCommandOptString(cmd, interface, interface) 0) {
+goto cleanup;
+}
+
+if ((ifaces_count = virDomainInterfaceAddresses(dom, ifaces, flags)) 0)
{
+vshError(ctl, _(Failed to query for interfaces addresses));
+goto cleanup;
+}
+
+vshPrintExtra(ctl, %-10s %-20s %-8s %s\n%s%s\n, _(Name),
+ _(MAC address), _(Protocol), _(Address),
+ _(-),
+ _(--));
+
+for (i = 0; i ifaces_count; i++) {
+virDomainInterfacePtr iface = ifaces[i];
+const char *hwaddr = ;
+const char *ip_addr_str = NULL;
+const char *type = NULL;
+
+if (interface STRNEQ(interface, iface-name))
+continue;
+
+if (iface-hwaddr)
+hwaddr = iface-hwaddr;
Variable hwaddr can be avoided? directly using iface-hwaddr
should be fine.
+
+/* When the interface has no IP address */
+if (!iface-naddrs) {
+vshPrintExtra(ctl, %-10s %-17s\n,
+ iface-name, hwaddr);
Not harm to add continue here. It will avoid the enter into the later
for loop.
And to be consistent, we use N/A if the field is empty in virsh, instead
of nothing in the output.
+}
+
+for (j = 0; j iface-naddrs; j++) {
+virBuffer buf = VIR_BUFFER_INITIALIZER;
+
+switch (iface-addrs[j].type) {
+case VIR_IP_ADDR_TYPE_IPV4:
+type = ipv4;
+break;
+case VIR_IP_ADDR_TYPE_IPV6:
+type = ipv6;
+break;
+}
+
+virBufferAsprintf(buf, %-12s %s/%d,
+ type, iface-addrs[j].addr,
+ iface-addrs[j].prefix);
+
+if (virBufferError(buf)) {
+virBufferFreeAndReset(buf);
+virReportOOMError();
+return ret;
Memory leak, need goto cleanup;
+}
+
+ip_addr_str = virBufferContentAndReset(buf);
+
+if (!ip_addr_str)
+ip_addr_str = ;
+
+/* Don't repeat interface name */
+if (optFull || !j)
+vshPrintExtra(ctl, %-10s %-17s%s\n,
+ iface-name, hwaddr, ip_addr_str);
+else
+vshPrintExtra(ctl, %-10s %-17s%s\n,
+ -,-,ip_addr_str);
-, -, ip_add_str);
I.E Add the space after ,
[libvirt] [PATCH] Don't call VIR_ALLOC on def-uuid in parallels storage driver
From: Daniel P. Berrange berra...@redhat.com
The 'uuid' field in virDomainDefPtr is not a pointer, it is a
fixed length array. Calling VIR_ALLOC on it is thus wrong and
leaks memory.
Signed-off-by: Daniel P. Berrange berra...@redhat.com
---
src/parallels/parallels_storage.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/src/parallels/parallels_storage.c
b/src/parallels/parallels_storage.c
index 3e254ce..44246a7 100644
--- a/src/parallels/parallels_storage.c
+++ b/src/parallels/parallels_storage.c
@@ -173,9 +173,6 @@ parallelsPoolCreateByPath(virConnectPtr conn, const char
*path)
if (!(def-name = parallelsMakePoolName(conn, path)))
goto error;
-if (VIR_ALLOC_N(def-uuid, VIR_UUID_BUFLEN))
-goto error;
-
if (virUUIDGenerate(def-uuid)) {
virReportError(VIR_ERR_INTERNAL_ERROR, %s,
_(Can't generate UUID));
--
1.8.3.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] test_virtlockd.aug.in: Use the correct file
The test should refer to Virtlockd.lns, which is the name of
the module + lens in virtlockd.aug.
Signed-off-by: Michal Privoznik mpriv...@redhat.com
---
src/locking/test_virtlockd.aug.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/locking/test_virtlockd.aug.in
b/src/locking/test_virtlockd.aug.in
index dcd47c3..799818e 100644
--- a/src/locking/test_virtlockd.aug.in
+++ b/src/locking/test_virtlockd.aug.in
@@ -5,7 +5,7 @@ log_outputs=\3:syslog:libvirtd\
log_buffer_size = 64
- test Libvirtd.lns get conf =
+ test Virtlockd.lns get conf =
{ log_level = 3 }
{ log_filters = 3:remote 4:event }
{ log_outputs = 3:syslog:libvirtd }
--
1.8.1.5
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Don't call VIR_ALLOC on def-uuid in parallels storage driver
On 09/03/13 17:42, Daniel P. Berrange wrote: From: Daniel P. Berrange berra...@redhat.com The 'uuid' field in virDomainDefPtr is not a pointer, it is a fixed length array. Calling VIR_ALLOC on it is thus wrong and leaks memory. Signed-off-by: Daniel P. Berrange berra...@redhat.com --- src/parallels/parallels_storage.c | 3 --- 1 file changed, 3 deletions(-) ACK. Peter signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Stop calling virAllocN directly from ESX code
On 09/03/13 17:56, Daniel P. Berrange wrote: From: Daniel P. Berrange berra...@redhat.com The ESX code has a method esxVI_Alloc which would call virAllocN directly, instead of using the VIR_ALLOC_N macro. Remove this method and make the callers just use VIR_ALLOC as is normal practice. Signed-off-by: Daniel P. Berrange berra...@redhat.com --- src/esx/esx_vi.c | 25 - src/esx/esx_vi.h | 3 --- src/esx/esx_vi_types.c | 11 +++ 3 files changed, 15 insertions(+), 24 deletions(-) ACK Peter signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Add missing 'libvirt_lxc_api' variable in pkg-config file
On 09/03/13 17:34, Daniel P. Berrange wrote: From: Daniel P. Berrange berra...@redhat.com The 'libvirt_lxc_api' variable is intended to allow apps to query the location of the API XML file for libvirt_lxc.so Signed-off-by: Daniel P. Berrange berra...@redhat.com --- libvirt.pc.in | 1 + 1 file changed, 1 insertion(+) ACK, Peter signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Stop free'ing 'const char *' strings
On 03.09.2013 17:35, Daniel P. Berrange wrote: From: Daniel P. Berrange berra...@redhat.com The VIR_FREE() macro will cast away any const-ness. This masked a number of places where we passed a 'const char *' string to VIR_FREE. Fortunately in all of these cases, the variable was not in fact const data, but a heap allocated string. Fix all the variable declarations to reflect this. Signed-off-by: Daniel P. Berrange berra...@redhat.com --- src/conf/domain_conf.c | 30 +++--- src/conf/netdev_vlan_conf.c| 4 ++-- src/conf/nwfilter_conf.c | 3 ++- src/node_device/node_device_udev.c | 2 +- src/nwfilter/nwfilter_gentech_driver.c | 2 +- src/qemu/qemu_command.c| 33 +++-- src/qemu/qemu_domain.c | 2 +- src/qemu/qemu_driver.c | 4 ++-- src/rpc/virnetsshsession.c | 34 +- src/storage/storage_backend.c | 2 +- src/storage/storage_driver.c | 2 +- src/util/vircommand.c | 9 - src/util/virlog.c | 4 ++-- tools/virsh-domain.c | 19 ++- 14 files changed, 82 insertions(+), 68 deletions(-) One question though, shouldn't we make VIR_FREE() pass const-ness now? Michal -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] conf: Remove the actual hostdev when removing a network
On 09/03/2013 09:29 AM, Peter Krempa wrote: Commit 50348e6edfa reused the code to remove the hostdev portion of a network definition on multiple places but forgot to take into account that sometimes the actual network is passed and in some cases the parent of that. This patch uses the virDomainNetGetActualHostdev() helper to acquire the correct pointer all the time while removing the hostdev portion from the list. --- src/conf/domain_conf.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) ACK. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Stop free'ing 'const char *' strings
On 03.09.2013 17:35, Daniel P. Berrange wrote: From: Daniel P. Berrange berra...@redhat.com The VIR_FREE() macro will cast away any const-ness. This masked a number of places where we passed a 'const char *' string to VIR_FREE. Fortunately in all of these cases, the variable was not in fact const data, but a heap allocated string. Fix all the variable declarations to reflect this. Signed-off-by: Daniel P. Berrange berra...@redhat.com --- src/conf/domain_conf.c | 30 +++--- src/conf/netdev_vlan_conf.c| 4 ++-- src/conf/nwfilter_conf.c | 3 ++- src/node_device/node_device_udev.c | 2 +- src/nwfilter/nwfilter_gentech_driver.c | 2 +- src/qemu/qemu_command.c| 33 +++-- src/qemu/qemu_domain.c | 2 +- src/qemu/qemu_driver.c | 4 ++-- src/rpc/virnetsshsession.c | 34 +- src/storage/storage_backend.c | 2 +- src/storage/storage_driver.c | 2 +- src/util/vircommand.c | 9 - src/util/virlog.c | 4 ++-- tools/virsh-domain.c | 19 ++- 14 files changed, 82 insertions(+), 68 deletions(-) ACK I've checked that you didn't miss anything by redefining VIR_FREE to virFree(ptr) and the compiler didn't warned about anything. There was one issue though and I wonder if we should notify xen developers. The xen_session struct contains session_id which is type of const char *. Michal -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Stop free'ing 'const char *' strings
On 09/03/2013 09:35 AM, Daniel P. Berrange wrote: From: Daniel P. Berrange berra...@redhat.com The VIR_FREE() macro will cast away any const-ness. This masked a number of places where we passed a 'const char *' string to VIR_FREE. Fortunately in all of these cases, the variable was not in fact const data, but a heap allocated string. Fix all the variable declarations to reflect this. I already have a patch pending review for a subset of this issue: https://www.redhat.com/archives/libvir-list/2013-August/msg01474.html I'm very much a fan of the idea. Signed-off-by: Daniel P. Berrange berra...@redhat.com --- src/conf/domain_conf.c | 30 +++--- src/conf/netdev_vlan_conf.c| 4 ++-- src/conf/nwfilter_conf.c | 3 ++- src/node_device/node_device_udev.c | 2 +- src/nwfilter/nwfilter_gentech_driver.c | 2 +- src/qemu/qemu_command.c| 33 +++-- src/qemu/qemu_domain.c | 2 +- src/qemu/qemu_driver.c | 4 ++-- src/rpc/virnetsshsession.c | 34 +- src/storage/storage_backend.c | 2 +- src/storage/storage_driver.c | 2 +- src/util/vircommand.c | 9 - src/util/virlog.c | 4 ++-- tools/virsh-domain.c | 19 ++- 14 files changed, 82 insertions(+), 68 deletions(-) Where's the actual patch to VIR_FREE to drop the const cast, and let the compiler enforce things so that we don't reintroduce the problem in the future? Other than that (which could be done as a followup patch), I agree with Michal's ack. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] test failure on rawhide
On 09/03/2013 05:00 AM, Laine Stump wrote: On 08/30/2013 11:26 PM, Eric Blake wrote: Just noticed this on latest rawhide (Fedora 21): Looks like the bug might not be libvirt's fault (as the assertion failure is not in our source file), but I'm out of time to investigate further today. $ VIR_TEST_DEBUG=1 ./virdrivermoduletest TEST: virdrivermoduletest 1) Test driver network ... OK 2) Test driver storage ... OK 3) Test driver nodedev ... OK 4) Test driver secret ... OK 5) Test driver nwfilter... OK 6) Test driver interface ... lt-virdrivermoduletest: route/tc.c:973: rtnl_tc_register: Assertion `0' failed. During the switch from libnl-1 to libnl-3, a similar (the same?) error meant that version of libnl used for the netcf build didn't match the version used for the libvirt build. That should be a thing of the distant past now though... This particular rawhide VM of mine has been incrementally updated since at least F15 days, which predates the libnl switch; I also noticed that I had libnl-devel but NOT libnl3-devel installed. I cleaned out the incremental stuff, installed libnl3-devel, and a build from scratch succeeded. So suspicions confirmed, and fixing my environment fixed the problem. But it DOES point out that maybe configure should try harder to die up front if mismatch is detected (ie. the wrong libnl-devel is installed) - I'll uninstall libnl3-devel, and play with it a bit more, before calling this thread done. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv5 1/5] domifaddr: Implement the public APIs
On 09/01/2013 07:43 AM, Nehal J Wani wrote:
Define a new API virDomainInterfaceAddresses, which returns
the address information of a running domain's interfaces(s).
If no interface name is specified, it returns the information
of all interfaces, otherwise it only returns the information
of the specificed interface. The address information includes
the MAC and IP addresses.
Define helper function virDomainInterfaceFree, which allows
the upper layer application to free the domain interface object
conveniently.
The API is going to provide multiple methods by flags, e.g.
* Query guest agent
* Parse lease file of dnsmasq
* DHCP snooping
But at this stage, it will only work with guest agent, and flags
won't be supported.
That worries me a bit. Ultimately, we want our interfaces to behave as
sane as possible when flags==0; rather than making the behavior be that
'flags==0' implies 'only guest agent probe', I'd rather introduce a flag
right away up front that says 'include guest agent probe in the set of
attempted methods', and then document that 'flags==0 is shorthand for
letting the hypervisor choose the best method(s) out of supported
possibilities)'. In other words, I want to make sure that this API will
be similar to virDomainShutdownFlags, where a flags of 0 lets the
hypervisor choose between methods, a single explicit flag forces the
hypervisor to use that method alone, and more than one flag can be OR'd
together to let the hypervisor choose among that subset of flags.
+char *addr; /* IP address */
+unsigned int prefix; /* IP address prefix */
Do we ever intend to support non-CIDR IPv4 addresses (where the mask is
not contiguous bits)? Or are we intentionally documenting that the
prefix will always be possible because we always require the mask to be
a contiguous prefix?
@@ -1238,6 +1243,7 @@ struct _virDriver {
virDrvDomainInterfaceStats domainInterfaceStats;
virDrvDomainSetInterfaceParameters domainSetInterfaceParameters;
virDrvDomainGetInterfaceParameters domainGetInterfaceParameters;
+virDrvDomainInterfaceAddressesdomainInterfaceAddresses;
Spacing is off; only one space needed.
+ *
+ * cleanup:
+ * if (ifaces)
+ * for (i = 0; i ifaces_count; i++)
+ * virDomainInterfaceFree(ifaces[i]);
+ * VIR_FREE(ifaces);
VIR_FREE() is not a public function; this comment should instead mention
free(); because it is in a comment, it will not trigger our syntax check
rules.
+int
+virDomainInterfaceAddresses(virDomainPtr dom,
+virDomainInterfacePtr **ifaces,
+unsigned int flags)
+{
+virConnectPtr conn;
+
+VIR_DOMAIN_DEBUG(dom, ifaces=%p, flags=%x, ifaces, flags);
+
+virResetLastError();
+
+if (!VIR_IS_CONNECTED_DOMAIN(dom)) {
+virLibDomainError(VIR_ERR_INVALID_DOMAIN, __FUNCTION__);
+virDispatchError(NULL);
+return -1;
+}
+
+conn = dom-conn;
Putting on my security hat - anything that requires guest interaction
should probably not be permitted from a read-only connection (because a
malicious guest coupled with a read-only caller purposefully exploiting
the guest's intentional bad behavior might open up a denial of service
against read-write clients). Again, all the more reason why I think you
should require non-zero flags before permitting guest agent interaction,
so that we can then add a security check here (if you pass flags=0, you
get the default set of actions that are safe for a read-only client; but
if you pass flags=..._AGENT, then we can prevent the call from
succeeding on a read-only client).
Overall, I'm happy with what we finally settled on for the API, and my
questions now only involve whether we need a non-zero flag before
allowing agent interaction.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv5 1/5] domifaddr: Implement the public APIs
On 09/03/2013 01:07 PM, Eric Blake wrote: On 09/01/2013 07:43 AM, Nehal J Wani wrote: Define a new API virDomainInterfaceAddresses, which returns the address information of a running domain's interfaces(s). If no interface name is specified, it returns the information of all interfaces, otherwise it only returns the information of the specificed interface. The address information includes the MAC and IP addresses. Define helper function virDomainInterfaceFree, which allows the upper layer application to free the domain interface object conveniently. The API is going to provide multiple methods by flags, e.g. * Query guest agent * Parse lease file of dnsmasq * DHCP snooping But at this stage, it will only work with guest agent, and flags won't be supported. That worries me a bit. Ultimately, we want our interfaces to behave as sane as possible when flags==0; rather than making the behavior be that 'flags==0' implies 'only guest agent probe', I'd rather introduce a flag right away up front that says 'include guest agent probe in the set of attempted methods', and then document that 'flags==0 is shorthand for letting the hypervisor choose the best method(s) out of supported possibilities)'. In other words, I want to make sure that this API will be similar to virDomainShutdownFlags, where a flags of 0 lets the hypervisor choose between methods, a single explicit flag forces the hypervisor to use that method alone, and more than one flag can be OR'd together to let the hypervisor choose among that subset of flags. Hmm. I'm replying to myself - is that a good sign? If the guest agent returns names that are provided by the guest, and don't necessarily correspond to the domain XML, then maybe it's best to NEVER return guest results by default, but to make the user always explicitly request agent interaction. That is, even if 'flags==0' is used to select between parsing the lease file vs. DHCP snoop results (both of which tie perfectly to guest XML naming), the agent approach can seriously confuse users if they passed flags==0 and don't know if they are getting XML names or guest-provided names. Which argues that guest results should ALWAYS be an explicit non-zero flag, never an automatic action. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv2 RESEND 3/5] vbox_tmpl.c: Better XML description for snapshots
Hi,
On Mon, Sep 02, 2013 at 06:05:51PM +0200, Manuel VIVES wrote:
It will be needed for the futur patches because we will
redefine snapshots
---
src/conf/domain_conf.c | 20 ++-
src/vbox/vbox_tmpl.c | 427
++--
2 files changed, 427 insertions(+), 20 deletions(-)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index f1623f1..c98ff63 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -16810,15 +16810,17 @@ virDomainDefFormatInternal(virDomainDefPtr def,
if (virDomainChrDefFormat(buf, console, flags) 0)
goto error;
}
-if (STREQ(def-os.type, hvm)
-def-nconsoles == 0
-def-nserials 0) {
-virDomainChrDef console;
-memcpy(console, def-serials[n], sizeof(console));
-console.deviceType = VIR_DOMAIN_CHR_DEVICE_TYPE_CONSOLE;
-console.targetType = VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SERIAL;
-if (virDomainChrDefFormat(buf, console, flags) 0)
-goto error;
+if (def-os.type) {
+if (STREQ(def-os.type, hvm)
+def-nconsoles == 0
+def-nserials 0) {
Maybe I'm missing something but this looks like:
if (STREQ_NULLABLE(def-os.type, hvm)
def-nconsoles == 0
def-nserials 0) {
is simpler.
Cheers,
-- Guido
+virDomainChrDef console;
+memcpy(console, def-serials[n], sizeof(console));
+console.deviceType = VIR_DOMAIN_CHR_DEVICE_TYPE_CONSOLE;
+console.targetType = VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SERIAL;
+if (virDomainChrDefFormat(buf, console, flags) 0)
+goto error;
+}
}
for (n = 0; n def-nchannels; n++)
diff --git a/src/vbox/vbox_tmpl.c b/src/vbox/vbox_tmpl.c
index 5e5ea85..ded179f 100644
--- a/src/vbox/vbox_tmpl.c
+++ b/src/vbox/vbox_tmpl.c
@@ -38,6 +38,7 @@
#include sys/types.h
#include sys/stat.h
#include fcntl.h
+#include libxml/xmlwriter.h
#include internal.h
#include datatypes.h
@@ -58,6 +59,8 @@
#include fdstream.h
#include viruri.h
#include virstring.h
+#include virtime.h
+#include virutil.h
/* This one changes from version to version. */
#if VBOX_API_VERSION == 2002
@@ -271,10 +274,16 @@ static vboxGlobalData *g_pVBoxGlobalData = NULL;
#endif /* VBOX_API_VERSION = 4000 */
+#define reportInternalErrorIfNS_FAILED(message) \
+if (NS_FAILED(rc)) { \
+virReportError(VIR_ERR_INTERNAL_ERROR, %s, _(message)); \
+goto cleanup; \
+}
+
+
static virDomainPtr vboxDomainDefineXML(virConnectPtr conn, const char *xml);
static int vboxDomainCreate(virDomainPtr dom);
static int vboxDomainUndefineFlags(virDomainPtr dom, unsigned int flags);
-
static void vboxDriverLock(vboxGlobalData *data) {
virMutexLock(data-lock);
}
@@ -283,6 +292,12 @@ static void vboxDriverUnlock(vboxGlobalData *data) {
virMutexUnlock(data-lock);
}
+typedef enum {
+VBOX_STORAGE_DELETE_FLAG = 0,
+#if VBOX_API_VERSION = 4002
+VBOX_STORAGE_CLOSE_FLAG = 1,
+#endif
+} vboxStorageDeleteOrCloseFlags;
#if VBOX_API_VERSION == 2002
static void nsIDtoChar(unsigned char *uuid, const nsID *iid) {
@@ -5907,7 +5922,8 @@ vboxDomainSnapshotCreateXML(virDomainPtr dom,
virCheckFlags(VIR_DOMAIN_SNAPSHOT_CREATE_NO_METADATA, NULL);
if (!(def = virDomainSnapshotDefParseString(xmlDesc, data-caps,
-data-xmlopt, 0, 0)))
+data-xmlopt, -1,
VIR_DOMAIN_SNAPSHOT_PARSE_DISKS |
+
VIR_DOMAIN_SNAPSHOT_PARSE_REDEFINE)))
goto cleanup;
if (def-ndisks) {
@@ -5915,7 +5931,6 @@ vboxDomainSnapshotCreateXML(virDomainPtr dom,
_(disk snapshots not supported yet));
goto cleanup;
}
-
vboxIIDFromUUID(domiid, dom-uuid);
rc = VBOX_OBJECT_GET_MACHINE(domiid.value, machine);
if (NS_FAILED(rc)) {
@@ -5923,7 +5938,6 @@ vboxDomainSnapshotCreateXML(virDomainPtr dom,
_(no domain with matching UUID));
goto cleanup;
}
-
rc = machine-vtbl-GetState(machine, state);
if (NS_FAILED(rc)) {
virReportError(VIR_ERR_INTERNAL_ERROR, %s,
@@ -5998,6 +6012,344 @@ cleanup:
return ret;
}
+#if VBOX_API_VERSION =4002
+static
+int vboxSnapshotGetReadWriteDisks(virDomainSnapshotDefPtr def,
+virDomainSnapshotPtr snapshot)
+{
+virDomainPtr dom = snapshot-domain;
+VBOX_OBJECT_CHECK(dom-conn, int, -1);
+vboxIID domiid = VBOX_IID_INITIALIZER;
+IMachine *machine = NULL;
+ISnapshot *snap = NULL;
+IMachine *snapMachine = NULL;
+bool error = false;
+vboxArray mediumAttachments = VBOX_ARRAY_INITIALIZER;
+PRUint32
Re: [libvirt] [PATCH] test_virtlockd.aug.in: Use the correct file
On Tue, Sep 03, 2013 at 09:17:47AM -0600, Eric Blake wrote:
On 09/03/2013 08:50 AM, Michal Privoznik wrote:
The test should refer to Virtlockd.lns, which is the name of
the module + lens in virtlockd.aug.
Signed-off-by: Michal Privoznik mpriv...@redhat.com
---
src/locking/test_virtlockd.aug.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Hmm, it looks like this was missed during Guido's commit 3e325448.
Hmm...while my src/locking/test_virtlockd.aug.in lacks this change my
build/src/test_virtlockd.aug has it so it seems I forgot to commit it
(otherwise the test would still fail) so ACK!
ACK.
diff --git a/src/locking/test_virtlockd.aug.in
b/src/locking/test_virtlockd.aug.in
index dcd47c3..799818e 100644
--- a/src/locking/test_virtlockd.aug.in
+++ b/src/locking/test_virtlockd.aug.in
@@ -5,7 +5,7 @@ log_outputs=\3:syslog:libvirtd\
log_buffer_size = 64
- test Libvirtd.lns get conf =
+ test Virtlockd.lns get conf =
{ log_level = 3 }
{ log_filters = 3:remote 4:event }
{ log_outputs = 3:syslog:libvirtd }
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/2] Handle a couple of new Coverity warnings
On 09/03/2013 07:55 AM, John Ferlan wrote: Coverity 6.6.1 was recently made available - installed it and a couple more RESOURCE_LEAK's were found in error paths. John Ferlan (2): esx_vi: Resolve Coverity RESOURCE_LEAK in error path esx_driver: Resolve Coverity RESOURCE_LEAK on error paths src/esx/esx_driver.c | 10 +- src/esx/esx_vi.c | 14 ++ 2 files changed, 19 insertions(+), 5 deletions(-) Pushed... Thanks for the quick review. John -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 01/12] libxl: Move detection of autoballoon to libxl_conf
Michal Privoznik wrote:
On 30.08.2013 23:46, Jim Fehlig wrote:
Detecting whether or not to autoballoon is configuration related,
so move the code to libxl_conf.
Signed-off-by: Jim Fehlig jfeh...@suse.com
---
src/libxl/libxl_conf.c | 22 ++
src/libxl/libxl_conf.h | 3 +++
src/libxl/libxl_driver.c | 25 +
3 files changed, 26 insertions(+), 24 deletions(-)
diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
index 8129c7f..f8937a4 100644
--- a/src/libxl/libxl_conf.c
+++ b/src/libxl/libxl_conf.c
@@ -978,6 +978,28 @@ error:
return -1;
}
+bool
+libxlGetAutoballoonConf(libxlDriverPrivatePtr driver)
+{
+const libxl_version_info *info;
+regex_t regex;
+int ret;
+
+info = libxl_get_version_info(driver-ctx);
+if (!info)
+return true; /* default to on */
+
+ret = regcomp(regex,
+(^| )dom0_mem=((|min:|max:)[0-9]+[bBkKmMgG]?,?)+($| ),
+REG_NOSUB | REG_EXTENDED);
+if (ret)
+return true;
Pre-existing, but if we fail to compile the regex, shouldn't we error out?
I think so, especially since patch 7 makes similar changes, e.g. bailing
out on libxl_get_version_info() failures.
I'll send a separate patch to fix this pre-existing issue.
Regards,
Jim
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 03/12] libxl: Earlier detection of not running on Xen
Daniel P. Berrange wrote:
On Fri, Aug 30, 2013 at 03:46:49PM -0600, Jim Fehlig wrote:
Detect early on in libxl driver initialization if the driver
should be loaded at all, avoiding needless initialization steps
that only have to be undone later. While at it, move th
detection to a helper function to improve readability.
After detecting that the driver should be loaded, subsequent
failures such as initializing the log stream, allocating libxl
ctx, etc. should be treated as failure to initialize the driver.
Signed-off-by: Jim Fehlig jfeh...@suse.com
---
src/libxl/libxl_driver.c | 62
+++-
1 file changed, 40 insertions(+), 22 deletions(-)
diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index ff4f6be..759fed5 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -775,34 +775,54 @@ libxlStateCleanup(void)
return 0;
}
-static int
-libxlStateInitialize(bool privileged,
- virStateInhibitCallback callback ATTRIBUTE_UNUSED,
- void *opaque ATTRIBUTE_UNUSED)
+static bool
+libxlDriverShouldLoad(bool privileged)
{
-const libxl_version_info *ver_info;
-char *log_file = NULL;
+bool ret = false;
virCommandPtr cmd;
-int status, ret = 0;
-unsigned int free_mem;
-char ebuf[1024];
+int status;
-/* Disable libxl driver if non-root */
+/* Don't load if non-root */
if (!privileged) {
VIR_INFO(Not running privileged, disabling libxenlight driver);
-return 0;
+return ret;
+}
+
+/* Don't load if not running on a Xen control domain (dom0) */
+if (!virFileExists(/proc/xen/capabilities)) {
+VIR_INFO(No Xen capabilities detected, probably not running
+ in a Xen Dom0. Disabling libxenlight driver);
+
+return ret;
}
-/* Disable driver if legacy xen toolstack (xend) is in use */
+ /* Don't load if legacy xen toolstack (xend) is in use */
Indentation typo
cmd = virCommandNewArgList(/usr/sbin/xend, status, NULL);
if (virCommandRun(cmd, status) == 0 status == 0) {
VIR_INFO(Legacy xen tool stack seems to be in use, disabling
libxenlight driver.);
-virCommandFree(cmd);
-return 0;
+} else {
+ret = true;
}
virCommandFree(cmd);
+return ret;
+}
+
+static int
+libxlStateInitialize(bool privileged,
+ virStateInhibitCallback callback ATTRIBUTE_UNUSED,
+ void *opaque ATTRIBUTE_UNUSED)
+{
+const libxl_version_info *ver_info;
+char *log_file = NULL;
+int ret = 0;
+unsigned int free_mem;
+char ebuf[1024];
+
+if (!libxlDriverShouldLoad(privileged))
+return 0;
+
if (VIR_ALLOC(libxl_driver) 0)
return -1;
@@ -883,21 +903,20 @@ libxlStateInitialize(bool privileged,
libxl_driver-logger =
(xentoollog_logger
*)xtl_createlogger_stdiostream(libxl_driver-logger_file, XTL_DEBUG, 0);
if (!libxl_driver-logger) {
-VIR_INFO(cannot create logger for libxenlight, disabling driver);
-goto fail;
+VIR_ERROR(_(Failed to create logger for libxenlight));
+goto error;
}
if (libxl_ctx_alloc(libxl_driver-ctx,
LIBXL_VERSION, 0,
libxl_driver-logger)) {
-VIR_INFO(cannot initialize libxenlight context, probably not
running
- in a Xen Dom0, disabling driver);
-goto fail;
+VIR_ERROR(_(Failed to initialize libxenlight context));
+goto error;
}
if ((ver_info = libxl_get_version_info(libxl_driver-ctx)) == NULL) {
-VIR_INFO(cannot version information from libxenlight, disabling
driver);
-goto fail;
+VIR_ERROR(_(Failed to get version information from libxenlight));
For the errors here, it is preferrable to use virReportError() which will
in turn call VIR_ERROR anywway.
I'll change these to virReportError(). Is it generally preferable to
use virReportError() over VIR_ERROR? If so, I'll send a followup patch
to replace any remaining uses of VIR_ERROR.
Regards,
Jim
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 07/12] libxl: Introduce libxlDriverConfig object
Michal Privoznik wrote:
On 30.08.2013 23:46, Jim Fehlig wrote:
The libxlDriverPrivate struct contains an variety of data with
varying access needs. Similar to the QEMU and LXC drivers,
move all the static config data into a dedicated libxlDriverConfig
object. The only locking requirement is to hold the driver lock
while obtaining an instance of libxlDriverConfig. Once a reference
is held on the config object, it can be used completely lockless
since it is immutable.
Signed-off-by: Jim Fehlig jfeh...@suse.com
---
src/libxl/libxl_conf.c | 124 ++-
src/libxl/libxl_conf.h | 52 +---
src/libxl/libxl_driver.c | 313
+++
3 files changed, 309 insertions(+), 180 deletions(-)
[...]
@@ -168,6 +177,8 @@ libxlSaveImageOpen(libxlDriverPrivatePtr driver, const
char *from,
virDomainDefPtr def = NULL;
libxlSavefileHeader hdr;
char *xml = NULL;
+libxlDriverConfigPtr cfg = libxlDriverConfigGet(driver);
+int ret = -1;
if ((fd = virFileOpenAs(from, O_RDONLY, 0, -1, -1, 0)) 0) {
virReportSystemError(-fd,
@@ -207,23 +218,25 @@ libxlSaveImageOpen(libxlDriverPrivatePtr driver, const
char *from,
goto error;
}
-if (!(def = virDomainDefParseString(xml, driver-caps, driver-xmlopt,
+if (!(def = virDomainDefParseString(xml, cfg-caps, driver-xmlopt,
1 VIR_DOMAIN_VIRT_XEN,
VIR_DOMAIN_XML_INACTIVE)))
goto error;
[...]
-VIR_FREE(xml);
-
*ret_def = def;
*ret_hdr = hdr;
-return fd;
+ret = fd;
+goto cleanup;
error:
-VIR_FREE(xml);
virDomainDefFree(def);
VIR_FORCE_CLOSE(fd);
-return -1;
+
+cleanup:
+VIR_FREE(xml);
+virObjectUnref(cfg);
+return ret;
In libvirt we rather have the 'error' label below the 'cleanup'. It's
more common to jump from the 'error' to 'cleanup' then. So can you
please swap these two?
Hmm, looking at this again I think adding the cleanup label was
overkill. I've changed the above two hunks to the following, which is a
bit simpler.
@@ -168,6 +177,7 @@ libxlSaveImageOpen(libxlDriverPrivatePtr driver,
const char *from,
virDomainDefPtr def = NULL;
libxlSavefileHeader hdr;
char *xml = NULL;
+libxlDriverConfigPtr cfg = libxlDriverConfigGet(driver);
if ((fd = virFileOpenAs(from, O_RDONLY, 0, -1, -1, 0)) 0) {
virReportSystemError(-fd,
@@ -207,12 +217,13 @@ libxlSaveImageOpen(libxlDriverPrivatePtr driver,
const char *from,
goto error;
}
-if (!(def = virDomainDefParseString(xml, driver-caps, driver-xmlopt,
+if (!(def = virDomainDefParseString(xml, cfg-caps, driver-xmlopt,
1 VIR_DOMAIN_VIRT_XEN,
VIR_DOMAIN_XML_INACTIVE)))
goto error;
VIR_FREE(xml);
+virObjectUnref(cfg);
*ret_def = def;
*ret_hdr = hdr;
@@ -221,6 +232,7 @@ libxlSaveImageOpen(libxlDriverPrivatePtr driver,
const char *from,
error:
VIR_FREE(xml);
+virObjectUnref(cfg);
virDomainDefFree(def);
VIR_FORCE_CLOSE(fd);
return -1;
Regards,
Jim
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 08/12] libxl: Use atomic ops for driver-nactive
Michal Privoznik wrote:
On 30.08.2013 23:46, Jim Fehlig wrote:
Signed-off-by: Jim Fehlig jfeh...@suse.com
---
src/libxl/libxl_conf.h | 2 +-
src/libxl/libxl_driver.c | 10 --
2 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/src/libxl/libxl_conf.h b/src/libxl/libxl_conf.h
index e3875ba..83bb6b9 100644
--- a/src/libxl/libxl_conf.h
+++ b/src/libxl/libxl_conf.h
@@ -90,7 +90,7 @@ struct _libxlDriverPrivate {
* then lockless thereafter */
libxlDriverConfigPtr config;
-size_t nactive;
+unsigned int nactive;
virStateInhibitCallback inhibitCallback;
void *inhibitOpaque;
diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index e604899..7615cdd 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -50,6 +50,7 @@
#include virstring.h
#include virsysinfo.h
#include viraccessapicheck.h
+#include viratomic.h
#define VIR_FROM_THIS VIR_FROM_LIBXL
@@ -265,8 +266,7 @@ libxlVmCleanup(libxlDriverPrivatePtr driver,
virDomainObjSetState(vm, VIR_DOMAIN_SHUTOFF, reason);
}
-driver-nactive--;
-if (!driver-nactive driver-inhibitCallback)
+if (virAtomicIntDecAndTest(driver-nactive) driver-inhibitCallback)
driver-inhibitCallback(false, driver-inhibitOpaque);
if ((vm-def-ngraphics == 1)
@@ -655,9 +655,8 @@ libxlVmStart(libxlDriverPrivatePtr driver,
virDomainObjPtr vm,
if (virDomainSaveStatus(driver-xmlopt, cfg-stateDir, vm) 0)
goto error;
-if (!driver-nactive driver-inhibitCallback)
+if (virAtomicIntInc(driver-nactive) driver-inhibitCallback)
driver-inhibitCallback(true, driver-inhibitOpaque);
Not exactly the same as previous code. Previously, the callback was
called iff nactive == 0; However, with your change the callback is
invoked each time the control gets to the 'if' (as virAtomicIntInc()
returns the *new* value after the increment). I think we want this to be:
if (virAtomicIntInc(driver-nactive) == 1 driver-inhibitCallback)
Opps, thanks for catching that. I've fixed both instances you pointed out.
Regards,
Jim
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 11/12] libxl: Remove unnecessary driver locking
Jim Fehlig wrote:
Now that most fields of libxlDriverPrivate struct are immutable
or self-locking, there is no need to acquire the driver lock in
much of the libxl driver.
Signed-off-by: Jim Fehlig jfeh...@suse.com
---
src/libxl/libxl_conf.c | 7 +-
src/libxl/libxl_driver.c | 217
+--
2 files changed, 46 insertions(+), 178 deletions(-)
diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
index 19fd8a6..34f6bc1 100644
--- a/src/libxl/libxl_conf.c
+++ b/src/libxl/libxl_conf.c
@@ -1110,7 +1110,12 @@ error:
libxlDriverConfigPtr
libxlDriverConfigGet(libxlDriverPrivatePtr driver)
{
-return virObjectRef(driver-config);
+libxlDriverConfigPtr cfg;
+
+libxlDriverLock(driver);
+cfg = virObjectRef(driver-config);
+libxlDriverUnlock(driver);
+return cfg;
}
virCapsPtr
diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index 8ece4c9..22bd26f 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -77,7 +77,6 @@ static int
libxlVmStart(libxlDriverPrivatePtr driver, virDomainObjPtr vm,
bool start_paused, int restore_fd);
-/* driver must be locked before calling */
static void
libxlDomainEventQueue(libxlDriverPrivatePtr driver, virDomainEventPtr event)
{
@@ -156,17 +155,21 @@ libxlDomainManagedSavePath(libxlDriverPrivatePtr
driver, virDomainObjPtr vm) {
return ret;
}
-/* This internal function expects the driver lock to already be held on
- * entry. */
-static int ATTRIBUTE_NONNULL(3) ATTRIBUTE_NONNULL(4)
-libxlSaveImageOpen(libxlDriverPrivatePtr driver, const char *from,
- virDomainDefPtr *ret_def, libxlSavefileHeaderPtr
ret_hdr)
+/*
+ * This internal function expects the driver lock to already be held on
+ * entry.
+ */
+static int ATTRIBUTE_NONNULL(4) ATTRIBUTE_NONNULL(5)
+libxlSaveImageOpen(libxlDriverPrivatePtr driver,
+ libxlDriverConfigPtr cfg,
+ const char *from,
+ virDomainDefPtr *ret_def,
+ libxlSavefileHeaderPtr ret_hdr)
{
int fd;
virDomainDefPtr def = NULL;
libxlSavefileHeader hdr;
char *xml = NULL;
-libxlDriverConfigPtr cfg = libxlDriverConfigGet(driver);
While rebasing this patch after making the changes to 7 suggested by
Michal, I realized that unref'ing the cfg object also needs to be
removed since it is now passed to this function and unref'ed by its
callers. Squashing in the following hunks before pushing
@@ -212,7 +215,6 @@ libxlSaveImageOpen(libxlDriverPrivatePtr driver,
const char *from,
goto error;
VIR_FREE(xml);
-virObjectUnref(cfg);
*ret_def = def;
*ret_hdr = hdr;
@@ -221,7 +223,6 @@ libxlSaveImageOpen(libxlDriverPrivatePtr driver,
const char *from,
error:
VIR_FREE(xml);
-virObjectUnref(cfg);
virDomainDefFree(def);
VIR_FORCE_CLOSE(fd);
return -1;
Regards,
Jim
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 2/n] build: only run fdstreamtest when libvirtd is built
An rpm build with client_only set to 1 (for example, RHEL 5 on s390, or by modifying libvirt.spec.in) failed with TEST: fdstreamtest 1) Stream read blocking ... OK 2) Stream read non-blocking ... Unexpected EOF block 0 want 128 FAILED 3) Stream write blocking ... OK 4) Stream write non-blocking ... Failed to finish stream: internal error: libvirt: error : cannot execute binary /home/eblake/rpmbuild/BUILD/libvirt-1.1.1/tests/../src/libvirt_iohelper: No such file or directory Since the test depends on something that was only built for WITH_LIBVIRTD (see src/Makefile.am), we must do the same for the test. * tests/Makefile.am (test_programs): Make fdstreamtest conditional. Signed-off-by: Eric Blake ebl...@redhat.com --- tests/Makefile.am | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/tests/Makefile.am b/tests/Makefile.am index c800179..f46ff56 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -128,10 +128,13 @@ test_programs = virshtest sockettest \ virportallocatortest \ sysinfotest \ virstoragetest \ -fdstreamtest \ fchosttest \ $(NULL) +if WITH_LIBVIRTD +test_programs += fdstreamtest +endif + if WITH_DBUS test_programs += virdbustest \ virsystemdtest -- 1.8.3.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] build: fix typo that broke 'make dist'
Otherwise, 'make dist' fails: make[3]: Entering directory `/home/eblake/libvirt-tmp/build3/examples/python' make[3]: *** No rule to make target `topoology.py', needed by `distdir'. Stop. make[3]: Leaving directory `/home/eblake/libvirt-tmp/build3/examples/python' * examples/python/Makefile.am (EXTRA_DIST): Spell topology right. Signed-off-by: Eric Blake ebl...@redhat.com --- Pushing under the build-breaker rule. examples/python/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/examples/python/Makefile.am b/examples/python/Makefile.am index d5d867c..7823c20 100644 --- a/examples/python/Makefile.am +++ b/examples/python/Makefile.am @@ -17,5 +17,5 @@ EXTRA_DIST=\ README \ consolecallback.py \ - topoology.py\ + topology.py \ dominfo.py domrestore.py domsave.py domstart.py esxlist.py -- 1.8.3.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Fix: Syle issues (daemon/remote.c)
Fix for argument layouts of various functions in daemon/remote.c. Refer:
https://www.redhat.com/archives/libvir-list/2013-September/msg00057.html
---
daemon/remote.c | 117 ++--
1 file changed, 55 insertions(+), 62 deletions(-)
diff --git a/daemon/remote.c b/daemon/remote.c
index 6ace7af..2aff7c1 100644
--- a/daemon/remote.c
+++ b/daemon/remote.c
@@ -3852,13 +3852,13 @@ cleanup:
return rv;
}
-static int remoteDispatchDomainGetDiskErrors(
-virNetServerPtr server ATTRIBUTE_UNUSED,
-virNetServerClientPtr client,
-virNetMessagePtr msg ATTRIBUTE_UNUSED,
-virNetMessageErrorPtr rerr,
-remote_domain_get_disk_errors_args *args,
-remote_domain_get_disk_errors_ret *ret)
+static int
+remoteDispatchDomainGetDiskErrors(virNetServerPtr server ATTRIBUTE_UNUSED,
+ virNetServerClientPtr client,
+ virNetMessagePtr msg ATTRIBUTE_UNUSED,
+ virNetMessageErrorPtr rerr,
+ remote_domain_get_disk_errors_args *args,
+ remote_domain_get_disk_errors_ret *ret)
{
int rv = -1;
virDomainPtr dom = NULL;
@@ -4674,13 +4674,12 @@ cleanup:
}
static int
-remoteDispatchDomainMigrateBegin3Params(
-virNetServerPtr server ATTRIBUTE_UNUSED,
-virNetServerClientPtr client ATTRIBUTE_UNUSED,
-virNetMessagePtr msg ATTRIBUTE_UNUSED,
-virNetMessageErrorPtr rerr,
-remote_domain_migrate_begin3_params_args *args,
-remote_domain_migrate_begin3_params_ret *ret)
+remoteDispatchDomainMigrateBegin3Params(virNetServerPtr server
ATTRIBUTE_UNUSED,
+virNetServerClientPtr client
ATTRIBUTE_UNUSED,
+virNetMessagePtr msg ATTRIBUTE_UNUSED,
+virNetMessageErrorPtr rerr,
+
remote_domain_migrate_begin3_params_args *args,
+
remote_domain_migrate_begin3_params_ret *ret)
{
char *xml = NULL;
virDomainPtr dom = NULL;
@@ -4733,13 +4732,12 @@ cleanup:
}
static int
-remoteDispatchDomainMigratePrepare3Params(
-virNetServerPtr server ATTRIBUTE_UNUSED,
-virNetServerClientPtr client ATTRIBUTE_UNUSED,
-virNetMessagePtr msg ATTRIBUTE_UNUSED,
-virNetMessageErrorPtr rerr,
-remote_domain_migrate_prepare3_params_args *args,
-remote_domain_migrate_prepare3_params_ret *ret)
+remoteDispatchDomainMigratePrepare3Params(virNetServerPtr server
ATTRIBUTE_UNUSED,
+ virNetServerClientPtr client
ATTRIBUTE_UNUSED,
+ virNetMessagePtr msg
ATTRIBUTE_UNUSED,
+ virNetMessageErrorPtr rerr,
+
remote_domain_migrate_prepare3_params_args *args,
+
remote_domain_migrate_prepare3_params_ret *ret)
{
virTypedParameterPtr params = NULL;
int nparams = 0;
@@ -4794,13 +4792,12 @@ cleanup:
}
static int
-remoteDispatchDomainMigratePrepareTunnel3Params(
-virNetServerPtr server ATTRIBUTE_UNUSED,
-virNetServerClientPtr client,
-virNetMessagePtr msg,
-virNetMessageErrorPtr rerr,
-remote_domain_migrate_prepare_tunnel3_params_args *args,
-remote_domain_migrate_prepare_tunnel3_params_ret *ret)
+remoteDispatchDomainMigratePrepareTunnel3Params(virNetServerPtr server
ATTRIBUTE_UNUSED,
+virNetServerClientPtr client,
+virNetMessagePtr msg,
+virNetMessageErrorPtr rerr,
+
remote_domain_migrate_prepare_tunnel3_params_args *args,
+
remote_domain_migrate_prepare_tunnel3_params_ret *ret)
{
virTypedParameterPtr params = NULL;
int nparams = 0;
@@ -4865,13 +4862,12 @@ cleanup:
static int
-remoteDispatchDomainMigratePerform3Params(
-virNetServerPtr server ATTRIBUTE_UNUSED,
-virNetServerClientPtr client ATTRIBUTE_UNUSED,
-virNetMessagePtr msg ATTRIBUTE_UNUSED,
-virNetMessageErrorPtr rerr,
-remote_domain_migrate_perform3_params_args *args,
-remote_domain_migrate_perform3_params_ret *ret)
+remoteDispatchDomainMigratePerform3Params(virNetServerPtr server
ATTRIBUTE_UNUSED,
+ virNetServerClientPtr client
ATTRIBUTE_UNUSED,
+ virNetMessagePtr msg
ATTRIBUTE_UNUSED,
+ virNetMessageErrorPtr rerr,
+
remote_domain_migrate_perform3_params_args *args,
+
[libvirt] [PATCH 1/n] spec: fix rpm build when lxc disabled
'make rpm' failed if ~/.rpmmacros contains '%_without_lxc 1',
which simulates the case of not having lxc available.
RPM build errors:
File not found:
/home/eblake/rpmbuild/BUILDROOT/libvirt-1.1.1-1.fc19.x86_64/etc/libvirt/virt-login-shell.conf
File not found by glob:
/home/eblake/rpmbuild/BUILDROOT/libvirt-1.1.1-1.fc19.x86_64/usr/share/man/man1/virt-login-shell.1*
File not found:
/home/eblake/rpmbuild/BUILDROOT/libvirt-1.1.1-1.fc19.x86_64/usr/bin/virt-login-shell
make: *** [rpm] Error 1
Reported by Dan Berrange.
* libvirt.spec.in: Mark virt-login-shell as conditional on lxc.
Signed-off-by: Eric Blake ebl...@redhat.com
---
I'm working on a couple more that I spotted while in the area:
we still unconditionally build vbox even though we recently
moved it into libvirtd for licensing reasons, which means a
client_only build will probably fall over on that; but while
testing my hypothesis, I discoverd that a client_only build
fails even earlier with:
TEST: fdstreamtest
1) Stream read blocking ... OK
2) Stream read non-blocking ...
Unexpected EOF block 0 want 128
FAILED
3) Stream write blocking ... OK
4) Stream write non-blocking ...
Failed to finish stream: internal error: libvirt: error : cannot execute
binary /home/eblake/rpmbuild/BUILD/libvirt-1.1.1/tests/../src/libvirt_iohelper:
No such file or directory
libvirt.spec.in | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libvirt.spec.in b/libvirt.spec.in
index e94901a..affd2ec 100644
--- a/libvirt.spec.in
+++ b/libvirt.spec.in
@@ -2014,17 +2014,23 @@ fi
%doc AUTHORS ChangeLog.gz NEWS README COPYING COPYING.LESSER TODO
%config(noreplace) %{_sysconfdir}/libvirt/libvirt.conf
+%if %{with_lxc}
%config(noreplace) %{_sysconfdir}/libvirt/virt-login-shell.conf
+%endif
%{_mandir}/man1/virsh.1*
%{_mandir}/man1/virt-xml-validate.1*
%{_mandir}/man1/virt-pki-validate.1*
%{_mandir}/man1/virt-host-validate.1*
+%if %{with_lxc}
%{_mandir}/man1/virt-login-shell.1*
+%endif
%{_bindir}/virsh
%{_bindir}/virt-xml-validate
%{_bindir}/virt-pki-validate
%{_bindir}/virt-host-validate
+%if %{with_lxc}
%attr(4755, root, root) %{_bindir}/virt-login-shell
+%endif
%{_libdir}/lib*.so.*
%if %{with_dtrace}
--
1.8.3.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH V3] Use loop-control to allocate loop device.
This patch changes virFileLoopDeviceOpen() to use the new loop-control
device to allocate a new loop device. If this behavior is unsupported
we fall back to the previous method of searching /dev for a free device.
With this patch you can start as many image based LXC domains as you
like (well almost).
Fixes bug https://bugzilla.redhat.com/show_bug.cgi?id=995543
V2:
- Modified to use a dedicated error return for loop-control allocation
function.
- Only do fallback if /dev/loop-control does not exist, otherwise return
error.
V3:
- Remove warning about falling back to search technique.
Signed-off-by: Ian Main im...@redhat.com
---
configure.ac | 12 ++
src/util/virfile.c | 70 +-
2 files changed, 81 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index ac8cfa1..10cd872 100644
--- a/configure.ac
+++ b/configure.ac
@@ -913,6 +913,18 @@ if test $with_lxc = yes || test $with_lxc = check;
then
AC_MSG_ERROR([Required kernel features for LXC were not found])
fi
])
+AC_LINK_IFELSE([AC_LANG_PROGRAM(
+[[
+#include sched.h
+#include linux/loop.h
+#include sys/epoll.h
+]], [[
+unshare(!(LOOP_CTL_GET_FREE));
+]])], [
+ AC_DEFINE([HAVE_DECL_LOOP_CTL_GET_FREE], [1],
+ [Define to 1 if you have the declaration of `LOOP_CTL_GET_FREE',
+ and to 0 if you don't.])
+])
fi
if test $with_lxc = yes ; then
AC_DEFINE_UNQUOTED([WITH_LXC], 1, [whether LXC driver is enabled])
diff --git a/src/util/virfile.c b/src/util/virfile.c
index 2b07ac9..9d42380 100644
--- a/src/util/virfile.c
+++ b/src/util/virfile.c
@@ -528,7 +528,56 @@ int virFileUpdatePerm(const char *path,
#if defined(__linux__) HAVE_DECL_LO_FLAGS_AUTOCLEAR
-static int virFileLoopDeviceOpen(char **dev_name)
+
+#if HAVE_DECL_LOOP_CTL_GET_FREE
+
+/* virFileLoopDeviceOpenLoopCtl() returns -1 when a real failure has occured
+ * while in the process of allocating or opening the loop device. On success
+ * we return 0 and modify the fd to the appropriate file descriptor.
+ * If /dev/loop-control does not exist, we return 0 and do not set fd. */
+
+static int virFileLoopDeviceOpenLoopCtl(char **dev_name, int *fd)
+{
+int devnr;
+int ctl_fd;
+char *looppath = NULL;
+
+VIR_DEBUG(Opening loop-control device);
+if ((ctl_fd = open(/dev/loop-control, O_RDWR)) 0) {
+virReportSystemError(errno, %s,
+ _(Unable to open /dev/loop-control));
+if (errno == ENOENT) {
+return 0;
+}
+return -1;
+}
+
+if ((devnr = ioctl(ctl_fd, LOOP_CTL_GET_FREE)) 0) {
+virReportSystemError(errno, %s,
+ _(Unable to get free loop device via ioctl));
+close(ctl_fd);
+return -1;
+}
+close(ctl_fd);
+
+VIR_DEBUG(Found free loop device number %i, devnr);
+
+if (virAsprintf(looppath, /dev/loop%i, devnr) 0)
+return -1;
+
+if ((*fd = open(looppath, O_RDWR)) 0) {
+virReportSystemError(errno,
+_(Unable to open %s), looppath);
+VIR_FREE(looppath);
+return -1;
+}
+
+*dev_name = looppath;
+return 0;
+}
+#endif /* HAVE_DECL_LOOP_CTL_GET_FREE */
+
+static int virFileLoopDeviceOpenSearch(char **dev_name)
{
int fd = -1;
DIR *dh = NULL;
@@ -601,6 +650,25 @@ cleanup:
return fd;
}
+static int virFileLoopDeviceOpen(char **dev_name)
+{
+int loop_fd = -1;
+
+#ifdef HAVE_DECL_LOOP_CTL_GET_FREE
+if (virFileLoopDeviceOpenLoopCtl(dev_name, loop_fd) 0)
+return -1;
+
+VIR_DEBUG(Return from loop-control got fd %d\n, loop_fd);
+
+if (loop_fd = 0)
+return loop_fd;
+#endif /* HAVE_DECL_LOOP_CTL_GET_FREE */
+
+/* Without the loop control device we just use the old technique. */
+loop_fd = virFileLoopDeviceOpenSearch(dev_name);
+
+return loop_fd;
+}
int virFileLoopDeviceAssociate(const char *file,
char **dev)
--
1.8.1.4
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 00/12] Various libxl driver improvements
Jim Fehlig wrote: This series contains several improvements for the libxl driver. Patches 1 and 2 are primarily code movement, putting code in files that are more consistent with other drivers. Patches 3 through 12 improve locking of the libxlDriverPrivate struct, similar to the work done in the QEMU and LXC drivers Obviously post-1.1.2 material, but would be nice to get it in soon thereafter for testing throughout the 1.1.3 cycle... Jim Fehlig (12): libxl: Move detection of autoballoon to libxl_conf libxl: Introduce libxl_domain.[ch] libxl: Earlier detection of not running on Xen libxl: Add libxl_version_info to libxlDriverPrivate libxl: libxl: Use per-domain ctx in libxlMakeDomCreateInfo libxl: User per-domain ctx in libxlDomainGetInfo libxl: Introduce libxlDriverConfig object libxl: Use atomic ops for driver-nactive libxl: Add comments to libxlDriverPrivate fields libxl: Move driver lock/unlock to libxl_conf libxl: Remove unnecessary driver locking libxl: Add libxlDomObjFromDomain I addressed the review comments from the various patches and pushed the series. Thanks for the reviews! Regards, Jim po/POTFILES.in |1 + src/Makefile.am |1 + src/libxl/libxl_conf.c | 149 +- src/libxl/libxl_conf.h | 87 +-- src/libxl/libxl_domain.c | 469 src/libxl/libxl_domain.h | 61 +++ src/libxl/libxl_driver.c | 1329 ++ 7 files changed, 1010 insertions(+), 1087 deletions(-) create mode 100644 src/libxl/libxl_domain.c create mode 100644 src/libxl/libxl_domain.h -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 02/12] libxl: Introduce libxl_domain.[ch]
Daniel P. Berrange wrote:
On Fri, Aug 30, 2013 at 03:46:48PM -0600, Jim Fehlig wrote:
Create libxl_domain.[ch] and move all functions operating on
libxlDomainObjPrivate to these files. This will be useful for
future patches that e.g. add job support for libxlDomainObjPrivate.
Signed-off-by: Jim Fehlig jfeh...@suse.com
---
po/POTFILES.in | 1 +
src/Makefile.am | 1 +
src/libxl/libxl_conf.c | 2 +-
src/libxl/libxl_conf.h | 18 --
src/libxl/libxl_domain.c | 469
+++
src/libxl/libxl_domain.h | 61 ++
src/libxl/libxl_driver.c | 436 +--
7 files changed, 535 insertions(+), 453 deletions(-)
diff --git a/po/POTFILES.in b/po/POTFILES.in
index 9a83069..281274e 100644
--- a/po/POTFILES.in
+++ b/po/POTFILES.in
@@ -67,6 +67,7 @@ src/lxc/lxc_conf.c
src/lxc/lxc_controller.c
src/lxc/lxc_driver.c
src/lxc/lxc_process.c
+src/libxl/libxl_domain.c
src/libxl/libxl_driver.c
src/libxl/libxl_conf.c
src/network/bridge_driver.c
diff --git a/src/Makefile.am b/src/Makefile.am
index d8b943d..82aefe3 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -657,6 +657,7 @@ XENAPI_DRIVER_SOURCES =
\
LIBXL_DRIVER_SOURCES = \
libxl/libxl_conf.c libxl/libxl_conf.h \
+libxl/libxl_domain.c libxl/libxl_domain.h \
libxl/libxl_driver.c libxl/libxl_driver.h
UML_DRIVER_SOURCES =\
diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
index f8937a4..f9ffe5d 100644
--- a/src/libxl/libxl_conf.c
+++ b/src/libxl/libxl_conf.c
@@ -39,7 +39,7 @@
#include viralloc.h
#include viruuid.h
#include capabilities.h
-#include libxl_driver.h
+#include libxl_domain.h
#include libxl_conf.h
#include libxl_utils.h
#include virstoragefile.h
diff --git a/src/libxl/libxl_conf.h b/src/libxl/libxl_conf.h
index 0498012..68e770c 100644
--- a/src/libxl/libxl_conf.h
+++ b/src/libxl/libxl_conf.h
@@ -89,24 +89,6 @@ struct _libxlDriverPrivate {
typedef struct _libxlEventHookInfo libxlEventHookInfo;
typedef libxlEventHookInfo *libxlEventHookInfoPtr;
-typedef struct _libxlDomainObjPrivate libxlDomainObjPrivate;
-typedef libxlDomainObjPrivate *libxlDomainObjPrivatePtr;
-struct _libxlDomainObjPrivate {
-virObjectLockable parent;
-
-/* per domain log stream for libxl messages */
-FILE *logger_file;
-xentoollog_logger *logger;
-/* per domain libxl ctx */
-libxl_ctx *ctx;
-/* console */
-virChrdevsPtr devs;
-libxl_evgen_domain_death *deathW;
-
-/* list of libxl timeout registrations */
-libxlEventHookInfoPtr timerRegistrations;
-};
-
# define LIBXL_SAVE_MAGIC libvirt-xml\n \0 \r
# define LIBXL_SAVE_VERSION 1
diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
new file mode 100644
index 000..1d03797
--- /dev/null
+++ b/src/libxl/libxl_domain.c
@@ -0,0 +1,469 @@
+/*---*/
+/* Copyright (C) 2011-2013 SUSE LINUX Products GmbH, Nuernberg, Germany.
It is a pretty minor nitpick, but the normal style
/*
* filename.h: blah description blah
*
* Copyright (C) 2013
without any '/*---'
Ok, I'll change this and send a followup patch for the other libxl files
that similarly deviate from the norm :).
Regards,
Jim
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [libvirt-users] Is virsh blockcommit supported? Thanks a lot
Hi, I have another question, when I do the blockcommit command and get the result Top image as the active layer is currently unsupported , is it being developed? root@cvk-31:/vms/images# virsh blockcommit Vmtest /vms/images/Vmtest1;echo $? error: internal error unable to execute QEMU command 'block-commit': Top image as the active layer is currently unsupported 1 But as I specified the commit file which is not the current image file, it will be work, such as below: root@cvk-31:/vms/images# qemu-img info --backing-chain /vms/images/Vmtest1 image: /vms/images/Vmtest1 file format: qcow2 virtual size: 9.8G (1048576 bytes) disk size: 18M cluster_size: 65536 backing file: /vms/images/Vmtest1_base_1 backing file format: qcow2 image: /vms/images/Vmtest1_base_1 file format: qcow2 virtual size: 9.8G (1048576 bytes) disk size: 196K cluster_size: 65536 backing file: /vms/images/Vmtest1_base backing file format: qcow2 image: /vms/images/Vmtest1_base file format: qcow2 virtual size: 9.8G (1048576 bytes) disk size: 3.4G cluster_size: 2097152 root@cvk-31:/vms/images# virsh blockcommit Vmtest /vms/images/Vmtest1 --base /vms/images/Vmtest1_base --top /vms/images/Vmtest1_base_1 --wait --verbose;echo $? Block Commit: [100 %] Commit complete 0 - 本邮件及其附件含有杭州华三通信技术有限公司的保密信息，仅限于发送给上面地址中列出 的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、 或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本 邮件！ This e-mail and its attachments contain confidential information from H3C, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [libvirt-users] Is virsh blockcommit supported? Thanks a lot
On 09/03/2013 06:56 PM, Guozhonghua wrote: Hi, I have another question, when I do the blockcommit command and get the result Top image as the active layer is currently unsupported , is it being developed? root@cvk-31:/vms/images# virsh blockcommit Vmtest /vms/images/Vmtest1;echo $? error: internal error unable to execute QEMU command 'block-commit': Top image as the active layer is currently unsupported Yes, patches have been proposed to upstream qemu for that feature, but they missed 1.6, so you will have to wait for qemu 1.7. There may also be some integration efforts that require tweaks to libvirt to take advantage of the qemu feature (the libvirt API was designed to work as soon as qemu added support, but we haven't yet proven whether our plans work out as nicely as we hope). -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
