June 2014 - Devel - Libvirt List Archives

[libvirt] [PATCH] tests: Build virstoragetest only when storage driver is compiled too

by Peter Krempa

virstoragetest now requires parts of the storage driver to be built. Without this change the test can't be compiled on platforms that don't build the storage driver (mingw). make[2]: *** No rule to make target `../src/libvirt_driver_storage_impl.la', needed by `virstoragetest.exe'. Stop. Broken by commit 713cc3b0a7ff8ad42b4c13429b624d1b2b5a99f2 --- tests/Makefile.am | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tests/Makefile.am b/tests/Makefile.am index f9f2b84..1fdfd3b 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -162,7 +162,6 @@ test_programs = virshtest sockettest \ virstringtest \ virportallocatortest \ sysinfotest \ - virstoragetest \ virnetdevbandwidthtest \ virkmodtest \ vircapstest \ @@ -279,7 +278,8 @@ test_programs += nwfilterxml2firewalltest endif WITH_NWFILTER if WITH_STORAGE -test_programs += storagevolxml2argvtest +test_programs += storagevolxml2argvtest \ + virstoragetest endif WITH_STORAGE if WITH_LINUX -- 1.9.3

10 years, 5 months

2
2
0 / 0

[libvirt] Idea for representing VMX virtualHW.version in domain XML

by Daniel P. Berrange

At the Xen Hackathon we were discussing dealing hypervisors which have a "virtual hardware version" concept, like VMWares' virtualHW.version. Currently our code mostly ignores the virtualHW.version when reading VMX files, and when writing them, just uses the hypervisor's default virtual hardware version. This is sub-optimal since that means the guest's hardware version could change if the hypervisor is upgraded, which could in turn cause Windows re-activation. It was suggested to me that the virtualHW.version is really akin to QEMU's machine type concept, and so we should map it that way in the XML. eg if the VMX file contains virtualHW.version = "4" Then we might represent that in the XML as <domain type='vmware'> ... <os> <type machine="vmware4">hvm</type> </os> ... </domain> ie we just invent a machine type prefix and append the version number to it. I'm not planning on implementing this myself, just sending this mail so the idea is in the historical record and some other motivated person can wire it up.... 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 :|

10 years, 5 months

1
0
0 / 0

[libvirt] [PATCH 0/5] Testing libvirt XML -> libxl_domain_config conversion

by Daniel P. Berrange

