- Devel - libvirt List Archives

[libvirt] VIRTIO v1.0 15-day public review - ends July 2nd
by Chet Ensign 17 Jun '15

17 Jun '15

OASIS members and other interested parties, The Virtual I/O Device (VIRTIO) TC members [1] have produced an updated Committee Specification Draft (CSD) and submitted this specification for 15-day public review: Virtual I/O Device (VIRTIO) Version 1.0 Committee Specification Draft 04 / Public Review Draft 04 28 May 2015 Specification overview: This document describes the specifications of the "virtio" family of devices. These devices are found in virtual environments, yet by design they are not all that different from physical devices, and this document treats them as such. This allows the guest to use standard drivers and discovery mechanisms. The purpose of virtio and this specification is that virtual environments and guests should have a straightforward, efficient, standard and extensible mechanism for virtual devices, rather than boutique per-environment or per-OS mechanisms. Among multiple other enhancements and corrections, the Virtio specification now includes support for the memory balloon device for managing guest memory. This puts Virtio 1.0 at feature parity with Virtio 0.9. This is the first public review of VIRTIO since it was approved as Committee Specification 02 (CS02). The files http://docs.oasis-open.org/virtio/virtio/v1.0/csprd04/virtio-v1.0-csprd04-d… and http://docs.oasis-open.org/virtio/virtio/v1.0/csprd04/virtio-v1.0-csprd04-d… include all changes since CS02 highlighted. TC Description: The goal of the OASIS Virtual I/O Device (VIRTIO) TC is to simplify virtual devices, making them more extensible and more recognizable. The purpose of VIRTIO is to ensure that virtual environments and guests have a straightforward, efficient, standard, and extensible mechanism for virtual devices, rather than boutique per-environment or per-OS mechanisms. Public Review Period: The public review starts 18 June 2015 at 00:00 UTC and ends 02 July 2015 at 23:59 UTC. This is the first public review of VIRTIO since it was approved as Committee Specification 02 (CS02). The files http://docs.oasis-open.org/virtio/virtio/v1.0/csprd04/virtio-v1.0-csprd04-d… and http://docs.oasis-open.org/virtio/virtio/v1.0/csprd04/virtio-v1.0-csprd04-d… include all changes since CS02 highlighted [2]. This 15-day review is limited in scope to these changes. This is an open invitation to comment. OASIS solicits feedback from potential users, developers and others, whether OASIS members or not, for the sake of improving the interoperability and quality of its technical work. Reviewers may provide comments directly from the comment-tag version of document. The file http://docs.oasis-open.org/virtio/virtio/v1.0/csprd04/virtio-v1.0-csprd04-C… contains the HTML version of the draft with a “[comment?]” link next to each section heading. Clicking on this link will launch your email application and begin a message to virtio-comment(a)lists.oasis-open.org with the specific section number and title in the subject line. Simply enter your comment and click send. Note that you must be subscribed to the comment mailing list before sending feedback. Instructions on how to subscribe can be found at https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=virtio. URIs: The prose specification document and related files are available here: Editable source (Authoritative): http://docs.oasis-open.org/virtio/virtio/v1.0/csprd04/tex/ HTML: http://docs.oasis-open.org/virtio/virtio/v1.0/csprd04/virtio-v1.0-csprd04.h… HTML with inline tags for direct commenting: http://docs.oasis-open.org/virtio/virtio/v1.0/csprd04/virtio-v1.0-csprd04-C… PDF: http://docs.oasis-open.org/virtio/virtio/v1.0/csprd04/virtio-v1.0-csprd04.p… ZIP distribution files (complete): For your convenience, OASIS provides a complete package of the prose specification and related files in a ZIP distribution file. You can download the ZIP file here: http://docs.oasis-open.org/virtio/virtio/v1.0/csprd04/virtio-v1.0-csprd04.z… Additional information about this specification and the VIRTIO TC may be found on the TC's public home page located at: http://www.oasis-open.org/committees/virtio/ Comments may be submitted to the TC by any person through the use of the OASIS TC Comment Facility which can be accessed via the button labeled "Send A Comment" at the top of the TC public home page, or directly at: http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=virtio Feedback submitted by TC non-members for this work and for other work of this TC is publicly archived and can be viewed at: http://lists.oasis-open.org/archives/virtio-comment/ All comments submitted to OASIS are subject to the OASIS Feedback License, which ensures that the feedback you provide carries the same obligations at least as the obligations of the TC members. In connection with this public review of 'Virtual I/O Device (VIRTIO) Version 1.0', we call your attention to the OASIS IPR Policy [3] applicable especially [4] to the work of this technical committee. All members of the TC should be familiar with this document, which may create obligations regarding the disclosure and availability of a member's patent, copyright, trademark and license rights that read on an approved OASIS specification. OASIS invites any persons who know of any such claims to disclose these if they may be essential to the implementation of the above specification, so that notice of them may be posted to the notice page for this TC's work. ========== Additional references: [1] Virtual I/O Device (VIRTIO) TC http://www.oasis-open.org/committees/virtio/ [2] Redlined DIFF file: http://docs.oasis-open.org/virtio/virtio/v1.0/csprd04/virtio-v1.0-csprd04-d… [3] http://www.oasis-open.org/policies-guidelines/ipr [4] http://www.oasis-open.org/committees/virtio/ipr.php https://www.oasis-open.org/policies-guidelines/ipr#licensing_req Non-Assertion Mode -- /chet ---------------- Chet Ensign Director of Standards Development and TC Administration OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-996-2298 Mobile: +1 201-341-1393

