- Devel - libvirt List Archives

[libvirt] Host OS, Storage Info
by Sijo Jose 30 May '14

30 May '14

Hi, Is there any way to get host OS information and host Storage in formations using libvirt API...? Rgds -Sijo

3 6

[libvirt] [libvirt-glib] [PATCH] GVirDomainSnapshot: add gvir_domain_snapshot_delete
by Timm Bäder 30 May '14

30 May '14

--- libvirt-gobject/libvirt-gobject-domain-snapshot.c | 21 +++++++++++++++++++++ libvirt-gobject/libvirt-gobject-domain-snapshot.h | 3 +++ libvirt-gobject/libvirt-gobject.sym | 5 +++++ 3 files changed, 29 insertions(+) diff --git a/libvirt-gobject/libvirt-gobject-domain-snapshot.c b/libvirt-gobject/libvirt-gobject-domain-snapshot.c index ab23342..f46c99b 100644 --- a/libvirt-gobject/libvirt-gobject-domain-snapshot.c +++ b/libvirt-gobject/libvirt-gobject-domain-snapshot.c @@ -206,3 +206,24 @@ GVirConfigDomainSnapshot *gvir_domain_snapshot_get_config free(xml); return conf; } + +/** + * gvir_domain_snapshot_delete: + * @snapshot: the domain_snapshot + * @error: (allow-none): Place-holder for error or NULL + */ +void gvir_domain_snapshot_delete(GVirDomainSnapshot *snapshot, 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, 0); + if (status < 0) { + gvir_set_error_literal(error, GVIR_DOMAIN_SNAPSHOT_ERROR, 0, + "Unable to delete snapshot"); + } +} diff --git a/libvirt-gobject/libvirt-gobject-domain-snapshot.h b/libvirt-gobject/libvirt-gobject-domain-snapshot.h index 5bd827c..575f56f 100644 --- a/libvirt-gobject/libvirt-gobject-domain-snapshot.h +++ b/libvirt-gobject/libvirt-gobject-domain-snapshot.h @@ -69,6 +69,9 @@ GVirConfigDomainSnapshot *gvir_domain_snapshot_get_config guint flags, GError **err); +void gvir_domain_snapshot_delete (GVirDomainSnapshot *snapshot, 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..5d12a6a 100644 --- a/libvirt-gobject/libvirt-gobject.sym +++ b/libvirt-gobject/libvirt-gobject.sym @@ -234,4 +234,9 @@ LIBVIRT_GOBJECT_0.1.5 { gvir_connection_open_read_only_finish; } LIBVIRT_GOBJECT_0.1.4; +LIBVIRT_GOBJECT_0.1.9 { + global: + gvir_domain_shapshot_delete; +} LIBVIRT_GOBJECT_0.1.5; + # .... define new API here using predicted next version number .... -- 1.9.3

2 1

[libvirt] GSoC student introduction and work plan
by Taowei Luo 30 May '14

30 May '14

Hi, everyone, My name is Taowei Luo. I'm one of the students working for GSoC this summer. My project is rewriting the vbox driver. Before coding, I really need some discussions about how to implement it. Here I post my first version of plan. I had show as much details as I thought about in this plan. If anyone have ideas or suggestions about my work, I would like to hear. My nick name in #virt IRC channel is uaedante (or dante I used before). If I am offline in IRC, please contract me with my email address uaedante(a)gmail.com. Regards, Taowei. Plan to rewrite vbox driver Introduction: The existing vbox driver codes use vbox API directly. But the vbox API is incompatible between different versions. To support all vbox API versions, the vbox_tmpl.c file provides a template to implement all vbox drivers. Each specified version of vbox driver includes the vbox_tmpl.c file, with the definition in the corresponding head file, they work well. As the vbox API defined in head files is conflict between different versions, even some behavior of vbox APIs are changed. The vbox_tmpl.c contains lots of codes such as “#if VBOX_API_VERSION < 4001000”. These codes is hard to manage or adding new features. Plan: The core idea of my rewriting work is to add a middle layer to uniform the API changes. This modification will not change any functions’ behavior or sematic. The middle layer has a global structure which contains API changes. Like this: struct vboxUniformedAPI { A (*funcA)(A1 a, ….); B (*funcB)(B1 a, ….); } If there is a code segment: #if VBOX_API_VERSION < 4001000 adapter->vtbl->GetHostInterface(adapter, &hostIntUtf16); #else /* VBOX_API_VERSION >= 4001000 */ adapter->vtbl->GetBridgedInterface(adapter, &hostIntUtf16); #endif /* VBOX_API_VERSION >= 4001000 */ This will result to a variable in vboxUniformedAPI structure: RetType (*GetInterface)(INetworkAdapter *a, PRUnichar *b) When using the vbox under 4.1, this variable will points to a function that calls GetHostInterface. When using the vbox later than 4.1 and the variable will points to a function which calls GetBridgedInterface. When replace these code segments with a single function, we need to do living variable analyze and find out what is used and what is changed in these codes. I plan to do these analyze manually. All conflict in function prototype or function implementation will be fixed up though this method. When meeting a conflict in variable type, like: #if VBOX_API_VERSION < 4001000 TypeA var; #else /* VBOX_API_VERSION >= 4001000 */ TypeB var; #endif /* VBOX_API_VERSION >= 4001000 */ I will add a union like this: Union TypeC{ TypeA a;// used in some versions TypeB b;// used in some other versions } If there is any operation using variables with such a union type (or functions use it as an argument or return value), I will add a new function in vboxUniformedAPI to handle this operation. These functions use TypeC as parameter type, dispatch it depends on the vbox version and return TypeC value to conceal type conflict. We still have another kind of conflict. There are some versions have more variables, operations or function calls than other versions. I will reserve all variables even though they may not be used in some situation. And put an empty function if they have nothing to do in the specified function step. (I have a backup solution here. That is adding some flags to indicate whether the procession is necessary in the API version and prevent upper layer from calling a nonexistent function.) Expected result: After rewriting with the rules above, we will have a new vbox_tmpl.c. It gathers version specified code and common code respectively. The common codes use stable vbox API or functions in vboxUniformedAPI. A function named InstallvboxUnifromedAPI will fill the vboxUniformedAPI structure depends on the current vbox API version. In final step, I will put all vbox APIs into the vboxUniformedAPI and make the vbox driver codes use my API only. If this is done, the vbox driver will not be complied for each version anymore. Implementation: First, define the vboxUniformedAPI structure in vbox_tmpl.c, and write the InstallvboxUnifromedAPI function for every vbox API version. Next, rewrite the functions which have conflict codes one by one. Each time rewrite a new function, we can do some tests (here, I am not sure what kind of tests is enough). When rewriting one function in vbox_tmpl.c, the others will not change. At this point, there will split version specified codes and common codes But we still need to build the whole vbox_tmpl.c for each vbox API version. If we want a single object file be generated by vbox_tmpl.c, we need to prevent vbox_tmpl.c from calling vbox API directly. This could be done by putting all of the vbox API calls into the middle vboxUniformedAPI layer, and moving common codes into vbox_common.c. The vbox_common.c should only use APIs in vboxUniformedAPI and will be complied only once.

2 2

[libvirt] Entering freeze for libvirt-1.2.5
by Daniel Veillard 30 May '14

30 May '14

As planned I just tagged candidate release 1 in git and pushed the tarball, and signed rpms to the usual place: ftp://libvirt.org/libvirt/ I gave it a bit of testing, seems to work fine for me, I will probably provide an rc2 on Wed and aim for a release next week-end. In the meantime, please give it a try and report issues you may find ! thanks, Daniel -- Daniel Veillard | Open Source and Standards, Red Hat veillard(a)redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/

1 1

[libvirt] libvirt: Xen Driver error : Domain not found: xenGetDomainDefForName
by deepanshus 29 May '14

29 May '14

Hi, I have successfully installed xen 3.11 kernel but when I am running the vm I am getting this error: libvirt: Xen Driver error : Domain not found: xenGetDomainDefForName I am sending the xend log file as well error file as an attachment. Thanks And Regards, Deepanshu Saxena ------------------------------------------------------------------------------------------------------------------------------- [ C-DAC is on Social-Media too. Kindly follow us at: Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] This e-mail is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies and the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email is strictly prohibited and appropriate legal action will be taken. -------------------------------------------------------------------------------------------------------------------------------

3 2

[libvirt] Weekly meeting minutes May 22nd, 2014
by Daniel P. Berrange 29 May '14

29 May '14

Agenda + minutes from 22/05/2014 * Welcome / rollcall * IRC comments from: * eblake * danpb * pkrempa * derRichard * rbogorodskiy * mkletzan * nehaljwani * mprivozn * Next release schedule * Freeze: Mon May 26th * Release: Mon June 2nd * Patches needing review * pkrempa's gluster patches * 1-27 are nice to have but not release critical * 28+ need to wait for QEMU work * eblake's live commit work * minimum need patch to avoid hang with qemu 2.0 * remaining patches should rebase on top of pkrempa, even if it misses release * vbox snapshot patches - been waiting a long time * Jim Fehlig has libxl migration patches - probably desired for the release * Roman has bhyve pci allocation patches * Refactoring of PCI stuff already merged, just bhyve specific bits left * Nehal has lease helper patch pending * eblake to update to latest gnulib pre-freeze, unless the gnulib change from STREQ macro to inline function streq() requires lots of fallout * Michael has "Keep original file label" left over from March, not release critical though * Richard W suggests to add support for capabilties for LXC * Allows apps to be started with less caps (ie drop CAP_NET_ADMIN to prevent IP changes) * Could also allow uid/gid to be set Thanks to all for attending this first meeting. Set to repeat again on May 29th @ 1400 UTC in #virt-meeting on irc.oftc.net 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 :|

2 1

[libvirt] [PATCH 0/2] qemu: Fix few snapshot issues
by Peter Krempa 29 May '14

29 May '14

Peter Krempa (2): qemu: snapshot: Reject internal active snapshot without memory state qemu: snapshot: Improve detection of mixed snapshots src/qemu/qemu_driver.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) -- 1.9.3