At the Xen Hackathon I learnt that libxl provides an API which can serialize a libxl_domain_config instance to a JSON document. This is exactly what we need for testing the XML -> libxl_domain_config conversion process, so I spent the afternoon trying to get such a test working. The result is that we can now just add pairs of XML, JSON files to libvirt to test handling of new config features. I hit a couple of small issues with libxl, which I worked around, when writing this test which I why I'm copying xen-devel - libxl_ctx_alloc() will call xs_daemon_open and xc_interface_open, and stat /var/run/xenstored.pid to see if Xen is actually running. This fails when run on non-Xen hosts (and also possibly if run unprivileged). I used an evil LD_PRELOAD hack to stub out xs_daemon_open and xc_interface_open to return (void*)0x1, and also turn xc_interface_close and xs_daemon_close to no-ops, and make stat() always return success for xenstored.pid. This works (evidenced by the fact that if something was needing these xs/xc handles they would have crashed referencing 0x1), but at the same time it might be an idea to have an officially supported "non live" mode for libxl_ctx_alloc() turned on by a flag of some sort. - The libxl_json.h header file is relying on conditionals that are only set by Xen's build process eg HAVE_YAJL_YAJL_VERSION_H I hacked around this, but it is a little dirty too. libvirt already links to libyajl for the QEMU driver, but we don't really need the raw YAJL objects. It'd be nice to have a char * libxl_domain_config_as_json(libxl_domain_config *p) as a higher level wrapper around libxl_domain_config_gen_json avoiding the pain of dealing with YAJL's different APIs. Ian J mentioned to me that he thought there was already such a method, but AFAICT, the only such code is in the 'xl' command line tool itself (xl_cmdimpl.c - printf_info_one_json) A few further ideas that could be done as a followup - Make virConnectDomainXMLToNative accept 'xl-json" as a data format, so you can feed in a libvirt XML and get back out a JSON document. This could be a useful debugging tool for Xen developers trying to identify bugs in libvirt. - Write out the JSON document to /var/log/libvirt/libxl/$GUEST.log whenever starting a guest. Again this would be a useful debugging aid to Xen developers / support people trying to identify why a guest might be mis-behaving Regards, Daniel Daniel P. Berrange (5): Don't pass virDomainObjPtr to libxlBuildDomainConfig Don't pass libxlDriverPrivatePtr into libxlBuildDomainConfig libxl: Move virDomainXMLOptionNew into libxlCreateXMLConf Add more test suite mock helpers Add a test suite for libxl option generator src/libxl/libxl_conf.c | 38 +++--- src/libxl/libxl_conf.h | 10 +- src/libxl/libxl_domain.c | 7 +- src/libxl/libxl_driver.c | 4 +- tests/Makefile.am | 25 +++- tests/libxlxml2jsondata/minimal.json | 172 +++++++++++++++++++++++++++ tests/libxlxml2jsondata/minimal.xml | 36 ++++++ tests/libxlxml2jsontest.c | 219 +++++++++++++++++++++++++++++++++++ tests/virfirewalltest.c | 4 +- tests/virmock.h | 54 ++++++--- tests/virmocklibxl.c | 87 ++++++++++++++ tests/virsystemdtest.c | 4 +- 12 files changed, 617 insertions(+), 43 deletions(-) create mode 100644 tests/libxlxml2jsondata/minimal.json create mode 100644 tests/libxlxml2jsondata/minimal.xml create mode 100644 tests/libxlxml2jsontest.c create mode 100644 tests/virmocklibxl.c -- 1.9.3

10 years, 5 months

3
17
0 / 0

[libvirt] [libvirt-glib] [PATCH v3] GVirDomainSnapshot: Add gvir_domain_snapshot_delete

by Timm Bäder