1 0

[libvirt] [PATCH 0/3] parallels: add statistiscs
by Nikolay Shirokovskiy 17 Jun '15

17 Jun '15

Add vz statistics for network, cpu and memory. src/vz/vz_driver.c | 133 +++++++++++++++++++++++++++++++++++++++++++++++++++- src/vz/vz_sdk.c | 69 ++++++++++++++++++++++++++- src/vz/vz_sdk.h | 4 ++

1 3

[libvirt] PING: [PATCH v2 0/2] Allow PCI virtio on ARM "virt" machine
by Pavel Fedin 17 Jun '15

17 Jun '15

Hello ? Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia > -----Original Message----- > From: libvir-list-bounces(a)redhat.com [mailto:libvir-list-bounces@redhat.com] On Behalf Of > Pavel Fedin > Sent: Thursday, June 11, 2015 9:41 AM > To: libvir-list(a)redhat.com > Cc: Pavel Fedin > Subject: [libvirt] [PATCH v2 0/2] Allow PCI virtio on ARM "virt" machine > > Virt machine in qemu since v2.3.0 has PCI generic host controller, and can use > PCI devices. This provides performance improvement as well as vhost-net with > irqfd support for virtio-net. However libvirt still insists on virtio devices > attached to virt machine to have MMIO bindings. This patch allows to use both. > If the user doesn't specify <address type='virtio-mmio'>, PCI will be used by > default. > > Changes since v1: > - Added capability based on qemu version number > - Recognize also "virt-" prefix > > Pavel Fedin (2): > Introduce QEMU_CAPS_ARM_VIRT_PCI > Allow PCI virtio on ARM "virt" machine > > src/qemu/qemu_capabilities.c | 5 +++++ > src/qemu/qemu_capabilities.h | 1 + > src/qemu/qemu_command.c | 15 ++++++++++++--- > 3 files changed, 18 insertions(+), 3 deletions(-) > > -- > 1.9.5.msysgit.0 > > -- > libvir-list mailing list > libvir-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/libvir-list

2 1

[libvirt] [PATCH 0/3] Fix yet again some Admin API bugs
by Michal Privoznik 17 Jun '15

17 Jun '15

Pushed under trivial and build-breaker rules. The 'make rpm' is broken. There is still one issue I'm chasing down. Running 'distcheck' shows some errors. Michal Privoznik (3): daemon: Distribute admin_server.h tests: Follow virnetserver to virnetdaemon transition libvirt.spec: Don't expect virt-admin in libvirt-admin yet daemon/Makefile.am | 2 +- libvirt.spec.in | 2 -- tests/Makefile.am | 2 +- 3 files changed, 2 insertions(+), 4 deletions(-) -- 2.3.6

1 3

[libvirt] PING: [PATCH v2 0/2] Allow PCI virtio on ARM "virt" machine
by Pavel Fedin 17 Jun '15