2 6

[libvirt] [PATCH] util: storage: Fix crash of libvirtd on network backed guest block-pull
by Peter Krempa 29 May '14

29 May '14

For guests backed by gluster volumes (or other network storage) we don't fill the backing chain (see qemuDomainDetermineDiskChain). This leaves the "relPath" field of the top image NULL. This causes a crash in virStorageFileChainLookup() when looking up a backing element for such a disk. Since I'm working on adding support for network storage and one of the steps will make the "relPath" field optional let's use STREQ_NULLABLE instead of STREQ in virStorageFileChainLookup() to avoid the problem. --- src/util/virstoragefile.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/util/virstoragefile.c b/src/util/virstoragefile.c index 2feda67..c9b6187 100644 --- a/src/util/virstoragefile.c +++ b/src/util/virstoragefile.c @@ -1591,7 +1591,7 @@ virStorageFileChainLookup(virStorageSourcePtr chain, if (idx == i) break; } else { - if (STREQ(name, chain->relPath)) + if (STREQ_NULLABLE(name, chain->relPath)) break; if (nameIsFile && (chain->type == VIR_STORAGE_TYPE_FILE || chain->type == VIR_STORAGE_TYPE_BLOCK)) { -- 1.9.3

2 2

[libvirt] [PATCH V2] virsh: forbid negative vcpu argument to vcpupin.
by Jincheng Miao 29 May '14

