October 2011 - Devel - libvirt List Archives

[libvirt] [PATCH 1/3] Add vapi bindings generation
by Marc-André Lureau 21 Oct '11

21 Oct '11

--- Makefile.am | 2 +- configure.ac | 19 +++++++++++++++++++ vapi/Makefile.am | 37 +++++++++++++++++++++++++++++++++++++ vapi/libvirt-gobject-1.0.deps | 1 + vapi/libvirt-gobject-1.0.metada | 2 ++ 5 files changed, 60 insertions(+), 1 deletions(-) create mode 100644 vapi/Makefile.am create mode 100644 vapi/libvirt-gobject-1.0.deps create mode 100644 vapi/libvirt-gobject-1.0.metada diff --git a/Makefile.am b/Makefile.am index 3df8626..8d082c0 100644 --- a/Makefile.am +++ b/Makefile.am @@ -1,5 +1,5 @@ -SUBDIRS = libvirt-glib libvirt-gconfig libvirt-gobject python examples +SUBDIRS = libvirt-glib libvirt-gconfig libvirt-gobject python vapi examples ACLOCAL_AMFLAGS = -I m4 diff --git a/configure.ac b/configure.ac index 0581874..c474f0b 100644 --- a/configure.ac +++ b/configure.ac @@ -198,12 +198,31 @@ if test "x$enable_introspection" != "xno" ; then fi AM_CONDITIONAL([WITH_GOBJECT_INTROSPECTION], [test "x$enable_introspection" = "xyes"]) +AC_ARG_ENABLE([vala], + AS_HELP_STRING([--enable-vala], [enable Vala binding generation]), + [], [enable_vala=check]) +if test "x$enable_introspection" = "xyes" ; then + if test "x$enable_vala" != "xno" ; then + AC_PATH_PROG(VAPIGEN, vapigen, no) + if test "x$VAPIGEN" != "xno"; then + if test "x$enable_vala" == "xcheck" ; then + enable_vala=yes + AC_SUBST(VAPIGEN) + fi + else + AC_MSG_ERROR([Cannot find the "vapigen" binary in your PATH]) + fi + fi +fi +AM_CONDITIONAL([WITH_VALA], [test "x$enable_vala" = "xyes"]) + AC_OUTPUT(Makefile libvirt-glib/Makefile libvirt-gconfig/Makefile libvirt-gobject/Makefile examples/Makefile python/Makefile + vapi/Makefile libvirt-glib-1.0.pc libvirt-gconfig-1.0.pc libvirt-gobject-1.0.pc diff --git a/vapi/Makefile.am b/vapi/Makefile.am new file mode 100644 index 0000000..f844576 --- /dev/null +++ b/vapi/Makefile.am @@ -0,0 +1,37 @@ +NULL = + +if WITH_VALA +vapidir = $(datadir)/vala/vapi +vapi_DATA = \ + libvirt-gconfig-1.0.vapi \ + libvirt-glib-1.0.vapi \ + libvirt-gobject-1.0.vapi \ + $(NULL) + +libvirt-glib-1.0.vapi: $(top_builddir)/libvirt-glib/LibvirtGLib-1.0.gir + $(AM_V_GEN)$(VAPIGEN) \ + --vapidir=. \ + --pkg gobject-2.0 \ + --pkg gio-2.0 \ + --library libvirt-glib-1.0 \ + $< + +libvirt-gobject-1.0.vapi: $(top_builddir)/libvirt-gobject/LibvirtGObject-1.0.gir + $(AM_V_GEN)$(VAPIGEN) \ + --vapidir=. \ + --pkg gobject-2.0 \ + --pkg gio-2.0 \ + --pkg libvirt-glib-1.0 \ + --library libvirt-gobject-1.0 \ + $< + +libvirt-gconfig-1.0.vapi: $(top_builddir)/libvirt-gconfig/LibvirtGConfig-1.0.gir + $(AM_V_GEN)$(VAPIGEN) \ + --vapidir=. \ + --pkg gobject-2.0 \ + --library libvirt-gconfig-1.0 \ + $< + +endif + +CLEANFILES = $(vapi_DATA) diff --git a/vapi/libvirt-gobject-1.0.deps b/vapi/libvirt-gobject-1.0.deps new file mode 100644 index 0000000..899e8e8 --- /dev/null +++ b/vapi/libvirt-gobject-1.0.deps @@ -0,0 +1 @@ +libvirt-gconfig-1.0 diff --git a/vapi/libvirt-gobject-1.0.metada b/vapi/libvirt-gobject-1.0.metada new file mode 100644 index 0000000..90e5197 --- /dev/null +++ b/vapi/libvirt-gobject-1.0.metada @@ -0,0 +1,2 @@ +init_object.argv unowned +init_object_check.argv unowned -- 1.7.6.2

3 7

[libvirt] passing secrets to block devices
by Josh Durgin 21 Oct '11

21 Oct '11

We're working on libvirt support for block device authentication [1]. To authenticate, rbd needs a username and a secret. Normally, to avoid putting the secret on the command line, you can store the secret in a file and pass the file to qemu, but when this is automated, there's no good way to know when the file can be removed. There are a few ways to pass the secret to qemu that avoid this problem: 1) pass an fd to an unlinked file containing the secret This is the simplest method, but it sounds like qemu developers don't like fd passing from libvirt. [2] 2) start guests paused, without disks requiring authentication, then use the drive_add monitor command to attach them This would make disks with authentication somewhat of a special case in libvirt, but would be simple to implement, and require no qemu changes. 3) start guests paused, then send the secret via a new QMP/HMP command (block_set_conf <key> <value>?) This is a larger change, but it would be more generally useful for changing configuration at runtime. What do you think is the best approach? [1] http://permalink.gmane.org/gmane.comp.file-systems.ceph.devel/4129 [2] http://lists.gnu.org/archive/html/qemu-devel/2011-08/msg02494.html