17 Jun '15

Knock-knock??? Sorry for possibly repeated PING, but i see that mailing list for some reason strips CC:'s if specified without real name, so retry with name this time. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia > -----Original Message----- > From: libvir-list-bounces(a)redhat.com [mailto:libvir-list-bounces@redhat.com] On Behalf Of > Pavel Fedin > Sent: Thursday, June 11, 2015 9:41 AM > To: libvir-list(a)redhat.com > Cc: Pavel Fedin > Subject: [libvirt] [PATCH v2 0/2] Allow PCI virtio on ARM "virt" machine > > Virt machine in qemu since v2.3.0 has PCI generic host controller, and can use > PCI devices. This provides performance improvement as well as vhost-net with > irqfd support for virtio-net. However libvirt still insists on virtio devices > attached to virt machine to have MMIO bindings. This patch allows to use both. > If the user doesn't specify <address type='virtio-mmio'>, PCI will be used by > default. > > Changes since v1: > - Added capability based on qemu version number > - Recognize also "virt-" prefix > > Pavel Fedin (2): > Introduce QEMU_CAPS_ARM_VIRT_PCI > Allow PCI virtio on ARM "virt" machine > > src/qemu/qemu_capabilities.c | 5 +++++ > src/qemu/qemu_capabilities.h | 1 + > src/qemu/qemu_command.c | 15 ++++++++++++--- > 3 files changed, 18 insertions(+), 3 deletions(-) > > -- > 1.9.5.msysgit.0 > > -- > libvir-list mailing list > libvir-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/libvir-list

1 0

[libvirt] [sandbox PATCH 0/3] Disk support for libvirt-sandbox
by Eren Yagdiran 17 Jun '15

17 Jun '15

Hello, These patches provide disk support for libvirt-sandbox. Implemented '--disk' parameter will be useful when integrating Docker image support for libvirt-sandbox. Currently, we only support qcow2 file format and fallback is set to RAW type. Eren Yagdiran (3): Add an utility function for guessing filetype from file extension Add configuration object for disk support Add disk parameter to virt-sandbox bin/virt-sandbox.c | 37 +++ libvirt-sandbox/Makefile.am | 3 + .../libvirt-sandbox-builder-container.c | 36 ++- libvirt-sandbox/libvirt-sandbox-builder-machine.c | 31 ++- libvirt-sandbox/libvirt-sandbox-config-disk.c | 300 +++++++++++++++++++++ libvirt-sandbox/libvirt-sandbox-config-disk.h | 86 ++++++ libvirt-sandbox/libvirt-sandbox-config.c | 275 +++++++++++++++++++ libvirt-sandbox/libvirt-sandbox-config.h | 10 + libvirt-sandbox/libvirt-sandbox-util.c | 79 ++++++ libvirt-sandbox/libvirt-sandbox-util.h | 6 + libvirt-sandbox/libvirt-sandbox.h | 1 + libvirt-sandbox/libvirt-sandbox.sym | 8 + libvirt-sandbox/tests/test-config.c | 11 + 13 files changed, 881 insertions(+), 2 deletions(-) create mode 100644 libvirt-sandbox/libvirt-sandbox-config-disk.c create mode 100644 libvirt-sandbox/libvirt-sandbox-config-disk.h create mode 100644 libvirt-sandbox/libvirt-sandbox-util.c -- 2.1.0

3 11

[libvirt] [libvirt-glib] gconfig: Fix small leak in test-domain-create
by Christophe Fergeau 17 Jun '15

17 Jun '15

The object returned by gvir_config_domain_disk_get_driver() must be unref'ed when no longer used. --- libvirt-gconfig/tests/test-domain-create.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libvirt-gconfig/tests/test-domain-create.c b/libvirt-gconfig/tests/test-domain-create.c index eb4b945..417d3d0 100644 --- a/libvirt-gconfig/tests/test-domain-create.c +++ b/libvirt-gconfig/tests/test-domain-create.c @@ -284,6 +284,7 @@ int main(int argc, char **argv) g_assert(gvir_config_domain_disk_driver_get_copy_on_read(driver)); g_assert(gvir_config_domain_disk_get_target_bus(disk) == GVIR_CONFIG_DOMAIN_DISK_BUS_IDE); g_str_const_check(gvir_config_domain_disk_get_target_dev(disk), "hda"); + g_object_unref(driver); /* network interfaces node */ -- 2.3.5