--- libvirt-gobject/libvirt-gobject-domain-snapshot.c | 29 +++++++++++++++++++++++ libvirt-gobject/libvirt-gobject-domain-snapshot.h | 16 +++++++++++++ libvirt-gobject/libvirt-gobject.sym | 6 +++++ 3 files changed, 51 insertions(+) diff --git a/libvirt-gobject/libvirt-gobject-domain-snapshot.c b/libvirt-gobject/libvirt-gobject-domain-snapshot.c index fcf70ed..f835b58 100644 --- a/libvirt-gobject/libvirt-gobject-domain-snapshot.c +++ b/libvirt-gobject/libvirt-gobject-domain-snapshot.c @@ -205,3 +205,32 @@ GVirConfigDomainSnapshot *gvir_domain_snapshot_get_config free(xml); return conf; } + +/** + * gvir_domain_snapshot_delete: + * @snapshot: The domain snapshot + * @flags: Bitwise or of #GVirDomainSnapshotDeleteFlags + * @error: (allow-none): Place-holder for error or NULL + * + * Returns: TRUE on success, FALSE otherwise + */ +gboolean gvir_domain_snapshot_delete (GVirDomainSnapshot *snapshot, + guint flags, + GError **error) +{ + GVirDomainSnapshotPrivate *priv; + int status; + + g_return_if_fail(GVIR_IS_DOMAIN_SNAPSHOT (snapshot)); + g_return_if_fail(error == NULL || *error == NULL); + + priv = snapshot->priv; + status = virDomainSnapshotDelete(priv->handle, flags); + if (status < 0) { + gvir_set_error(error, GVIR_DOMAIN_SNAPSHOT_ERROR, 0, + "Unable to delete snapshot `%s'", + gvir_domain_snapshot_get_name(snapshot)); + return FALSE; + } + return TRUE; +} diff --git a/libvirt-gobject/libvirt-gobject-domain-snapshot.h b/libvirt-gobject/libvirt-gobject-domain-snapshot.h index 5bd827c..b3ebe7f 100644 --- a/libvirt-gobject/libvirt-gobject-domain-snapshot.h +++ b/libvirt-gobject/libvirt-gobject-domain-snapshot.h @@ -58,6 +58,18 @@ struct _GVirDomainSnapshotClass gpointer padding[20]; }; +/** + * GVirDomainSnapshotDeleteFlags: + * @GVIR_DOMAIN_SNAPSHOT_DELETE_CHILDREN: Also delete children + * @GVIR_DOMAIN_SNAPSHOT_DELETE_METADATA_ONLY: Delete just metadata + * @GVIR_DOMAIN_SNAPSHOT_DELETE_CHILDREN_ONLY: Delete just children + */ +typedef enum { + GVIR_DOMAIN_SNAPSHOT_DELETE_CHILDREN = 1, + GVIR_DOMAIN_SNAPSHOT_DELETE_METADATA_ONLY = 2, + GVIR_DOMAIN_SNAPSHOT_DELETE_CHILDREN_ONLY = 4 +} GVirDomainSnapshotDeleteFlags; + GType gvir_domain_snapshot_get_type(void); GType gvir_domain_snapshot_handle_get_type(void); @@ -69,6 +81,10 @@ GVirConfigDomainSnapshot *gvir_domain_snapshot_get_config guint flags, GError **err); +gboolean gvir_domain_snapshot_delete (GVirDomainSnapshot *snapshot, + guint flags, + GError **error); + G_END_DECLS #endif /* __LIBVIRT_GOBJECT_DOMAIN_SNAPSHOT_H__ */ diff --git a/libvirt-gobject/libvirt-gobject.sym b/libvirt-gobject/libvirt-gobject.sym index f2419ac..232e63b 100644 --- a/libvirt-gobject/libvirt-gobject.sym +++ b/libvirt-gobject/libvirt-gobject.sym @@ -234,4 +234,10 @@ LIBVIRT_GOBJECT_0.1.5 { gvir_connection_open_read_only_finish; } LIBVIRT_GOBJECT_0.1.4; +LIBVIRT_GOBJECT_0.1.9 { + global: + gvir_domain_snapshot_delete_flags_get_type; + gvir_domain_snapshot_delete; +} LIBVIRT_GOBJECT_0.1.5; + # .... define new API here using predicted next version number .... -- 2.0.0

10 years, 5 months

2
2
0 / 0

[libvirt] [PATCH v2 0/4] qemu: Some more device unplug fixes

by Jiri Denemark

Jiri Denemark (4): qemu: Remove interface backend only after frontend is gone qemu: Remove disk backend only after frontend is gone qemu: Remove character device backend only after frontend is gone qemu: Return in from qemuDomainRemove*Device src/qemu/qemu_hotplug.c | 162 +++++++++++++++++++++++++----------------------- 1 file changed, 84 insertions(+), 78 deletions(-) -- 2.0.0

10 years, 5 months

2
9
0 / 0

[libvirt] [libvirt-glib] [PATCH] Remove #if 0's from libvirt-gobject-domain-snapshot

by Timm Bäder