4 7

[libvirt] [PATCH libvirt-glib] Fix vapigen on uninstalled environment
by Marc-André Lureau 21 Oct '11

21 Oct '11

--- vapi/Makefile.am | 20 +++++++++++--------- 1 files changed, 11 insertions(+), 9 deletions(-) diff --git a/vapi/Makefile.am b/vapi/Makefile.am index 129ce58..1e94a87 100644 --- a/vapi/Makefile.am +++ b/vapi/Makefile.am @@ -11,25 +11,27 @@ vapi_DATA = \ libvirt-glib-1.0.vapi: $(top_builddir)/libvirt-glib/LibvirtGLib-1.0.gir $(AM_V_GEN)$(VAPIGEN) \ - --vapidir=. \ + --vapidir=$(builddir) \ --pkg gobject-2.0 \ --pkg gio-2.0 \ --library libvirt-glib-1.0 \ $< libvirt-gobject-1.0.vapi: $(top_builddir)/libvirt-gobject/LibvirtGObject-1.0.gir - $(AM_V_GEN)$(VAPIGEN) \ - --vapidir=. \ - --pkg gobject-2.0 \ - --pkg gio-2.0 \ - --pkg libvirt-glib-1.0 \ - --library libvirt-gobject-1.0 \ - --metadatadir=$(srcdir) \ + $(AM_V_GEN)$(VAPIGEN) \ + --vapidir=$(builddir) \ + --pkg gobject-2.0 \ + --pkg gio-2.0 \ + --pkg libvirt-glib-1.0 \ + --library libvirt-gobject-1.0 \ + --metadatadir=$(srcdir) \ + --girdir=$(top_builddir)/libvirt-glib \ + --girdir=$(top_builddir)/libvirt-gconfig \ $< libvirt-gconfig-1.0.vapi: $(top_builddir)/libvirt-gconfig/LibvirtGConfig-1.0.gir $(AM_V_GEN)$(VAPIGEN) \ - --vapidir=. \ + --vapidir=$(builddir) \ --pkg gobject-2.0 \ --library libvirt-gconfig-1.0 \ $< -- 1.7.6.2