2 2

[libvirt] [sandbox] configure: check for static libc
by Cédric Bosdonnat 17 Jun '15

17 Jun '15

Missing static libc doesn't really prevent the build to finish, but it would cause errors when running qemu sandboxes. Checking in configure will save time for new developers. --- configure.ac | 2 ++ m4/virt-static.m4 | 33 +++++++++++++++++++++++++++++++++ 2 files changed, 35 insertions(+) create mode 100644 m4/virt-static.m4 diff --git a/configure.ac b/configure.ac index 0e49a0a..ba5247a 100644 --- a/configure.ac +++ b/configure.ac @@ -87,6 +87,8 @@ LIBVIRT_SANDBOX_COVERAGE LIBVIRT_SANDBOX_RPCGEN LIBVIRT_SANDBOX_SELINUX +LIBVIRT_SANDBOX_STATIC_LIBC + GOBJECT_INTROSPECTION_CHECK([$GOBJECT_INTROSPECTION_REQUIRED]) dnl Should be in m4/virt-gettext.m4 but intltoolize is too diff --git a/m4/virt-static.m4 b/m4/virt-static.m4 new file mode 100644 index 0000000..8a40351 --- /dev/null +++ b/m4/virt-static.m4 @@ -0,0 +1,33 @@ +# LIBVIRT_SANDBOX_STATIC_LIB(NAME, CFLAGS, LDFLAGS, PROLOG, PROGRAM) +# ------------------------------------------------------------------ +# Check if the program can be linked with static libraries only. +# +AC_DEFUN([LIBVIRT_SANDBOX_STATIC_LIB], [ + AC_MSG_CHECKING([for static $1]) + + SAVED_LDFLAGS=$LDFLAGS + SAVED_CFLAGS=$CFLAGS + CFLAGS="$2" + LDFLAGS="-static $3" + AC_LINK_IFELSE( + [AC_LANG_PROGRAM([$4], + [$5])], + [], + [AC_MSG_RESULT([no])] + [AC_MSG_ERROR([static $1 is required in order to build virt-sandbox-init-qemu])] + ) + LDFLAGS=$SAVED_LDFLAGS + CFLAGS=$SAVED_CFLAGS + + AC_MSG_RESULT([yes]) +]) + +AC_DEFUN([LIBVIRT_SANDBOX_STATIC_LIBC], [ + LIBVIRT_SANDBOX_STATIC_LIB( + [LIBC], + [], + [], + [#include <stdio.h>], + [printf("bar");]) +]) + -- 2.1.4

2 1

[libvirt] [RFC] libvirt hugepage hooks
by Alex Williamson 17 Jun '15

17 Jun '15

Hi, This is very rough and early, but I wanted to get some feedback, possibly advice, and see if there's some interest in at least creating infrastructure for user contributed libvirt hooks, if not some default ones that are no-ops unless configured. The impetus for this is that I started trying to tune a dual-socket system for performance with device assignment and quickly became very frustrated that distros don't provide any built-in support for more than the very basics of hugepages. Yes, there are kernel commandline options, but those don't allow node specific configuration. Yes, there's 'virsh allocpages', but how does that get incorporated automatically into initializing libvirtd or a domain? Creating any sort of persistence for hugepages is an exercise for the user. So I think the first step in this is that the hooks scripts[1] should by default support sub-scripts in the common way, with a ".d" sub-directory holding those scripts, for example daemon.d and qemu.d. In the attached file, I've simply commandeered the default script to call the sub-scripts. For compatibility (ie. not overwriting user scripts), that should probably happen within libvirt. In any case, a single monolithic hook file is impossible to maintain on a system, let alone multiple systems, so this needs to be brought up to date. The second step is that even if we drop user contrib hooks out in /usr/share for admins to pull in as desired, perhaps we can provide some consistency for how to configure those hooks. In the example below I propose /etc/sysconfig/libvirt-hook-config.xml. You can see how currently it supports static and dynamic hugepage hooks, static occurring through the daemon hook and dynamic through the qemu hook. Ideally the dynamic hook would simply list the domain names participating in dynamic hugepages and figure out what needs to be allocated where from the domain xml. I haven't gotten that far (and frankly trying to satisfy cpu/numa vs numatune/memory|memnode vs memoryBacking/hugepages and memory size still looks very confusing to me). Do we want a common place to configure this sort of thing? Is XML the right format? On to the scripts themselves. I got some advice on #virt that I should use 'virsh allocpages' to manage hugepages. Despite the warning not to call into libvirt in the hook documentation[1], I was assured it'd be ok here. However, somehow 'virsh freepages' did manage to hang and my RHEL7.1 system doesn't support allocpages yet, so my prototype uses raw sysfs. AFAICT, any sort of hugepage manipulation is inherently broken because of the racy kernel interfaces. We really need a hugepage broker, but that's well beyond the scope of libvirt. Functionally this seems to work well for me. I don't know how practical it is to support dynamic 1G pages; I'd probably encourage static setup for that as my system only survived a couple rounds before getting too fragmented. 2M dynamic seems to work quite nicely though. TL;DR, I thought I'd post this, even in a rough state to see if there's interest, get nitpicks at my terrible scripting, and make sure I'm not just scratching my own itch. Thanks, Alex [1] https://www.libvirt.org/hooks.html