29 May '14

vcpupin will allow argument --vcpu as a signed number, and pass it to virDomainPinVcpu directlly without checking if this value is positive(valid). > virsh vcpupin r7 -1 0 error: numerical overflow: input too large: 4294967295 This message is inaccurate, and the negative vcpu is non-valuable. So forbid vcpu argument as a negative. After patching, the result likes: > virsh vcpupin r6 -1 error: vcpupin: Invalid vCPU number. > virsh vcpupin r6 --cpulist 0-1 error: vcpupin: Missing vCPU number in pin mode. > virsh vcpupin r6 --vcpu ABC error: vcpupin: Invalid vCPU number in query mode. Signed-off-by: Jincheng Miao <jmiao(a)redhat.com> --- tools/virsh-domain.c | 42 ++++++++++++++++++++++++------------------ 1 files changed, 24 insertions(+), 18 deletions(-) diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c index 84a6706..e302459 100644 --- a/tools/virsh-domain.c +++ b/tools/virsh-domain.c @@ -5797,7 +5797,7 @@ cmdVcpuPin(vshControl *ctl, const vshCmd *cmd) { virDomainInfo info; virDomainPtr dom; - int vcpu = -1; + unsigned int vcpu; const char *cpulist = NULL; bool ret = false; unsigned char *cpumap = NULL; @@ -5809,6 +5809,7 @@ cmdVcpuPin(vshControl *ctl, const vshCmd *cmd) bool live = vshCommandOptBool(cmd, "live"); bool current = vshCommandOptBool(cmd, "current"); bool query = false; /* Query mode if no cpulist */ + int get_vcpu; unsigned int flags = VIR_DOMAIN_AFFECT_CURRENT; VSH_EXCLUSIVE_OPTIONS_VAR(current, live); @@ -5830,29 +5831,34 @@ cmdVcpuPin(vshControl *ctl, const vshCmd *cmd) query = !cpulist; - /* In query mode, "vcpu" is optional */ - if (vshCommandOptInt(cmd, "vcpu", &vcpu) < !query) { - vshError(ctl, "%s", - _("vcpupin: Invalid or missing vCPU number.")); - virDomainFree(dom); - return false; - } - - if ((maxcpu = vshNodeGetCPUCount(ctl->conn)) < 0) { - virDomainFree(dom); - return false; + get_vcpu = vshCommandOptUInt(cmd, "vcpu", &vcpu); + if (get_vcpu <= 0) { + /* In query mode, "vcpu" is optional */ + if (query && get_vcpu < 0) { + vshError(ctl, "%s", + _("vcpupin: Invalid vCPU number in query mode.")); + goto cleanup; + } + /* In pin mode, "vcpu" is necessary */ + if (!query) { + vshError(ctl, "%s", + _("vcpupin: Missing vCPU number in pin mode.")); + goto cleanup; + } } if (virDomainGetInfo(dom, &info) != 0) { vshError(ctl, "%s", _("vcpupin: failed to get domain information.")); - virDomainFree(dom); - return false; + goto cleanup; } if (vcpu >= info.nrVirtCpu) { vshError(ctl, "%s", _("vcpupin: Invalid vCPU number.")); - virDomainFree(dom); - return false; + goto cleanup; + } + + if ((maxcpu = vshNodeGetCPUCount(ctl->conn)) < 0) { + goto cleanup; } cpumaplen = VIR_CPU_MAPLEN(maxcpu); @@ -5871,7 +5877,7 @@ cmdVcpuPin(vshControl *ctl, const vshCmd *cmd) vshPrintExtra(ctl, "%s %s\n", _("VCPU:"), _("CPU Affinity")); vshPrintExtra(ctl, "----------------------------------\n"); for (i = 0; i < ncpus; i++) { - if (vcpu != -1 && i != vcpu) + if (get_vcpu > 0 && i != vcpu) continue; vshPrint(ctl, "%4zu: ", i); @@ -5880,8 +5886,8 @@ cmdVcpuPin(vshControl *ctl, const vshCmd *cmd) if (!ret) break; } - } + VIR_FREE(cpumaps); goto cleanup; } -- 1.7.1