2 1

[libvirt] [PATCH libvirt-glib] Fix GIR scanner on uninstalled environment
by Marc-André Lureau 21 Oct '11

21 Oct '11

--- libvirt-gobject/Makefile.am | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/libvirt-gobject/Makefile.am b/libvirt-gobject/Makefile.am index 7013675..1c36fb0 100644 --- a/libvirt-gobject/Makefile.am +++ b/libvirt-gobject/Makefile.am @@ -99,7 +99,7 @@ CLEANFILES = $(BUILT_SOURCES) if WITH_GOBJECT_INTROSPECTION LibvirtGObject-1.0.gir: libvirt-gobject-1.0.la $(G_IR_SCANNER) Makefile.am - $(AM_V_GEN)$(G_IR_SCANNER) \ + $(AM_V_GEN)PKG_CONFIG_PATH=$(top_builddir) $(G_IR_SCANNER) \ --quiet \ --warn-all \ --namespace LibvirtGObject \ -- 1.7.6.2

2 1

[libvirt] [libvirt PATCH] support continue/return targets in nwfilter
by David L Stevens 21 Oct '11

21 Oct '11

This patch adds support for "continue" and "return" actions in filter rules. Signed-off-by: David L Stevens <dlstevens(a)us.ibm.com> diff --git a/src/conf/nwfilter_conf.c b/src/conf/nwfilter_conf.c index 04bfa22..3e28806 100644 --- a/src/conf/nwfilter_conf.c +++ b/src/conf/nwfilter_conf.c @@ -55,12 +55,16 @@ VIR_ENUM_IMPL(virNWFilterRuleAction, VIR_NWFILTER_RULE_ACTION_LAST, "drop", "accept", - "reject"); + "reject", + "return", + "continue"); VIR_ENUM_IMPL(virNWFilterJumpTarget, VIR_NWFILTER_RULE_ACTION_LAST, "DROP", "ACCEPT", - "REJECT"); + "REJECT", + "RETURN", + "CONTINUE"); VIR_ENUM_IMPL(virNWFilterRuleDirection, VIR_NWFILTER_RULE_DIRECTION_LAST, "in", diff --git a/src/conf/nwfilter_conf.h b/src/conf/nwfilter_conf.h index 5306403..c96851a 100644 --- a/src/conf/nwfilter_conf.h +++ b/src/conf/nwfilter_conf.h @@ -299,6 +299,8 @@ enum virNWFilterRuleActionType { VIR_NWFILTER_RULE_ACTION_DROP = 0, VIR_NWFILTER_RULE_ACTION_ACCEPT, VIR_NWFILTER_RULE_ACTION_REJECT, + VIR_NWFILTER_RULE_ACTION_RETURN, + VIR_NWFILTER_RULE_ACTION_CONTINUE, VIR_NWFILTER_RULE_ACTION_LAST, };

4 3

Re: [libvirt] [PATCH] qemu: Relax -no-shutdown check to [0.14.0, 0.15.0]
by lvroyce 21 Oct '11

21 Oct '11

tested-by :Royce Lv<lvroyce(a)linux.vnet.ibm.com> patch workes expected,qemu version 0.15.50.reboot domain with ACPI support.

1 0

[libvirt] [PATCH] docs: document managed=yes of hostdev passthrough
by Eric Blake 21 Oct '11

21 Oct '11

Clarify some of the effects of managed passthrough <hostdev> devices; with today's recent changes, a nodedev-reattach is only needed to pair up to an explicit nodedev-dettach (but beware that virt-manager has a bug where it uses explicit nodedev-dettach under the hood when using the gui to hotplug a hostdev device). * docs/formatdomain.html.in: Mention reattach. * tools/virsh.pod (nodedev): Mention managed mode. --- My earlier commit beeab55 was pessimistic on when nodedev-reattach was needed, especially in light of today's patches. Hopefully this describes the situation with more accuracy. docs/formatdomain.html.in | 5 ++++- tools/virsh.pod | 30 ++++++++++++++++++------------ 2 files changed, 22 insertions(+), 13 deletions(-) diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index c007dff..bc20392 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -1410,7 +1410,10 @@ "subsystem" and <code>type</code> is "usb" for a USB device and "pci" for a PCI device. When <code>managed</code> is "yes" for a PCI device, it is detached from the host before being passed on to - the guest.</dd> + the guest, and reattached to the host after the guest exits; + otherwise, the user is responsible to + call <code>virNodeDeviceDettach</code> + and <code>virNodeDeviceReAttach</code> at appropriate points.</dd> <dt><code>source</code></dt> <dd>The source element describes the device as seen from the host. The USB device can either be addressed by vendor / product id using the diff --git a/tools/virsh.pod b/tools/virsh.pod index 74ae647..f9ac6b8 100644 --- a/tools/virsh.pod +++ b/tools/virsh.pod @@ -1211,7 +1211,8 @@ Attach a device to the domain, using a device definition in an XML file. See the documentation to learn about libvirt XML format for a device. For cdrom and floppy devices, this command only replaces the media within the single existing device; consider using B<update-device> for this usage. -For passthrough host devices, see also B<nodedev-dettach>. +For passthrough host devices, see also B<nodedev-dettach>, needed if +the device does not use managed mode. =item B<attach-disk> I<domain-id> I<source> I<target> [I<--driver driver>] [I<--subdriver subdriver>] [I<--cache cache>] @@ -1257,7 +1258,8 @@ will be created automatically. Detach a device from the domain, takes the same kind of XML descriptions as command B<attach-device>. -For passthrough host devices, see also B<nodedev-reattach>. +For passthrough host devices, see also B<nodedev-reattach>, needed if +the device does not use managed mode. =item B<detach-disk> I<domain-id> I<target> @@ -1299,11 +1301,16 @@ For more information on node device definition see: L<http://libvirt.org/formatnode.html>. Passthrough devices cannot be simultaneously used by the host and its -guest domains. Attempts to use a passthrough <hostdev> for a guest may -have the ability to behave as if B<nodedev-dettach> had been called, -although making this call explicitly is safe. Once a guest no longer -needs a passthrough device, reversing the process so that the host can -again use the device requires the explicit use of B<nodedev-reattach>. +guest domains. If the <hostdev> description includes the attribute +B<managed='yes'>, and the hypervisor supports it, then the device is +in managed mode, and attempts to use that passthrough device in an +active guest will automatically behave as if B<nodedev-dettach> (guest +start, device hot-plug) and B<nodedev-reattach> (guest stop, device +hot-unplug) were called at the right points. If a device is not +marked as managed, then it must manually be detached and reattached +before a guest can use it. Also, if a device is manually detached, +then the host does not regain control of the device without a matching +reattach, even if the guests use the device in managed mode. =over 4 @@ -1325,7 +1332,7 @@ by the rest of the physical host until a reboot. Detach I<nodedev> from the host, so that it can safely be used by guests via <hostdev> passthrough. This is reversed with -B<nodedev-reattach>. +B<nodedev-reattach>, and is done automatically for managed devices. =item B<nodedev-dumpxml> I<nodedev> @@ -1344,10 +1351,9 @@ formatted in a tree representing parents of each node. =item B<nodedev-reattach> I<nodedev> Declare that I<nodedev> is no longer in use by any guests, and that -the host can resume normal use of the device. While libvirt can -sometimes perform an implicit B<nodedev-dettach> when creating a -guest, it currently requires an explicit B<nodedev-reattach> after -the last guest use of the device before the host regains full control. +the host can resume normal use of the device. This is done +automatically for devices in managed mode, but must be done explicitly +to match any explicit B<nodedev-dettach>. =item B<nodedev-reset> I<nodedev> -- 1.7.4.4

2 3

[libvirt] [FYI] Skript to extract qcow2 snapshot info to libvirt snapshot xml
by Philipp Hahn 20 Oct '11

20 Oct '11

Hello, I sometimes get foreign qcow2 images with embedded snapshots. Without the corresponding XML files libvirt doesn't recognize them. Therefor I created the attached script to fake-create the missing snapshot XML files. Be advised that the XML files might not work in all cases, especially when the configuration was changed between snapshots, but at least I prefer a solution working 95% of the times instead of 0% ;-) And since I already wrote it, others might find it useful as well. Sincerely Philipp Hahn PS: An a drink of their reasonable choosing to the first one writing a qemu-img version printing (shell-)parsable output :-( -- Philipp Hahn Open Source Software Engineer hahn(a)univention.de Univention GmbH Linux for Your Business fon: +49 421 22 232- 0 Mary-Somerville-Str.1 D-28359 Bremen fax: +49 421 22 232-99 http://www.univention.de/

4 3

[libvirt] [PATCH] The output of domxml-to-native should be the same as the actual commandline.
by tangchen 20 Oct '11

20 Oct '11

Hi, There is a little difference between the output of domxml-to-native and the actual commandline. No matter qemu is in control or readline mode, domxml-to-native always converts it to readline mode. That is because the parameter "monitor_json" for qemuBuildCommandLine() is always set to false in qemuDomainXMLToNative(). Here is the patch, please comment! Signed-off-by: tangchen <tangchen(a)cn.fujitsu.com> --- src/qemu/qemu_driver.c | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 2e6f3e4..a564afb 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -4480,6 +4480,7 @@ static char *qemuDomainXMLToNative(virConnectPtr conn, virDomainDefPtr def = NULL; virDomainChrSourceDef monConfig; virBitmapPtr qemuCaps = NULL; + bool monitor_json = false; virCommandPtr cmd = NULL; char *ret = NULL; int i; @@ -4577,11 +4578,15 @@ static char *qemuDomainXMLToNative(virConnectPtr conn, &qemuCaps) < 0) goto cleanup; +#ifdef HAVE_YAJL + monitor_json = qemuCapsGet(qemuCaps, QEMU_CAPS_MONITOR_JSON); +#endif + if (qemuProcessPrepareMonitorChr(driver, &monConfig, def->name) < 0) goto cleanup; if (!(cmd = qemuBuildCommandLine(conn, driver, def, - &monConfig, false, qemuCaps, + &monConfig, monitor_json, qemuCaps, NULL, -1, NULL, VIR_VM_OP_NO_OP))) goto cleanup; -- 1.7.3.1 -- Best Regards, Tang chen

2 1

[libvirt] [PATCH] docs: fix incorrect info about routed networks
by Laine Stump 20 Oct '11

20 Oct '11

In a recent expansion of the documentation on network forward modes, I incorrectly stated that incoming sessions to guests on routed networks were blocked. This is true for guests on NATed networks, but not routed. This patch corrects that error, and adds a pointer to the nwfilter page for those who do want to restrict incoming sessions to hosts on routed networks. --- docs/formatnetwork.html.in | 12 ++++++------ 1 files changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/formatnetwork.html.in b/docs/formatnetwork.html.in index e06392b..02302fa 100644 --- a/docs/formatnetwork.html.in +++ b/docs/formatnetwork.html.in @@ -134,12 +134,12 @@ attribute is set, firewall rules will restrict forwarding to the named device only. This presumes that the local LAN router has suitable routing table entries to return - traffic to this host. Firewall rules are also installed - that prevent incoming sessions from the physical network - to the guests, but outgoing sessions are unrestricted (as - are sessions from the host to the guests, and between - guests on the same network.)<span class="since">Since - 0.4.2</span> + traffic to this host. All incoming and outgoing sessions + to guest on these networks are unrestricted. (To restrict + incoming traffic to a guest on a routed network, you can + configure <a href="formatnwfilter.html">nwfilter rules</a> + on the guest's interfaces.) + <span class="since">Since 0.4.2</span> </dd> <dt><code>bridge</code></dt> -- 1.7.6.4

2 1