The code seems to be fine. --- I'd like to use this code (in later patches). If anything is wrong with the current implementation, I'd like to know so I can fix it. libvirt-gobject/libvirt-gobject-domain-snapshot.c | 10 +--------- 1 file changed, 1 insertion(+), 9 deletions(-) diff --git a/libvirt-gobject/libvirt-gobject-domain-snapshot.c b/libvirt-gobject/libvirt-gobject-domain-snapshot.c index d4e9b97..ab23342 100644 --- a/libvirt-gobject/libvirt-gobject-domain-snapshot.c +++ b/libvirt-gobject/libvirt-gobject-domain-snapshot.c @@ -144,9 +144,7 @@ typedef struct virDomainSnapshot GVirDomainSnapshotHandle; static GVirDomainSnapshotHandle* gvir_domain_snapshot_handle_copy(GVirDomainSnapshotHandle *src) { -#if 0 virDomainSnapshotRef((virDomainSnapshotPtr)src); -#endif return src; } @@ -162,7 +160,7 @@ G_DEFINE_BOXED_TYPE(GVirDomainSnapshotHandle, gvir_domain_snapshot_handle, const gchar *gvir_domain_snapshot_get_name(GVirDomainSnapshot *snapshot) { g_return_val_if_fail(GVIR_IS_DOMAIN_SNAPSHOT(snapshot), NULL); -#if 0 + GVirDomainSnapshotPrivate *priv = snapshot->priv; const char *name; @@ -172,12 +170,6 @@ const gchar *gvir_domain_snapshot_get_name(GVirDomainSnapshot *snapshot) } return name; -#else - if (snapshot) - return NULL; -#endif - - g_return_val_if_reached(NULL); } -- 1.9.3

10 years, 5 months

3
3
0 / 0

[libvirt] [PATCH] xenapi_utils: Adapt to enum cleanups

by Michal Privoznik

It was just very recently that we transfered from: enum virSomeEnumName{ ... }; to: typedef enum { ... } virSomeEnumName; This change requires some code adaptation, which wasn't done for xenapi driver. With this fix we are able to build again. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- Pushed under build breaker rule. src/xenapi/xenapi_utils.c | 14 +++++++------- src/xenapi/xenapi_utils.h | 10 +++++----- 2 files changed, 12 insertions(+), 12 deletions(-) diff --git a/src/xenapi/xenapi_utils.c b/src/xenapi/xenapi_utils.c index c9a62d9..156e0c8 100644 --- a/src/xenapi/xenapi_utils.c +++ b/src/xenapi/xenapi_utils.c @@ -127,7 +127,7 @@ xenapiUtil_ParseQuery(virConnectPtr conn, virURIPtr uri, int *noVerify) enum xen_on_normal_exit -actionShutdownLibvirt2XenapiEnum(enum virDomainLifecycleAction action) +actionShutdownLibvirt2XenapiEnum(virDomainLifecycleAction action) { enum xen_on_normal_exit num = XEN_ON_NORMAL_EXIT_RESTART; if (action == VIR_DOMAIN_LIFECYCLE_DESTROY) @@ -139,7 +139,7 @@ actionShutdownLibvirt2XenapiEnum(enum virDomainLifecycleAction action) enum xen_on_crash_behaviour -actionCrashLibvirt2XenapiEnum(enum virDomainLifecycleCrashAction action) +actionCrashLibvirt2XenapiEnum(virDomainLifecycleCrashAction action) { enum xen_on_crash_behaviour num = XEN_ON_CRASH_BEHAVIOUR_RESTART; if (action == VIR_DOMAIN_LIFECYCLE_CRASH_DESTROY) @@ -180,7 +180,7 @@ createXenAPIBootOrderString(int nboot, int *bootDevs) } /* convert boot order string to libvirt boot order enum */ -enum virDomainBootOrder +virDomainBootOrder map2LibvirtBootOrder(char c) { switch (c) { @@ -197,10 +197,10 @@ map2LibvirtBootOrder(char c) } } -enum virDomainLifecycleAction +virDomainLifecycleAction xenapiNormalExitEnum2virDomainLifecycle(enum xen_on_normal_exit action) { - enum virDomainLifecycleAction num = VIR_DOMAIN_LIFECYCLE_RESTART; + virDomainLifecycleAction num = VIR_DOMAIN_LIFECYCLE_RESTART; if (action == XEN_ON_NORMAL_EXIT_DESTROY) num = VIR_DOMAIN_LIFECYCLE_DESTROY; else if (action == XEN_ON_NORMAL_EXIT_RESTART) @@ -209,10 +209,10 @@ xenapiNormalExitEnum2virDomainLifecycle(enum xen_on_normal_exit action) } -enum virDomainLifecycleCrashAction +virDomainLifecycleCrashAction xenapiCrashExitEnum2virDomainLifecycle(enum xen_on_crash_behaviour action) { - enum virDomainLifecycleCrashAction num = VIR_DOMAIN_LIFECYCLE_CRASH_RESTART; + virDomainLifecycleCrashAction num = VIR_DOMAIN_LIFECYCLE_CRASH_RESTART; if (action == XEN_ON_CRASH_BEHAVIOUR_DESTROY) num = VIR_DOMAIN_LIFECYCLE_CRASH_DESTROY; else if (action == XEN_ON_CRASH_BEHAVIOUR_RESTART) diff --git a/src/xenapi/xenapi_utils.h b/src/xenapi/xenapi_utils.h index 31b313b..26e1ac2 100644 --- a/src/xenapi/xenapi_utils.h +++ b/src/xenapi/xenapi_utils.h @@ -43,20 +43,20 @@ int xenapiUtil_ParseQuery(virConnectPtr conn, virURIPtr uri, int *noVerify); enum xen_on_normal_exit -actionShutdownLibvirt2XenapiEnum(enum virDomainLifecycleAction action); +actionShutdownLibvirt2XenapiEnum(virDomainLifecycleAction action); enum xen_on_crash_behaviour -actionCrashLibvirt2XenapiEnum(enum virDomainLifecycleCrashAction action); +actionCrashLibvirt2XenapiEnum(virDomainLifecycleCrashAction action); char * createXenAPIBootOrderString(int nboot, int *bootDevs); -enum virDomainBootOrder map2LibvirtBootOrder(char c); +virDomainBootOrder map2LibvirtBootOrder(char c); -enum virDomainLifecycleAction +virDomainLifecycleAction xenapiNormalExitEnum2virDomainLifecycle(enum xen_on_normal_exit action); -enum virDomainLifecycleCrashAction +virDomainLifecycleCrashAction xenapiCrashExitEnum2virDomainLifecycle(enum xen_on_crash_behaviour action); void getCpuBitMapfromString(char *mask, unsigned char *cpumap, int maplen); -- 2.0.0

10 years, 5 months

1
0
0 / 0

[libvirt] [PATCH 1/3] cpu: use typedefs for enums in "src/cpu/cpu_map.h"

by Julio Faracco

In "src/cpu/" there are some enumerations (enum) declarations. Similar to the recent cleanup to "src/util", "src/conf" and other directories, it's better to use a typedef for variable types, function types and other usages. Other enumeration and folders will be changed to typedef's in the future. Specially, in files that are in different places of "src/util" and "src/conf". Most of the files changed in this commit are related to CPU (cpu_map.h) enums. Signed-off-by: Julio Faracco <jcfaracco(a)gmail.com> --- src/cpu/cpu.c | 2 +- src/cpu/cpu_map.c | 2 +- src/cpu/cpu_map.h | 6 +++--- src/cpu/cpu_powerpc.c | 2 +- src/cpu/cpu_x86.c | 2 +- 5 files changed, 7 insertions(+), 7 deletions(-) diff --git a/src/cpu/cpu.c b/src/cpu/cpu.c index 528e1a7..c3d66dd 100644 --- a/src/cpu/cpu.c +++ b/src/cpu/cpu.c @@ -729,7 +729,7 @@ struct cpuGetModelsData }; static int -cpuGetArchModelsCb(enum cpuMapElement element, +cpuGetArchModelsCb(cpuMapElement element, xmlXPathContextPtr ctxt, void *cbdata) { diff --git a/src/cpu/cpu_map.c b/src/cpu/cpu_map.c index 68d287a..4706f67 100644 --- a/src/cpu/cpu_map.c +++ b/src/cpu/cpu_map.c @@ -42,7 +42,7 @@ VIR_ENUM_IMPL(cpuMapElement, CPU_MAP_ELEMENT_LAST, static int load(xmlXPathContextPtr ctxt, - enum cpuMapElement element, + cpuMapElement element, cpuMapLoadCallback callback, void *data) { diff --git a/src/cpu/cpu_map.h b/src/cpu/cpu_map.h index 23ce888..fcd6c34 100644 --- a/src/cpu/cpu_map.h +++ b/src/cpu/cpu_map.h @@ -27,19 +27,19 @@ # include "virxml.h" -enum cpuMapElement { +typedef enum { CPU_MAP_ELEMENT_VENDOR, CPU_MAP_ELEMENT_FEATURE, CPU_MAP_ELEMENT_MODEL, CPU_MAP_ELEMENT_LAST -}; +} cpuMapElement; VIR_ENUM_DECL(cpuMapElement) typedef int -(*cpuMapLoadCallback) (enum cpuMapElement element, +(*cpuMapLoadCallback) (cpuMapElement element, xmlXPathContextPtr ctxt, void *data); diff --git a/src/cpu/cpu_powerpc.c b/src/cpu/cpu_powerpc.c index 372272f..05fa55b 100644 --- a/src/cpu/cpu_powerpc.c +++ b/src/cpu/cpu_powerpc.c @@ -273,7 +273,7 @@ ppcModelLoad(xmlXPathContextPtr ctxt, } static int -ppcMapLoadCallback(enum cpuMapElement element, +ppcMapLoadCallback(cpuMapElement element, xmlXPathContextPtr ctxt, void *data) { diff --git a/src/cpu/cpu_x86.c b/src/cpu/cpu_x86.c index 06fbfba..72c5216 100644 --- a/src/cpu/cpu_x86.c +++ b/src/cpu/cpu_x86.c @@ -1098,7 +1098,7 @@ x86MapFree(struct x86_map *map) static int -x86MapLoadCallback(enum cpuMapElement element, +x86MapLoadCallback(cpuMapElement element, xmlXPathContextPtr ctxt, void *data) { -- 1.7.10.4

10 years, 5 months

2
5
0 / 0

[libvirt] [Question] Collect vNode pinning to pNode run-time information

by Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ)

Hi all, I have a question about NUMA. User configured vNode(guest virtual numa node), but he didn't configure cputune and numatune. Now we want to get the information that each vNode run in which pNode(host numa node). It's run-time information that may be modified with high frequency. In current Libvirt's API, we can get the information that each vCpu running on which pCpu through virsh vcpuinfo(there should be a corresponding Libvirt API function). But we didn't find any APIs to get the information that each vNode uses which pNode's memory, or just each vCpu consumes which pNode's memory. We find a command "numastat -mcn -p qemu" that can get the memory consume data of each VM, but it still loses the information that we want(vNode memory consume data), as following: # numastat -mcn -p qemu Per-node process memory usage (in MBs) PID Node 0 Node 1 Total --------------- ------ ------ ----- 8900 (qemu-kvm) 2032 50 2083 17716 (qemu-kvm) 1546 663 2209 22484 (qemu-kvm) 621 1524 2146 29694 (qemu-kvm) 892 1350 2242 --------------- ------ ------ ----- Total 5092 3588 8680 ......... My question is: 1. In Libvirt, are there any ways that we can get our needed data? 2. If no ways in Libvirt, do you have any other suggestions to collect the information? Any feedbacks from you are appreciated. Thanks & Best Regards Shi, Xiao-Lei (Bruce) Hewlett-Packard Co., Ltd. HP Servers Core Platform Software China Telephone +86 23 65683093 Mobile +86 18696583447 Email xiao-lei.shi(a)hp.com<mailto:shiguo.li@hp.com>

10 years, 5 months

2
1
0 / 0

[libvirt] Is there a way to get host uptime in remote libvirt

by coffeeball

We manage hypervisors (VMWare ESXi/vCenter, KVM, XEN, Hyper-V) by remote Libvirt API, in our case we need to get the host uptime via the same libvirt interface. Is there a way get this info now for all the aforementioned hypervisor types? The APIs virConnectGetSysinfo(), virNodeGetInfo() provide host info but it doesn't include the system uptime. The virNodeGetCPUStats() can returns CPU usage in nanosecond, can we add the user + system + idle + iowait to calculate the system uptime? Looks like the sum value has a huge gap with the real uptime value returned by "uptime" CLI. virsh # nodecpustats user: 2985046540000000 system: 1368209710000000 idle: 388018933920000000 iowait: 43371960000000

10 years, 5 months

2
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Devel June 2014