3 3

[libvirt] [PATCHv2] util: fix virTimeLocalOffsetFromUTC DST processing
by Laine Stump 29 May '14

29 May '14

The original version of virTimeLocalOffsetFromUTC() would fail for certain times of the day if daylight savings time was active. This could most easily be seen by uncommenting the TEST_LOCALOFFSET() cases that include a DST setting. After a lot of experimenting, I found that the way to solve it in almost all test cases is to set tm_isdst = -1 in the stuct tm prior to calling mktime(). Once this is done, the correct offset is returned for all test cases at all times except the two hours just after 00:00:00 Jan 1 UTC - during that time, any timezone that is *behind* UTC, and that is supposed to always be in DST will not have DST accounted for in its offset. I believe that the code of virTimeLocalOffsetFromUTC() is actually correct for all cases, but the problem still encountered is due to our inability to come up with a TZ string that properly forces DST to *always* be active. Since a modfication of the (currently fixed) expected result data to account for this would necessarily use the same functions that we're trying to test, I've instead just made the test program conditionally bypass the problematic cases if the current date is either December 31 or January 1. This way we get maximum testing during 363 days of the year, but don't get false failures on Dec 31 and Jan 1. --- Change from V1: correct typo in commit message pointed out by Eric, and also followed his suggestion to enable the sometimes-failing tests unless the current localtime is Jan 1 or Dec 31. src/util/virtime.c | 3 +++ tests/virtimetest.c | 61 ++++++++++++++++++++++++++++++++++++++++++++++------- 2 files changed, 56 insertions(+), 8 deletions(-) diff --git a/src/util/virtime.c b/src/util/virtime.c index 3a56400..c69dff1 100644 --- a/src/util/virtime.c +++ b/src/util/virtime.c @@ -377,6 +377,9 @@ virTimeLocalOffsetFromUTC(long *offset) return -1; } + /* tell mktime to figure out itself whether or not DST is in effect */ + gmtimeinfo.tm_isdst = -1; + /* mktime() also obeys current timezone rules */ if ((utc = mktime(&gmtimeinfo)) == (time_t)-1) { virReportSystemError(errno, "%s", diff --git a/tests/virtimetest.c b/tests/virtimetest.c index bf27682..f378076 100644 --- a/tests/virtimetest.c +++ b/tests/virtimetest.c @@ -101,6 +101,28 @@ testTimeLocalOffset(const void *args) return 0; } + +/* return true if the date is Jan 1 or Dec 31 (localtime) */ +static bool +IsJan1OrDec31(void) +{ + time_t current = time(NULL); + struct tm timeinfo; + + if (current == (time_t)-1) { + VIR_DEBUG("time() failed"); + return false; + } + if (!localtime_r(&current, &timeinfo)) { + VIR_DEBUG("localtime_r() failed"); + return false; + } + + return (timeinfo.tm_mon == 0 && timeinfo.tm_mday == 1) || + (timeinfo.tm_mon == 11 && timeinfo.tm_mday == 31); +} + + static int mymain(void) { @@ -161,21 +183,44 @@ mymain(void) TEST_LOCALOFFSET("VIR00:30", -30 * 60); TEST_LOCALOFFSET("VIR01:30", -90 * 60); + TEST_LOCALOFFSET("VIR05:00", (-5 * 60) * 60); TEST_LOCALOFFSET("UTC", 0); TEST_LOCALOFFSET("VIR-00:30", 30 * 60); TEST_LOCALOFFSET("VIR-01:30", 90 * 60); -#if __TEST_DST + /* test DST processing with timezones that always * have DST in effect; what's more, cover a zone with * with an unusual DST different than a usual one hour */ - /* NB: These tests fail at certain times of the day, so - * must be disabled until we figure out why - */ - TEST_LOCALOFFSET("VIR-00:30VID,0,365", 90 * 60); - TEST_LOCALOFFSET("VIR-02:30VID,0,365", 210 * 60); - TEST_LOCALOFFSET("VIR-02:30VID-04:30,0,365", 270 * 60); -#endif + TEST_LOCALOFFSET("VIR-00:30VID,0/00:00:00,366/23:59:59", + ((1 * 60) + 30) * 60); + TEST_LOCALOFFSET("VIR-02:30VID,0/00:00:00,366/23:59:59", + ((3 * 60) + 30) * 60); + TEST_LOCALOFFSET("VIR-02:30VID-04:30,0/00:00:00,366/23:59:59", + ((4 * 60) + 30) * 60); + TEST_LOCALOFFSET("VIR-12:00VID-13:00,0/00:00:00,366/23:59:59", + ((13 * 60) + 0) * 60); + + if (!IsJan1OrDec31()) { + /* experiments have shown that the following tests will fail + * during certain hours of Dec 31 or Jan 1 (depending on the + * TZ setting in the shell running the test, but in general + * for a period that apparently starts at 00:00:00 UTC Jan 1 + * and continues for 1 - 2 hours). We've determined this is + * due to our inability to specify a timezone with DST on/off + * settings that make it truly *always* on DST - i.e. it is a + * failing of the test data, *not* of the function we are + * testing. So to test as much as possible, we still run these + * tests, except on Dec 31 and Jan 1. + */ + + TEST_LOCALOFFSET("VIR02:45VID00:45,0/00:00:00,366/23:59:59", + -45 * 60); + TEST_LOCALOFFSET("VIR05:00VID04:00,0/00:00:00,366/23:59:59", + ((-4 * 60) + 0) * 60); + TEST_LOCALOFFSET("VIR11:00VID10:00,0/00:00:00,366/23:59:59", + ((-10 * 60) + 0) * 60); + } return ret == 0 ? EXIT_SUCCESS : EXIT_FAILURE; } -- 1.9.3

2 2