1 0

[libvirt] [[libvirt-php][PATCH v1] qemu-agent-command] fixes for installation and add another libvirt function
by Vasiliy Tolstov 16 Jun '15

16 Jun '15

* add libvirt_domain_qemu_agent_command * fix install target, because before this all stuff goes to /usr/usr dir Signed-off-by: Vasiliy Tolstov <v.tolstov(a)selfip.ru> --- configure.ac | 3 +++ src/Makefile.am | 19 ++++++++++--------- src/libvirt-php.c | 28 ++++++++++++++++++++++++++++ src/libvirt-php.h | 2 ++ 4 files changed, 43 insertions(+), 9 deletions(-) diff --git a/configure.ac b/configure.ac index 9e9fee0..0afa2e2 100644 --- a/configure.ac +++ b/configure.ac @@ -23,6 +23,9 @@ PKG_PROG_PKG_CONFIG LIBVIRT_REQUIRED=0.6.2 PKG_CHECK_MODULES(LIBVIRT, libvirt >= $LIBVIRT_REQUIRED) +PKG_CHECK_MODULES(QEMU, libvirt-qemu) +AC_SUBST([QEMU_CFLAGS]) +AC_SUBST([QEMU_LIBS]) dnl ========================================================================== dnl required minimum version of libxml2 diff --git a/src/Makefile.am b/src/Makefile.am index cab0456..f270ec2 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -6,10 +6,10 @@ WL=@WL@ SHLIB_FLAGS=@SHLIB_FLAGS@ install-exec-local: - $(MKDIR_P) $(DESTDIR)$(prefix)$(PHPEDIR) - $(MKDIR_P) $(DESTDIR)$(prefix)$(PHPCDIR) - $(INSTALL) -m 644 -D .libs/$(PACKAGE).so $(DESTDIR)$(prefix)$(PHPEDIR)/$(PACKAGE).so - $(INSTALL) -m 755 -d $(DESTDIR)$(prefix)$(PHPCDIR) + $(MKDIR_P) $(DESTDIR)$(PHPEDIR) + $(MKDIR_P) $(DESTDIR)$(PHPCDIR) + $(INSTALL) -m 644 -D .libs/$(PACKAGE).so $(DESTDIR)$(PHPEDIR)/$(PACKAGE).so + $(INSTALL) -m 755 -d $(DESTDIR)$(PHPCDIR) $(ECHO) "extension=$(PACKAGE).so" > libvirt-php.ini $(ECHO) >> libvirt-php.ini $(ECHO) "[libvirt]" >> libvirt-php.ini @@ -19,21 +19,22 @@ install-exec-local: $(ECHO) "libvirt.image_path=/var/lib/libvirt/images" >> libvirt-php.ini $(ECHO) "; Limit maximum number of libvirt connections" >> libvirt-php.ini $(ECHO) "libvirt.max_connections=5" >> libvirt-php.ini - $(INSTALL) -m 644 -D libvirt-php.ini $(DESTDIR)$(prefix)$(PHPCDIR)/$(PACKAGE).ini + $(INSTALL) -m 644 -D libvirt-php.ini $(DESTDIR)$(PHPCDIR)/$(PACKAGE).ini uninstall-local: - $(RM) -f $(DESTDIR)$(prefix)$(PHPCDIR)/$(PACKAGE).ini - $(RM) -f $(DESTDIR)$(prefix)$(PHPEDIR)/$(PACKAGE).so + $(RM) -f $(DESTDIR)$(PHPCDIR)/$(PACKAGE).ini + $(RM) -f $(DESTDIR)$(PHPEDIR)/$(PACKAGE).so AM_CFLAGS = \ $(PHPINC) $(LIBXML_CFLAGS) \ - $(LIBVIRT_CFLAGS) $(DEFINES) \ + $(LIBVIRT_CFLAGS) $(QEMU_CFLAGS) $(DEFINES) \ -I$(top_srcdir)/winsrc AM_LDFLAGS = \ $(SHLIB_LDFLAGS) \ $(LIBXML_LIBS) \ - $(LIBVIRT_LIBS) + $(LIBVIRT_LIBS) \ + $(QEMU_LIBS) lib_LTLIBRARIES = libvirt-php.la diff --git a/src/libvirt-php.c b/src/libvirt-php.c index d46fbb9..161abca 100644 --- a/src/libvirt-php.c +++ b/src/libvirt-php.c @@ -161,6 +161,7 @@ static zend_function_entry libvirt_functions[] = { PHP_FE(libvirt_domain_send_keys, NULL) PHP_FE(libvirt_domain_send_pointer_event, NULL) PHP_FE(libvirt_domain_update_device, NULL) + PHP_FE(libvirt_domain_qemu_agent_command, NULL) /* Domain snapshot functions */ PHP_FE(libvirt_domain_has_current_snapshot, NULL) PHP_FE(libvirt_domain_snapshot_create, NULL) @@ -3943,6 +3944,33 @@ PHP_FUNCTION(libvirt_domain_get_name) } /* + Function name: libvirt_domain_qemu_agent_command + Since version: 0.5.2(-1) + Description: Function is used to send qemu-ga command + Arguments: @res [resource]: libvirt domain resource, e.g. from libvirt_domain_lookup_by_*() + @timeout [int]: timeout for waiting (-2 block, -1 default, 0 no wait, >0 wait specific time + @flags [int]: ?? + Returns: String on success and FALSE on error +*/ +PHP_FUNCTION(libvirt_domain_qemu_agent_command) +{ + php_libvirt_domain *domain=NULL; + zval *zdomain; + const char *cmd; + int cmd_len; + char *ret; + long timeout = -1; + long flags = 0; + + GET_DOMAIN_FROM_ARGS("rs|l|l", &zdomain, &cmd, &cmd_len, &timeout, &flags); + + ret = virDomainQemuAgentCommand(domain->domain, cmd, timeout, flags); + if (ret == NULL) RETURN_FALSE; + + RETURN_STRING(ret,0); +} + +/* Function name: libvirt_domain_get_uuid_string Since version: 0.4.1(-1) Description: Function is used to get the domain's UUID in string format diff --git a/src/libvirt-php.h b/src/libvirt-php.h index 7c9a229..1d9c6ab 100644 --- a/src/libvirt-php.h +++ b/src/libvirt-php.h @@ -80,6 +80,7 @@ #include <libvirt/libvirt.h> #include <libvirt/virterror.h> +#include <libvirt/libvirt-qemu.h> #include <libxml/parser.h> #include <libxml/xpath.h> #include <fcntl.h> @@ -427,6 +428,7 @@ PHP_FUNCTION(libvirt_domain_send_keys); PHP_FUNCTION(libvirt_domain_send_pointer_event); PHP_FUNCTION(libvirt_domain_get_metadata); PHP_FUNCTION(libvirt_domain_set_metadata); +PHP_FUNCTION(libvirt_domain_qemu_agent_command); /* Domain snapshot functions */ PHP_FUNCTION(libvirt_domain_has_current_snapshot); PHP_FUNCTION(libvirt_domain_snapshot_create); -- 2.3.3

1 0