- Devel - libvirt List Archives

[libvirt] [PATCHv2 00/16] bypass-cache in save/restore
by Eric Blake 22 Jul '11

22 Jul '11

Incorporating review comments from v1: https://www.redhat.com/archives/libvir-list/2011-July/msg00842.html Still to be written: new API for managing save state images in isolation: https://www.redhat.com/archives/libvir-list/2011-July/msg00855.html virConnectDomainSaveGetXMLDesc virConnectDomainSaveModify as well as virsh commands to wrap them: virsh managedsave-dumpxml file virsh managedsave-define file xml virsh managedsave-edit file Eric Blake (16): command: move all docs into .c file command: avoid leaking fds across fork build: rename files.h to virfile.h qemu: fix error message with migrate2 xml save: document new public API save: wire up remote protocol save: wire up trivial save/restore flags implementations save: add --bypass-cache flag to virsh save/restore operations save: support --xml to virsh save/restore save: let iohelper handle inherited fd save: let iohelper work on O_DIRECT fds save: add virFileDirectFd wrapper type save: support BYPASS_CACHE during qemu save/restore save: support bypass-cache flag in qemu.conf save: support bypass-cache flag in libvirt-guests init script save: support qemu modifying xml on domain save/restore HACKING | 2 +- cfg.mk | 3 +- configure.ac | 6 +- daemon/libvirtd.c | 2 +- docs/hacking.html.in | 2 +- include/libvirt/libvirt.h.in | 30 ++- po/POTFILES.in | 1 + src/Makefile.am | 2 +- src/conf/domain_conf.c | 2 +- src/conf/network_conf.c | 2 +- src/conf/nwfilter_conf.c | 2 +- src/conf/storage_conf.c | 2 +- src/conf/storage_encryption_conf.c | 2 +- src/driver.h | 12 + src/fdstream.c | 36 +-- src/libvirt.c | 181 ++++++++++++- src/libvirt_private.syms | 16 +- src/libvirt_public.syms | 2 + src/libxl/libxl_conf.c | 2 +- src/libxl/libxl_driver.c | 36 +++- src/locking/lock_driver_sanlock.c | 2 +- src/lxc/lxc_container.c | 2 +- src/lxc/lxc_controller.c | 2 +- src/lxc/lxc_driver.c | 2 +- src/node_device/node_device_linux_sysfs.c | 2 +- src/nodeinfo.c | 2 +- src/nwfilter/nwfilter_ebiptables_driver.c | 2 +- src/openvz/openvz_conf.c | 2 +- src/openvz/openvz_driver.c | 2 +- src/phyp/phyp_driver.c | 2 +- src/qemu/libvirtd_qemu.aug | 2 + src/qemu/qemu.conf | 16 + src/qemu/qemu_capabilities.c | 2 +- src/qemu/qemu_command.c | 18 +-- src/qemu/qemu_conf.c | 12 +- src/qemu/qemu_conf.h | 5 +- src/qemu/qemu_domain.c | 2 +- src/qemu/qemu_driver.c | 229 ++++++++++++---- src/qemu/qemu_hotplug.c | 2 +- src/qemu/qemu_migration.c | 4 +- src/qemu/qemu_monitor.c | 2 +- src/qemu/qemu_process.c | 2 +- src/remote/remote_driver.c | 4 +- src/remote/remote_protocol.x | 17 +- src/remote_protocol-structs | 13 + src/rpc/virnetclient.c | 2 +- src/rpc/virnetserver.c | 2 +- src/rpc/virnetsocket.c | 2 +- src/secret/secret_driver.c | 2 +- src/security/security_apparmor.c | 2 +- src/security/security_selinux.c | 2 +- src/security/virt-aa-helper.c | 2 +- src/storage/storage_backend.c | 2 +- src/storage/storage_backend_fs.c | 2 +- src/storage/storage_backend_iscsi.c | 2 +- src/storage/storage_backend_logical.c | 2 +- src/storage/storage_backend_mpath.c | 2 +- src/storage/storage_backend_scsi.c | 2 +- src/storage/storage_driver.c | 2 +- src/test/test_driver.c | 44 +++- src/uml/uml_conf.c | 2 +- src/uml/uml_driver.c | 2 +- src/util/bridge.c | 2 +- src/util/cgroup.c | 2 +- src/util/command.c | 430 +++++++++++++++++++++-------- src/util/command.h | 223 +-------------- src/util/conf.c | 2 +- src/util/dnsmasq.c | 2 +- src/util/event_poll.c | 2 +- src/util/files.c | 80 ------ src/util/hooks.c | 2 +- src/util/interface.c | 2 +- src/util/iohelper.c | 194 ++++++++++--- src/util/logging.c | 2 +- src/util/macvtap.c | 2 +- src/util/pci.c | 2 +- src/util/stats_linux.c | 2 +- src/util/storage_file.c | 2 +- src/util/util.c | 2 +- src/util/uuid.c | 2 +- src/util/viraudit.c | 2 +- src/util/virfile.c | 253 +++++++++++++++++ src/util/{files.h => virfile.h} | 33 ++- src/vbox/vbox_tmpl.c | 2 +- src/vmware/vmware_conf.c | 2 +- src/vmware/vmware_driver.c | 2 +- src/xen/block_stats.c | 2 +- src/xen/xen_driver.c | 36 +++- src/xen/xen_hypervisor.c | 2 +- src/xen/xen_inotify.c | 2 +- src/xen/xend_internal.c | 2 +- tests/commandhelper.c | 2 +- tests/commandtest.c | 2 +- tests/nodeinfotest.c | 2 +- tests/testutils.c | 2 +- tests/virnetsockettest.c | 2 +- tests/xencapstest.c | 2 +- tools/console.c | 2 +- tools/libvirt-guests.init.sh | 10 +- tools/libvirt-guests.sysconf | 5 + tools/virsh.c | 107 ++++++-- tools/virsh.pod | 47 +++- 102 files changed, 1560 insertions(+), 685 deletions(-) delete mode 100644 src/util/files.c create mode 100644 src/util/virfile.c rename src/util/{files.h => virfile.h} (57%) -- 1.7.4.4

2 45

[libvirt] [PATCH] Ensure that libvirtd shuts down if initialization fails
by Daniel P. Berrange 22 Jul '11

22 Jul '11

From: "Daniel P. Berrange" <berrange(a)redhat.com> If the virStateInitialize call fails we must shutdown libvirtd since drivers will not be available. Just free'ing the virNetServer is not sufficient, we must send a SIGTERM to ourselves so that we interrupt the event loop and trigger a orderly shutdown * daemon/libvirtd.c: Kill ourselves if state init fails * src/rpc/virnetserver.c: Add some debugging to event loop --- daemon/libvirtd.c | 2 ++ src/rpc/virnetserver.c | 2 ++ 2 files changed, 4 insertions(+), 0 deletions(-) diff --git a/daemon/libvirtd.c b/daemon/libvirtd.c index 8f8b8b1..4a5f671 100644 --- a/daemon/libvirtd.c +++ b/daemon/libvirtd.c @@ -1160,6 +1160,8 @@ static void daemonRunStateInit(void *opaque) * seriously delay OS bootup process */ if (virStateInitialize(virNetServerIsPrivileged(srv)) < 0) { VIR_ERROR(_("Driver state initialization failed")); + /* Ensure the main event loop quits */ + kill(getpid(), SIGTERM); virNetServerFree(srv); return; } diff --git a/src/rpc/virnetserver.c b/src/rpc/virnetserver.c index 35f18b9..8f3ac4b 100644 --- a/src/rpc/virnetserver.c +++ b/src/rpc/virnetserver.c @@ -671,6 +671,7 @@ void virNetServerRun(virNetServerPtr srv) goto cleanup; } + VIR_DEBUG("srv=%p quit=%d", srv, srv->quit); while (!srv->quit) { /* A shutdown timeout is specified, so check * if any drivers have active state, if not @@ -731,6 +732,7 @@ void virNetServerQuit(virNetServerPtr srv) { virNetServerLock(srv); + VIR_DEBUG("Quit requested %p", srv); srv->quit = 1; virNetServerUnlock(srv); -- 1.7.6

2 1

[libvirt] [PATCH] Remove call to deprecated gnutls_certificate_type_set_priority (again)
by Daniel P. Berrange 22 Jul '11

22 Jul '11

From: "Daniel P. Berrange" <berrange(a)redhat.com> The gnutls_certificate_type_set_priority method is deprecated. Since we already set the default gnutls priority, it was not serving any useful purpose and can be removed * src/rpc/virnettlscontext.c: Remove gnutls_certificate_type_set_priority call --- src/rpc/virnettlscontext.c | 5 +---- 1 files changed, 1 insertions(+), 4 deletions(-) diff --git a/src/rpc/virnettlscontext.c b/src/rpc/virnettlscontext.c index 9279ded..ae16dbb 100644 --- a/src/rpc/virnettlscontext.c +++ b/src/rpc/virnettlscontext.c @@ -1115,7 +1115,6 @@ virNetTLSSessionPtr virNetTLSSessionNew(virNetTLSContextPtr ctxt, { virNetTLSSessionPtr sess; int err; - static const int cert_type_priority[] = { GNUTLS_CRT_X509, 0 }; VIR_DEBUG("ctxt=%p hostname=%s isServer=%d", ctxt, NULLSTR(hostname), ctxt->isServer); @@ -1142,9 +1141,7 @@ virNetTLSSessionPtr virNetTLSSessionNew(virNetTLSContextPtr ctxt, /* avoid calling all the priority functions, since the defaults * are adequate. */ - if ((err = gnutls_set_default_priority(sess->session)) != 0 || - (err = gnutls_certificate_type_set_priority(sess->session, - cert_type_priority))) { + if ((err = gnutls_set_default_priority(sess->session)) != 0) { virNetError(VIR_ERR_SYSTEM_ERROR, _("Failed to set TLS session priority %s"), gnutls_strerror(err)); -- 1.7.6

2 1

[libvirt] [PATCH] error: add new error type for reflecting partial API support
by Eric Blake 22 Jul '11

22 Jul '11

VIR_ERR_INVALID_ARG implies that an argument cannot possibly be correct, given the current state of the API. VIR_ERR_CONFIG_UNSUPPORTED implies that a configuration is wrong, but arguments aren't configuration. VIR_ERR_NO_SUPPORT implies that a function is completely unimplemented. But in the case of a function that is partially implemented, yet the full power of the API is not available for that driver, none of the above messages make sense. Hence a new error message, implying that the argument is known to comply with the current state of the API, and that while the driver supports aspects of the function, it does not support that particular use of the argument. A good use case for this is a driver that supports virDomainSaveFlags, but not the dxml argument of that API. It might be feasible to also use this new error for all functions that check flags, and which accept fewer flags than what is possible in the public API. But doing so would get complicated, since neither libvirt.c nor the remote driver may do flag filtering, and every other driver would have to do a two-part check, first using virCheckFlags on all public flags (which gives VIR_ERR_INVALID_ARG for an impossible flag), followed by a particular mask check for VIR_ERR_ARGUMENT_UNSUPPORTED (for a possible public flag but unsupported by this driver). * include/libvirt/virterror.h (VIR_ERR_ARGUMENT_UNSUPPORTED): New error. * src/util/virterror.c (virErrorMsg): Give it a message. Suggested by Daniel P. Berrange. --- Needed before v3 of 7/16 of the bypass-cache series: https://www.redhat.com/archives/libvir-list/2011-July/msg01470.html include/libvirt/virterror.h | 4 +++- src/util/virterror.c | 6 ++++++ 2 files changed, 9 insertions(+), 1 deletions(-) diff --git a/include/libvirt/virterror.h b/include/libvirt/virterror.h index efa4796..9cac437 100644 --- a/include/libvirt/virterror.h +++ b/include/libvirt/virterror.h @@ -4,7 +4,7 @@ * Description: Provides the interfaces of the libvirt library to handle * errors raised while using the library. * - * Copy: Copyright (C) 2006, 2010 Red Hat, Inc. + * Copy: Copyright (C) 2006, 2010-2011 Red Hat, Inc. * * See COPYING.LIB for the License of this software * @@ -232,6 +232,8 @@ typedef enum { VIR_ERR_INVALID_DOMAIN_SNAPSHOT = 71,/* invalid domain snapshot */ VIR_ERR_NO_DOMAIN_SNAPSHOT = 72, /* domain snapshot not found */ VIR_ERR_INVALID_STREAM = 73, /* stream pointer not valid */ + VIR_ERR_ARGUMENT_UNSUPPORTED = 74, /* valid API use but unsupported by + the given driver */ } virErrorNumber; /** diff --git a/src/util/virterror.c b/src/util/virterror.c index 07f8b45..9a27feb 100644 --- a/src/util/virterror.c +++ b/src/util/virterror.c @@ -1183,6 +1183,12 @@ virErrorMsg(virErrorNumber error, const char *info) else errmsg = _("invalid stream pointer in %s"); break; + case VIR_ERR_ARGUMENT_UNSUPPORTED: + if (info == NULL) + errmsg = _("argument unsupported"); + else + errmsg = _("argument unsupported: %s"); + break; } return (errmsg); } -- 1.7.4.4

2 2

[libvirt] [PATCH] remote: Fix forgotten comma
by Michal Privoznik 21 Jul '11

21 Jul '11

during conflict resolving --- Pushing under trivial & build-breaker rules src/remote/remote_protocol.x | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/remote/remote_protocol.x b/src/remote/remote_protocol.x index 1ada5f9..f300204 100644 --- a/src/remote/remote_protocol.x +++ b/src/remote/remote_protocol.x @@ -2410,7 +2410,7 @@ enum remote_procedure { REMOTE_PROC_DOMAIN_UNDEFINE_FLAGS = 231, /* autogen autogen */ REMOTE_PROC_DOMAIN_SAVE_FLAGS = 232, /* autogen autogen */ - REMOTE_PROC_DOMAIN_RESTORE_FLAGS = 233 /* autogen autogen */ + REMOTE_PROC_DOMAIN_RESTORE_FLAGS = 233, /* autogen autogen */ REMOTE_PROC_DOMAIN_DESTROY_FLAGS = 234 /* autogen autogen */ /* -- 1.7.5.rc3

2 1

[libvirt] [PATCHv2 00/13] New API: virDominDestroyFlags
by Michal Privoznik 21 Jul '11

21 Jul '11

This series creates new API which adds flags to virDomainDestroy. As mentioned here many times, it is a bad luck all APIs don't have flags parameter. Parameter for this might be needed to select different ways of destroying a domain. For example, qemu has 'quit' command, which force it to flush internal caches a thus preventing from data loss. Or vice versa - in cases where we are doing hypervisor assisted destroy we might want to send signals, because hypervisor is not responding. Currently, no new functionality is implemented, but this paves the way for creating multiple ways of domain destroying. Therefore, calling this new API is the same as calling its predecessor. diff to v1: -rename virDominDestroyWithFlags() to virDominDestroyFlags() -rename enum virDominDestroyFlags to virDominDestroyFlagsValues Michal Privoznik (13): destroy: Define new public API virDomainDestroyFlags destroy: Wire up the remote protocol destroy: Implement internal API for qemu driver destroy: Implement internal API for ESX driver destroy: Implement internal API for libxl driver destroy: Implement internal API for lxc driver destroy: Implement internal API for openvz driver destroy: Implement internal API for phyp driver destroy: Implement internal API for uml driver destroy: Implement internal API for vbox driver destroy: Implement internal API for vmware driver destroy: Implement internal API for xen driver destroy: Implement internal API for xenapi driver include/libvirt/libvirt.h.in | 7 +++++ src/driver.h | 4 +++ src/esx/esx_driver.c | 12 +++++++++- src/libvirt.c | 52 ++++++++++++++++++++++++++++++++++++++++++ src/libvirt_public.syms | 1 + src/libxl/libxl_driver.c | 12 +++++++++- src/lxc/lxc_driver.c | 23 +++++++++++++++++- src/openvz/openvz_driver.c | 13 +++++++++- src/phyp/phyp_driver.c | 12 +++++++++- src/qemu/qemu_driver.c | 13 +++++++++- src/remote/remote_driver.c | 1 + src/remote/remote_protocol.x | 8 +++++- src/remote_protocol-structs | 5 ++++ src/uml/uml_driver.c | 14 ++++++++++- src/vbox/vbox_tmpl.c | 14 ++++++++++- src/vmware/vmware_driver.c | 12 +++++++++- src/xen/xen_driver.c | 28 ++++++++++++++++++++++ src/xen/xen_driver.h | 1 + src/xen/xen_hypervisor.c | 24 +++++++++++++++++- src/xen/xen_hypervisor.h | 3 ++ src/xen/xen_inotify.c | 1 + src/xen/xend_internal.c | 24 +++++++++++++++++- src/xen/xm_internal.c | 1 + src/xen/xs_internal.c | 1 + src/xenapi/xenapi_driver.c | 22 ++++++++++++++++- 25 files changed, 291 insertions(+), 17 deletions(-) -- 1.7.5.rc3

3 18

[libvirt] [PATCH RFC 0/3] undefine: Interface for undefinig storage devices along with domains
by Peter Krempa 21 Jul '11

21 Jul '11

This extension of flags used while undefining domains grants the user ability to remove virtual storage devices while undefining a domain. This is only a demonstration, implemented only for the QEMU/KVM emulators. I'd like to know your opinions and comments and soon i'll provide patches for other emulators as well. Thanks for your precious time :) Peter Peter Krempa (3): undefine: Add flags for removing storage files when undefining a domain. undefine: QEMU driver - remove storage associated with a domain while undefining undefine: Add coresponding switches to virsh, for removing storage devices associated with domain include/libvirt/libvirt.h.in | 2 ++ src/qemu/qemu_driver.c | 32 +++++++++++++++++++++++++++++++- tools/virsh.c | 17 ++++++++++++++++- 3 files changed, 49 insertions(+), 2 deletions(-) -- 1.7.6

3 8

[libvirt] [PATCH v2] rpc: Make the dispatch generator handle 'void name(void)' style procedures
by Matthias Bolte 21 Jul '11

21 Jul '11

The only 'void name(void)' style procedure in the protocol is 'close' that is handled special, but also programming errors like a missing _args or _ret suffix on the structs in the .x files can create such a situation by accident. Making the generator aware of this avoids bogus errors from the generator such as: Use of uninitialized value in exists at ./rpc/gendispatch.pl line 967. Also this allows to get rid of the -c option and the special case code for the 'close' procedure, as the generator handles it now correctly. Reported by Michal Privoznik --- v2: - remove the special handling of the 'close' procedure daemon/Makefile.am | 2 +- src/Makefile.am | 2 +- src/rpc/gendispatch.pl | 32 +++++++++++++++++--------------- 3 files changed, 19 insertions(+), 17 deletions(-) diff --git a/daemon/Makefile.am b/daemon/Makefile.am index 8ed29b8..63c731e 100644 --- a/daemon/Makefile.am +++ b/daemon/Makefile.am @@ -44,7 +44,7 @@ QEMU_PROTOCOL = $(top_srcdir)/src/remote/qemu_protocol.x $(srcdir)/remote_dispatch.h: $(srcdir)/../src/rpc/gendispatch.pl \ $(REMOTE_PROTOCOL) - $(AM_V_GEN)perl -w $(srcdir)/../src/rpc/gendispatch.pl -c -b remote \ + $(AM_V_GEN)perl -w $(srcdir)/../src/rpc/gendispatch.pl -b remote \ $(REMOTE_PROTOCOL) > $@ $(srcdir)/qemu_dispatch.h: $(srcdir)/../src/rpc/gendispatch.pl \ diff --git a/src/Makefile.am b/src/Makefile.am index fadde28..00e78ac 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -188,7 +188,7 @@ REMOTE_DRIVER_PROTOCOL = $(REMOTE_PROTOCOL) $(QEMU_PROTOCOL) $(srcdir)/remote/remote_client_bodies.h: $(srcdir)/rpc/gendispatch.pl \ $(REMOTE_PROTOCOL) $(AM_V_GEN)perl -w $(srcdir)/rpc/gendispatch.pl \ - -c -k remote $(REMOTE_PROTOCOL) > $@ + -k remote $(REMOTE_PROTOCOL) > $@ $(srcdir)/remote/qemu_client_bodies.h: $(srcdir)/rpc/gendispatch.pl \ $(QEMU_PROTOCOL) diff --git a/src/rpc/gendispatch.pl b/src/rpc/gendispatch.pl index e068b53..6e26e2d 100755 --- a/src/rpc/gendispatch.pl +++ b/src/rpc/gendispatch.pl @@ -9,7 +9,7 @@ # for both remote_protocol.x and qemu_protocol.x, you would run the # following: # -# gendispatch.pl -c -t remote ../src/remote/remote_protocol.x +# gendispatch.pl -t remote ../src/remote/remote_protocol.x # gendispatch.pl -t qemu ../src/remote/qemu_protocol.x # # By Richard Jones <rjones(a)redhat.com> @@ -20,8 +20,8 @@ use strict; use Getopt::Std; # Command line options. -our ($opt_p, $opt_t, $opt_a, $opt_r, $opt_d, $opt_c, $opt_b, $opt_k); -getopts ('ptardcbk'); +our ($opt_p, $opt_t, $opt_a, $opt_r, $opt_d, $opt_b, $opt_k); +getopts ('ptardbk'); my $structprefix = shift or die "missing prefix argument"; my $protocol = shift or die "missing protocol argument"; @@ -45,18 +45,6 @@ sub name_to_ProcName { # opinion about the name, args and return type of each RPC. my ($name, $ProcName, $id, $flags, %calls, @calls); -# only generate a close method if -c was passed -if ($opt_c) { - # REMOTE_PROC_CLOSE has no args or ret. - $calls{close} = { - name => "close", - ProcName => "Close", - UC_NAME => "CLOSE", - args => "void", - ret => "void", - }; -} - my $collect_args_members = 0; my $collect_ret_members = 0; my $last_name; @@ -143,6 +131,20 @@ while (<PROTOCOL>) { $flags = $3; $ProcName = name_to_ProcName ($name); + if (!exists $calls{$name}) { + # that the argument and return value cases have not yet added + # this procedure to the calls hash means that it has no arguments + # and no return value. add it to the calls hash now because all + # procedures have to be listed in the calls hash + $calls{$name} = { + name => $name, + ProcName => $ProcName, + UC_NAME => uc $name, + args => "void", + ret => "void" + } + } + if ($opt_b or $opt_k) { if (!($flags =~ m/^\s*\/\*\s*(\S+)\s+(\S+)\s*(.*)\*\/\s*$/)) { die "invalid generator flags for ${procprefix}_PROC_${name}" -- 1.7.4.1

2 2

[libvirt] [PATCH 00/13] New API: virDominDestroyWithFlags
by Michal Privoznik 21 Jul '11

21 Jul '11

This series creates new API which adds flags to virDomainDestroy. As mentioned here many times, it is a bad luck all APIs don't have flags parameter. Parameter for this might be needed to select different ways of destroying a domain. For example, qemu has 'quit' command, which force it to flush internal caches a thus preventing from data loss. Or vice versa - in cases where we are doing hypervisor assisted destroy we might want to send signals, because hypervisor is not responding. Currently, no new functionality is implemented, but this paves the way for creating multiple ways of domain destroying. Therefore, calling this new API is the same as calling its predecessor. Michal Privoznik (13): destroy: Define new public API virDomainDestroyWithFlags destroy: Wire up the remote protocol destroy: Implement internal API for qemu driver destroy: Implement internal API for ESX driver destroy: Implement internal API for libxl driver destroy: Implement internal API for lxc driver destroy: Implement internal API for openvz driver destroy: Implement internal API for phyp driver destroy: Implement internal API for uml driver destroy: Implement internal API for vbox driver destroy: Implement internal API for vmware driver destroy: Implement internal API for xen driver destroy: Implement internal API for xenapi driver include/libvirt/libvirt.h.in | 7 +++++ src/driver.h | 4 +++ src/esx/esx_driver.c | 12 +++++++++- src/libvirt.c | 52 ++++++++++++++++++++++++++++++++++++++++++ src/libvirt_public.syms | 1 + src/libxl/libxl_driver.c | 12 +++++++++- src/lxc/lxc_driver.c | 23 +++++++++++++++++- src/openvz/openvz_driver.c | 13 +++++++++- src/phyp/phyp_driver.c | 12 +++++++++- src/qemu/qemu_driver.c | 13 +++++++++- src/remote/remote_driver.c | 1 + src/remote/remote_protocol.x | 8 +++++- src/remote_protocol-structs | 5 ++++ src/uml/uml_driver.c | 14 ++++++++++- src/vbox/vbox_tmpl.c | 14 ++++++++++- src/vmware/vmware_driver.c | 12 +++++++++- src/xen/xen_driver.c | 28 ++++++++++++++++++++++ src/xen/xen_driver.h | 1 + src/xen/xen_hypervisor.c | 24 +++++++++++++++++- src/xen/xen_hypervisor.h | 3 ++ src/xen/xen_inotify.c | 1 + src/xen/xend_internal.c | 24 +++++++++++++++++- src/xen/xm_internal.c | 1 + src/xen/xs_internal.c | 1 + src/xenapi/xenapi_driver.c | 22 ++++++++++++++++- 25 files changed, 291 insertions(+), 17 deletions(-) -- 1.7.5.rc3

3 19

[libvirt] [PATCH] error: preserve errno when saving last error
by Eric Blake 21 Jul '11

21 Jul '11

It is common to see the sequence: virErrorPtr save_err = virSaveLastError(); // do cleanup virSetError(save_err); virFreeError(save_err); on cleanup paths. But for functions where it is desirable to return the errno that caused failure, this sequence can clobber that errno. virFreeError was already safe; this makes the other two functions in the sequence safe as well, assuming all goes well (on OOM, errno will be clobbered, but then again, save_err won't reflect the real error that happened, so you are no longer preserving the real situation - that's life with OOM). * src/util/virterror.c (virSaveLastError, virSetError): Preserve errno. --- Fixes an errno-clobbering situation pointed out here: https://www.redhat.com/archives/libvir-list/2011-July/msg01382.html src/util/virterror.c | 17 +++++++++++++---- 1 files changed, 13 insertions(+), 4 deletions(-) diff --git a/src/util/virterror.c b/src/util/virterror.c index 0c7698a..07f8b45 100644 --- a/src/util/virterror.c +++ b/src/util/virterror.c @@ -295,18 +295,24 @@ virGetLastError(void) * Can be used to re-set an old error, which may have been squashed by * other functions (like cleanup routines). * - * Returns 0 on success, 1 on failure + * Returns 0 on success, -1 on failure. Leaves errno unchanged. */ int virSetError(virErrorPtr newerr) { virErrorPtr err; + int saved_errno = errno; + int ret = -1; + err = virLastErrorObject(); if (!err) - return -1; + goto cleanup; virResetError(err); - return virCopyError(newerr, err); + ret = virCopyError(newerr, err); +cleanup: + errno = saved_errno; + return ret; } /** @@ -339,7 +345,8 @@ virCopyLastError(virErrorPtr to) /** * virSaveLastError: * - * Save the last error into a new error object. + * Save the last error into a new error object. On success, errno is + * unchanged; on failure, errno is ENOMEM. * * Returns a pointer to the copied error or NULL if allocation failed. * It is the caller's responsibility to free the error with @@ -349,11 +356,13 @@ virErrorPtr virSaveLastError(void) { virErrorPtr to; + int saved_errno = errno; if (VIR_ALLOC(to) < 0) return NULL; virCopyLastError(to); + errno = saved_errno; return to; } -- 1.7.4.4

2 2

[libvirt] [PATCH] python: Fix makefile rule for code generation
by Matthias Bolte 21 Jul '11

21 Jul '11

Commit 8665f85523f0451c changed generated.stamp to $(GENERATE).stamp, but missed one instance in the CLEANFILES list. This can break the build in case the generated code is deleted but the .stamp file stays around and therefore the code isn't regenerated. --- python/Makefile.am | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/python/Makefile.am b/python/Makefile.am index a4c9a6b..51f005d 100644 --- a/python/Makefile.am +++ b/python/Makefile.am @@ -71,7 +71,7 @@ install-data-local: uninstall-local: rm -f $(DESTDIR)$(pyexecdir)/libvirt.py -CLEANFILES= $(GENERATED) generated.stamp +CLEANFILES= $(GENERATED) $(GENERATE).stamp else all: -- 1.7.4.1

2 2

[libvirt] [PATCH v2 0/7] Add support for setting QoS
by Michal Privoznik 21 Jul '11

21 Jul '11

This patch series add support for setting traffic shaping and policing on both domain's interface and network's virtual bridge. Basically, this is done via 'tc' from iproute2 package. For shaping is HTB used, for policing we need u32 match selector. Both should be available in RHEL-6 kernel. How this works: On an virtual interface which has limits defined a root qdisc are replaced. Ingress root for outbound traffic shaping and egress for inbound. Basically, in inbound traffic policing is applied, on outbound shaping. New qdiscs are set to limit the traffic to rate set in XML. For shaping it is possible to set the size of buffer. Accepted values for rate, peak and burst have same format as 'tc' command and are documented. Supported devices are VIR_DOMAIN_NET_TYPE_NETWORK, VIR_DOMAIN_NET_TYPE_BRIDGE and VIR_DOMAIN_NET_TYPE_DIRECT. diff to v1: -rebase to current HEAD -add support for macvtap devices Michal Privoznik (7): bandwidth: Define schema and create documentation bandwidth: Declare internal structures bandwidth: Add format parsing functions bandwidth: Create format functions bandwitdh: Implement functions to enable and disable QoS bandwidth: Add test cases for network bandwidth: Add domain schema test suite configure.ac | 4 + docs/formatdomain.html.in | 32 ++ docs/formatnetwork.html.in | 30 ++ docs/schemas/domain.rng | 50 +++ docs/schemas/network.rng | 50 +++ src/conf/domain_conf.c | 6 + src/conf/domain_conf.h | 1 + src/conf/network_conf.c | 8 + src/conf/network_conf.h | 1 + src/libvirt_private.syms | 6 + src/network/bridge_driver.c | 12 + src/qemu/qemu_command.c | 10 +- src/util/macvtap.c | 12 +- src/util/macvtap.h | 5 +- src/util/network.c | 517 +++++++++++++++++++++++++ src/util/network.h | 28 ++ tests/domainschemadata/domain-bandwidth.xml | 72 ++++ tests/networkxml2xmlin/bandwidth-network.xml | 16 + tests/networkxml2xmlout/bandwidth-network.xml | 16 + tests/networkxml2xmltest.c | 1 + 20 files changed, 873 insertions(+), 4 deletions(-) create mode 100644 tests/domainschemadata/domain-bandwidth.xml create mode 100644 tests/networkxml2xmlin/bandwidth-network.xml create mode 100644 tests/networkxml2xmlout/bandwidth-network.xml -- 1.7.5.rc3

6 19

[libvirt] [PATCH 0/7] Add support for setting QoS
by Michal Privoznik 21 Jul '11

21 Jul '11

This patch series add support for setting traffic shaping and policing on both domain's interface and network's virtual bridge. Basically, this is done via 'tc' from iproute2 package. For shaping is HTB used, for policing we need u32 match selector. Both should be available in RHEL-6 kernel. How this works: On an virtual interface which has limits defined a root qdisc are replaced. Ingress root for outbound traffic shaping and egress for inbound. Basically, in inbound traffic policing is applied, on outbound shaping. New qdiscs are set to limit the traffic to rate set in XML. For shaping it is possible to set the size of buffer. Accepted values for rate, peak and burst are integer numbers. Units are kilobytes per second for rate or kilobytes for size. Supported devices are VIR_DOMAIN_NET_TYPE_NETWORK, VIR_DOMAIN_NET_TYPE_BRIDGE and VIR_DOMAIN_NET_TYPE_DIRECT. diff to v2: -Jirka's review included diff to v1: -rebase to current HEAD -add support for macvtap devices Michal Privoznik (7): bandwidth: Define schema and create documentation bandwidth: Declare internal structures bandwidth: Add parsing functions bandwidth: Create format functions bandwitdh: Implement functions to enable and disable QoS bandwidth: Add test cases for network bandwidth: Add domain schema test suite configure.ac | 4 + docs/formatdomain.html.in | 33 +++ docs/formatnetwork.html.in | 30 +++ docs/schemas/bandwidth.rng | 52 ++++ docs/schemas/domain.rng | 4 + docs/schemas/network.rng | 4 + src/conf/domain_conf.c | 6 + src/conf/domain_conf.h | 1 + src/conf/network_conf.c | 8 + src/conf/network_conf.h | 1 + src/libvirt_private.syms | 4 + src/network/bridge_driver.c | 12 + src/qemu/qemu_command.c | 10 +- src/util/macvtap.c | 12 +- src/util/macvtap.h | 5 +- src/util/network.c | 345 +++++++++++++++++++++++++ src/util/network.h | 23 ++ tests/domainschemadata/domain-bandwidth.xml | 72 +++++ tests/networkxml2xmlin/bandwidth-network.xml | 16 ++ tests/networkxml2xmlout/bandwidth-network.xml | 16 ++ tests/networkxml2xmltest.c | 1 + 21 files changed, 655 insertions(+), 4 deletions(-) create mode 100644 docs/schemas/bandwidth.rng create mode 100644 tests/domainschemadata/domain-bandwidth.xml create mode 100644 tests/networkxml2xmlin/bandwidth-network.xml create mode 100644 tests/networkxml2xmlout/bandwidth-network.xml -- 1.7.5.rc3

5 24

[libvirt] Schedule for release of 0.9.4
by Daniel Veillard 21 Jul '11

21 Jul '11

I should have posted this beginning of this week... Basically I would like to freeze for 0.9.4 next Monday, which means we need to finish ACK'ing and pushing the number of patch sets which are well advanced already. Then try to get a final 0.9.4 release on Aug 1 or 2. So let's make sure we have updated patches on the list and let's review the patches and apply them ! This includes: - virtual switch support - support for cpu bandwith (Wen can you provide a patchset including latest feedback ?) - New virDomainBlockPull API (Adam can you provide a new patchset too ?) - and various other patch(set)s floating around And if you sent a patch which got no feedback, please raise it again, thanks everybody ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/

2 2

[libvirt] [PATCH] maint: fix typos on guaranteed
by Eric Blake 21 Jul '11

21 Jul '11

* src/conf/domain_event.c (virDomainEventDispatch): Fix typo. * src/internal.h (ATTRIBUTE_FMT_PRINTF): Likewise. * src/libvirt.c (virStreamEventUpdateCallback): Likewise. * src/remote/remote_driver.c (doRemoteOpen): Likewise. * src/storage/storage_backend_fs.c (virStorageBackendProbeTarget): Likewise. * src/util/virterror.c (virConnCopyLastError, virCopyLastError): Likewise. * src/xen/xend_internal.h (xend_wait_for_devices): Likewise. --- Pushing under the trivial rule. src/conf/domain_event.c | 2 +- src/internal.h | 2 +- src/libvirt.c | 2 +- src/remote/remote_driver.c | 2 +- src/storage/storage_backend_fs.c | 2 +- src/util/virterror.c | 4 ++-- src/xen/xend_internal.h | 2 +- 7 files changed, 8 insertions(+), 8 deletions(-) diff --git a/src/conf/domain_event.c b/src/conf/domain_event.c index c435484..d43331f 100644 --- a/src/conf/domain_event.c +++ b/src/conf/domain_event.c @@ -1069,7 +1069,7 @@ void virDomainEventDispatch(virDomainEventPtr event, { int i; /* Cache this now, since we may be dropping the lock, - and have more callbacks added. We're guarenteed not + and have more callbacks added. We're guaranteed not to have any removed */ int cbCount = callbacks->count; diff --git a/src/internal.h b/src/internal.h index 5747a90..1997031 100644 --- a/src/internal.h +++ b/src/internal.h @@ -140,7 +140,7 @@ * Macro used to check printf like functions, if compiling * with gcc. * - * We use gnulib which guarentees we always have GNU style + * We use gnulib which guarantees we always have GNU style * printf format specifiers even on broken Win32 platforms * hence we have to force 'gnu_printf' for new GCC */ diff --git a/src/libvirt.c b/src/libvirt.c index 2f5241a..16a9a02 100644 --- a/src/libvirt.c +++ b/src/libvirt.c @@ -13390,7 +13390,7 @@ error: * Changes the set of events to monitor for a stream. This allows * for event notification to be changed without having to * unregister & register the callback completely. This method - * is guarenteed to succeed if a callback is already registered + * is guaranteed to succeed if a callback is already registered * * Returns 0 on success, -1 if no callback is registered */ diff --git a/src/remote/remote_driver.c b/src/remote/remote_driver.c index 6ba58ed..82b938c 100644 --- a/src/remote/remote_driver.c +++ b/src/remote/remote_driver.c @@ -584,7 +584,7 @@ doRemoteOpen (virConnectPtr conn, if (!(priv->client = virNetClientNewExternal(cmd_argv))) goto failed; - /* Do not set 'is_secure' flag since we can't guarentee + /* Do not set 'is_secure' flag since we can't guarantee * an external program is secure, and this flag must be * pessimistic */ } break; diff --git a/src/storage/storage_backend_fs.c b/src/storage/storage_backend_fs.c index 8d6f76d..1656215 100644 --- a/src/storage/storage_backend_fs.c +++ b/src/storage/storage_backend_fs.c @@ -143,7 +143,7 @@ virStorageBackendProbeTarget(virStorageVolTargetPtr target, } /* XXX ideally we'd fill in secret UUID here - * but we cannot guarentee 'conn' is non-NULL + * but we cannot guarantee 'conn' is non-NULL * at this point in time :-( So we only fill * in secrets when someone first queries a vol */ diff --git a/src/util/virterror.c b/src/util/virterror.c index 75058f3..0c7698a 100644 --- a/src/util/virterror.c +++ b/src/util/virterror.c @@ -327,7 +327,7 @@ int virCopyLastError(virErrorPtr to) { virErrorPtr err = virLastErrorObject(); - /* We can't guarentee caller has initialized it to zero */ + /* We can't guarantee caller has initialized it to zero */ memset(to, 0, sizeof(*to)); if (err) virCopyError(err, to); @@ -464,7 +464,7 @@ virConnGetLastError(virConnectPtr conn) int virConnCopyLastError(virConnectPtr conn, virErrorPtr to) { - /* We can't guarentee caller has initialized it to zero */ + /* We can't guarantee caller has initialized it to zero */ memset(to, 0, sizeof(*to)); if (conn == NULL) diff --git a/src/xen/xend_internal.h b/src/xen/xend_internal.h index c4ed9ba..4a0cd69 100644 --- a/src/xen/xend_internal.h +++ b/src/xen/xend_internal.h @@ -36,7 +36,7 @@ xenDaemonOpen_unix(virConnectPtr conn, const char *path); * \return 0 for success; -1 (with errno) on error * * xen_create() returns after a domain has been allocated including - * its memory. This does not guarentee, though, that the devices + * its memory. This does not guarantee, though, that the devices * have come up properly. For instance, if you create a VBD with an * invalid filename, the error won't occur until after this function * returns. -- 1.7.4.4

1 0

[libvirt] [PATCH] rpc: Pass through DISPLAY so ssh can launch askpass
by Cole Robinson 20 Jul '11

20 Jul '11

Though we prefer users to have SSH keys setup, virt-manager users still depend on remote SSH connections to launch a password dialog. This fixes launch ssh-askpass Fix suggested by danpb --- src/rpc/virnetsocket.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/rpc/virnetsocket.c b/src/rpc/virnetsocket.c index 4403fc4..6605aa3 100644 --- a/src/rpc/virnetsocket.c +++ b/src/rpc/virnetsocket.c @@ -604,6 +604,7 @@ int virNetSocketNewConnectSSH(const char *nodename, virCommandAddEnvPassCommon(cmd); virCommandAddEnvPass(cmd, "SSH_AUTH_SOCK"); virCommandAddEnvPass(cmd, "SSH_ASKPASS"); + virCommandAddEnvPass(cmd, "DISPLAY"); virCommandClearCaps(cmd); if (service) -- 1.7.4.4

3 3

[libvirt] remote driver RPC API usage breaks launching ssh askpass
by Cole Robinson 20 Jul '11

20 Jul '11

This commit broke launching SSH askpass from virt-manager: http://libvirt.org/git/?p=libvirt.git;a=commit;h=c1b226447781ba8367606f760d… Using upstream virt-manager, running python src/virt-manager.py and trying to connect to a remote SSH connection without SSH keys causes a segfault: #0 virNetSocketRead (sock=0xc, buf=0x7f746c006458 "", len=4) at rpc/virnetsocket.c:969 #1 0x00007f7477ea7374 in virNetClientIOReadMessage (client=0x7f746c006400) at rpc/virnetclient.c:712 #2 virNetClientIOHandleInput (client=0x7f746c006400) at rpc/virnetclient.c:731 #3 0x00007f7477ea7ae0 in virNetClientIncomingEvent (sock=0x7f746c002040, events=<value optimized out>, opaque=0x7f746c006400) at rpc/virnetclient.c:1120 #4 0x00007f74782332ce in libvirt_virEventInvokeHandleCallback ( self=<value optimized out>, args=<value optimized out>) at libvirt-override.c:2997 #5 0x0000003075ee965b in call_function (f=<value optimized out>, throwflag=<value optimized out>) at /usr/src/debug/Python-2.7/Python/ceval.c:4071 #6 PyEval_EvalFrameEx (f=<value optimized out>, throwflag=<value optimized out>) at /usr/src/debug/Python-2.7/Python/ceval.c:2721 ... If you apply the following patch to virt-manager: $ cat a diff --git a/src/virt-manager.py.in b/src/virt-manager.py.in index cf0a20e..4d3f1c6 100755 --- a/src/virt-manager.py.in +++ b/src/virt-manager.py.in @@ -357,8 +357,8 @@ def main(): "disabling DBus service") # Hook libvirt events into glib main loop - import virtManager.libvirtglib - virtManager.libvirtglib.register_event_impl() + #import virtManager.libvirtglib + #virtManager.libvirtglib.register_event_impl() # At this point we're either starting a brand new controlling instance, # or the dbus comms to existing instance has failed rerun make, and reproduce the error, libvirt raises an exception from virConnectOpenAuth: libvirtError: Cannot recv data: Permission denied, please try again. Permission denied, please try again. Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password). : Connection reset by peer I haven't poked at it yet, putting it here incase anyone else has ideas. - Cole

2 2

[libvirt] [PATCH] udev: Don't try to dump DMI on non-intel archs
by Michal Privoznik 20 Jul '11

20 Jul '11

DMI is Intel & Intel-compatible specific. Don't try to dump information on non-compatible architectures, which results only in error message in logs. --- NB: libsmbios is exclusively for x86_64 ia64 %{ix86} src/node_device/node_device_udev.c | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/src/node_device/node_device_udev.c b/src/node_device/node_device_udev.c index a6b5b2e..2c5d016 100644 --- a/src/node_device/node_device_udev.c +++ b/src/node_device/node_device_udev.c @@ -1477,6 +1477,8 @@ out: } +/* DMI is intel-compatible specific */ +#if defined(__x86_64__) || defined(__i386__) || defined(__amd64__) static void udevGetDMIData(union _virNodeDevCapData *data) { @@ -1549,6 +1551,7 @@ out: } return; } +#endif static int udevSetupSystemDev(void) @@ -1573,7 +1576,9 @@ static int udevSetupSystemDev(void) goto out; } +#if defined(__x86_64__) || defined(__i386__) || defined(__amd64__) udevGetDMIData(&def->caps->data); +#endif dev = virNodeDeviceAssignDef(&driverState->devs, def); if (dev == NULL) { -- 1.7.5.rc3

2 10

[libvirt] RFC New virDomainBlockPull API family to libvirt
by Adam Litke 20 Jul '11

20 Jul '11

Unfortunately, after committing the blockPull API to libvirt, the qemu community decided to change the API somewhat and we needed to revert the libvirt implementation. Now that the qemu API is settling out again, I would like to propose an updated libvirt public API which has required only a minor set of changes to sync back up to the qemu API. Summary of changes: - Qemu dropped incremental streaming so remove libvirt incremental BlockPull() API - Rename virDomainBlockPullAll() to virDomainBlockPull() - Changes required to qemu monitor handlers for changed command names Currently, qemu block device streaming completely flattens a disk image's backing file chain. Consider the following chain: A->B->C where C is a leaf image that is backed by B and B is backed by A. The current disk streaming command will produce an independent image C with no backing file. Future versions of qemu block streaming may support an option to specify a new base image from the current chain. For example: stream --backing_file B C would pull all blocks that are only in A to produce the chain: B->C (thus eliminating a dependency on A but maintaining B as a backing image. Do we want to create room in the BlockPull API to support this advanced usage in the future? If so, then a new parameter must be added to BlockPull: const char *backing_path. Even if we extend the API in this manner, the initial implementation will not support it because qemu will not support it immediately, and libvirt is missing core functionality to support it (no public enumeration of the disk backing file chain). Thoughts? -- To help speed the provisioning process for large domains, new QED disks are created with backing to a template image. These disks are configured with copy on read such that blocks that are read from the backing file are copied to the new disk. This reduces I/O over a potentially costly path to the backing image. In such a configuration, there is a desire to remove the dependency on the backing image as the domain runs. To accomplish this, qemu will provide an interface to perform sequential copy on read operations during normal VM operation. Once all data has been copied, the disk image's link to the backing file is removed. The virDomainBlockPull API family brings this functionality to libvirt. virDomainBlockPull() instructs the hypervisor to stream the entire device in the background. Progress of this operation can be checked with the function virDomainBlockPullInfo(). An ongoing stream can be cancelled with virDomainBlockPullAbort(). An event (VIR_DOMAIN_EVENT_ID_BLOCK_PULL) will be emitted when a disk has been fully populated or if a BlockPull() operation was terminated due to an error. This event is useful to avoid polling on virDomainBlockPullInfo() for completion and could also be used by the security driver to revoke access to the backing file when it is no longer needed. /* * BlockPull API */ /* An iterator for initiating and monitoring block pull operations */ typedef unsigned long long virDomainBlockPullCursor; typedef struct _virDomainBlockPullInfo virDomainBlockPullInfo; struct _virDomainBlockPullInfo { /* * The following fields provide an indication of block pull progress. @cur * indicates the current position and will be between 0 and @end. @end is * the final cursor position for this operation and represents completion. * To approximate progress, divide @cur by @end. */ virDomainBlockPullCursor cur; virDomainBlockPullCursor end; }; typedef virDomainBlockPullInfo *virDomainBlockPullInfoPtr; /** * virDomainBlockPull: * @dom: pointer to domain object * @path: Fully-qualified filename of disk * @flags: currently unused, for future extension * * Populate a disk image with data from its backing image. Once all data from * its backing image has been pulled, the disk no longer depends on a backing * image. This function pulls data for the entire device in the background. * Progress of the operation can be checked with virDomainGetBlockPullInfo() and * the operation can be aborted with virDomainBlockPullAbort(). When finished, * an asynchronous event is raised to indicate the final status. * * Returns 0 if the operation has started, -1 on failure. */ int virDomainBlockPull(virDomainPtr dom, const char *path, unsigned int flags); /** * virDomainBlockPullAbort: * @dom: pointer to domain object * @path: fully-qualified filename of disk * @flags: currently unused, for future extension * * Cancel a pull operation previously started by virDomainBlockPullAll(). * * Returns -1 in case of failure, 0 when successful. */ int virDomainBlockPullAbort(virDomainPtr dom, const char *path, unsigned int flags); /** * virDomainGetBlockPullInfo: * @dom: pointer to domain object * @path: fully-qualified filename of disk * @info: pointer to a virDomainBlockPullInfo structure * @flags: currently unused, for future extension * * Request progress information on a block pull operation that has been started * with virDomainBlockPull(). If an operation is active for the given * parameters, @info will be updated with the current progress. * * Returns -1 in case of failure, 0 when successful. */ int virDomainGetBlockPullInfo(virDomainPtr dom, const char *path, virDomainBlockPullInfoPtr info, unsigned int flags); /** * virConnectDomainEventBlockPullStatus: * * The final status of a virDomainBlockPull() operation */ typedef enum { VIR_DOMAIN_BLOCK_PULL_COMPLETED = 0, VIR_DOMAIN_BLOCK_PULL_FAILED = 1, } virConnectDomainEventBlockPullStatus; /** * virConnectDomainEventBlockPullCallback: * @conn: connection object * @dom: domain on which the event occurred * @path: fully-qualified filename of the affected disk * @status: final status of the operation (virConnectDomainEventBlockPullStatus * * The callback signature to use when registering for an event of type * VIR_DOMAIN_EVENT_ID_BLOCK_PULL with virConnectDomainEventRegisterAny() */ typedef void (*virConnectDomainEventBlockPullCallback)(virConnectPtr conn, virDomainPtr dom, const char *path, int status, void *opaque); -- Adam Litke IBM Linux Technology Center

5 21

[libvirt] [PATCH 0/3] Fixes to key usage/purpose checking
by Daniel P. Berrange 20 Jul '11

20 Jul '11

We were not correctly checking key usage/purpose as per RFC recommendations. We should have been treated unavailable info as a non-fatal condition, and should have honoured the criticality field

2 6

Re: [libvirt] Build libvirt 0.9.3 failed
by zhang xintao 20 Jul '11

20 Jul '11

config.log 38094 configure:54859:checking for LIBNL 38995 configure:54924:result: no 38096 configure:54924:error: libnl-devel >= 1.1 is required for macvtap support I try to build libvirt 0.9.3 -without macvtap support but failed same error message. can you help me ? On Wed, Jul 20, 2011 at 2:02 PM, zhang xintao <zhang.kvm(a)gmail.com> wrote: > This is th config.log > > I try to build libvirt 0.9.3 -without macvtap support but failed > > same error message. > > can you help me ? > > On Wed, Jul 20, 2011 at 12:52 PM, Eric Blake <eblake(a)redhat.com> wrote: >> On 07/19/2011 10:42 PM, zhang xintao wrote: >>> >>> I try to build libvirt 0.9.3 but failed >>> ========================== >>> Host OS：Ubuntu server 11.04 >>> ========================== >>> configure:error libnl-devel>= 1.1 is required for macvtap support >>> >>> libnl-dev 1.1-6 is already installed >>> >>> who can help me? >> >> What does config.log say in the areas where it was checking for libnl >> support? Meanwhile, are you okay building without macvtap support? >> >> -- >> Eric Blake eblake(a)redhat.com +1-801-349-2682 >> Libvirt virtualization library http://libvirt.org >> >

2 1

[libvirt] [PATCH] Should determine the value of client first before locking it
by Guannan Ren 20 Jul '11

20 Jul '11

--- src/rpc/virnetclient.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/src/rpc/virnetclient.c b/src/rpc/virnetclient.c index dfc4ed9..c100ef1 100644 --- a/src/rpc/virnetclient.c +++ b/src/rpc/virnetclient.c @@ -271,6 +271,9 @@ void virNetClientFree(virNetClientPtr client) void virNetClientClose(virNetClientPtr client) { + if (!client) + return; + virNetClientLock(client); virNetSocketRemoveIOCallback(client->sock); virNetSocketFree(client->sock); -- 1.7.1

2 1

[libvirt] [PATCH] virsh: add custom readline generator
by Lai Jiangshan 20 Jul '11

20 Jul '11

Custom readline generator will help for some usecase. Also add a custom readline generator for the "help" command. Signed-off-by: Lai Jiangshan <laijs(a)cn.fujitsu.com> --- diff --git a/tools/virsh.c b/tools/virsh.c index fcd254d..51e43c1 100644 --- a/tools/virsh.c +++ b/tools/virsh.c @@ -13575,7 +13575,7 @@ vshCloseLogFile(vshControl *ctl) * (i.e. STATE == 0), then we start at the top of the list. */ static char * -vshReadlineCommandGenerator(const char *text, int state) +vshReadlineCmdAndGrpGenerator(const char *text, int state, int grpname) { static int grp_list_index, cmd_list_index, len; const char *name; @@ -13604,8 +13604,13 @@ vshReadlineCommandGenerator(const char *text, int state) return vshStrdup(NULL, name); } } else { + name = grp[grp_list_index].keyword; cmd_list_index = 0; grp_list_index++; + + if (grpname && STREQLEN(name, text, len)) + return vshStrdup(NULL, name); + } } @@ -13614,10 +13619,45 @@ vshReadlineCommandGenerator(const char *text, int state) } static char * +vshReadlineCommandGenerator(const char *text, int state) +{ + return vshReadlineCmdAndGrpGenerator(text, state, 0); +} + +static char * +vshReadlineHelpOptionGenerator(const char *text, int state) +{ + return vshReadlineCmdAndGrpGenerator(text, state, 1); +} + +struct vshCustomReadLine { + const char *name; + char *(*CustomReadLineOptionGenerator)(const char *text, int state); +}; + +struct vshCustomReadLine customeReadLine[] = { + { "help", vshReadlineHelpOptionGenerator }, + { NULL, NULL } +}; + +static struct vshCustomReadLine *vshCustomReadLineSearch(const char *name) +{ + struct vshCustomReadLine *ret = customeReadLine; + + for (ret = customeReadLine; ret->name; ret++) { + if (STREQ(ret->name, name)) + return ret; + } + + return NULL; +} + +static char * vshReadlineOptionsGenerator(const char *text, int state) { static int list_index, len; static const vshCmdDef *cmd = NULL; + static const struct vshCustomReadLine *rl = NULL; const char *name; if (!state) { @@ -13632,6 +13672,7 @@ vshReadlineOptionsGenerator(const char *text, int state) memcpy(cmdname, rl_line_buffer, p - rl_line_buffer); cmd = vshCmddefSearch(cmdname); + rl = vshCustomReadLineSearch(cmdname); list_index = 0; len = strlen(text); VIR_FREE(cmdname); @@ -13640,6 +13681,9 @@ vshReadlineOptionsGenerator(const char *text, int state) if (!cmd) return NULL; + if (rl) + return rl->CustomReadLineOptionGenerator(text, state); + if (!cmd->opts) return NULL;

3 6

[libvirt] [PATCH RFC v3 0/6] support cpu bandwidth in libvirt
by Wen Congyang 20 Jul '11

20 Jul '11

TODO: 1. We create sub directory for each vcpu in cpu subsystem. So we should recalculate cpu.shares for each vcpu. Changelog: v3: fix some small bugs implement the simple way v2: almost rewrite the patchset to support to control each vcpu's bandwidth. Limit quota to [-1, 2^64/1000] at the schemas level. We will check it at cgroup level. Wen Congyang (6): Introduce the function virCgroupForVcpu cgroup: Implement cpu.cfs_period_us and cpu.cfs_quota_us tuning API Update XML Schema for new entries qemu: Implement period and quota tunable XML configuration and parsing qemu: Implement cfs_period and cfs_quota's modification doc: Add documentation for new cputune elements period and quota docs/formatdomain.html.in | 19 ++ docs/schemas/domain.rng | 26 +++- src/conf/domain_conf.c | 20 ++- src/conf/domain_conf.h | 2 + src/libvirt_private.syms | 5 + src/qemu/qemu_cgroup.c | 127 +++++++++++ src/qemu/qemu_cgroup.h | 4 + src/qemu/qemu_driver.c | 259 ++++++++++++++++++++--- src/qemu/qemu_process.c | 4 + src/util/cgroup.c | 153 +++++++++++++- src/util/cgroup.h | 11 + tests/qemuxml2argvdata/qemuxml2argv-cputune.xml | 2 + 12 files changed, 596 insertions(+), 36 deletions(-)

3 22

[libvirt] [PATCH 00/10] network: physical device abstraction aka 'virtual switch'
by Laine Stump 20 Jul '11

20 Jul '11

This patch is in response to the following bug reports: https://bugzilla.redhat.com/show_bug.cgi?id=643947 (RHEL) https://bugzilla.redhat.com/show_bug.cgi?id=636106 (upstream) It is functionally complete, and has gone through rudimentary testing for bridge networks (host bridge) and direct networks in bridge mode (macvtap). The patch series doesn't yet include updates to the domain and network XML documentation, though, so it isn't ready to push. I am sending it now to get feedback, both on the specifics of the code, as well as on how it is designed and how it works. I will be transferring info from my design document (at the end of this message) into the libvirt doc files during this week, and will have them ready for the V2 of the series that is sure to be requested. ***************** (The working design document) Network device abstraction aka virtual switch - V4 ================================================== The <interface> element of a guest's domain config in libvirt has a <source> element that describes what resources on a host will be used to connect the guest's network interface to the rest of the world. This is very flexible, allowing several different types of connection (virtual network, host bridge, direct macvtap connection to physical interface, qemu usermode, user-defined via an external script), but currently has the problem that unnecessary details of the host resources are embedded into the guest's config; if the guest is migrated to a different host, and that host has a different hardware or network config (or possibly the same hardware, but that hardware is currently in use by a different guest), the migration will fail. This document outlines a change to libvirt's network XML that will allow us to (optionally - old configs will remain valid) remove the host details from the guest's domain XML (which can move around from host to host) and place them in the network XML (which remains with a single host); the domain XML will then use existing config elements to associate each guest interface with a "network". The motivating use case for this change is the "direct" connection type (which uses macvtap for vepa and vnlink connections directly between a guest and a physical interface, rather than through a bridge), but it is applicable for all types of connection. (Another hopeful side effect of this change will be to make libvirt's network connection model easier to realize on non-Linux hypervisors (eg, VMWare ESX) and for other network technologies, such as openvswitch, VDE, and various VPN implementations). Background ========== (parts lifted from Dan Berrange's mail on this subject) Currently <network> supports 3 connectivity modes - Non-routed network, separate subnet (no <forward> element present) - Routed network, separate subnet with NAT (<forward mode='nat'/>) - Routed network, separate subnet (<forward mode='route'/>) Each of these is implemented in the existing network driver by creating a bridge device using brctl, and connecting the guest network interfaces via tap devices (a detail which, now that I've stated it, you should promptly forget!). All traffic between that bridge and the outside network is done via the host's IP routing stack (ie, there is no physical device directly connected to the bridge) In the future, these two additional routed modes might be useful: - Routed network, IP subnetting - Routed network, separate subnet with VPN The core goal of this proposal, though, is to replace type=bridge and type=direct from the domain interface XML with new types of <network> definitions so that the domain can just give "type='network'" and have all the necessary details filled in at runtime. This basically means we're adding several bridging modes (the submodes of "direct" have been flattened out here): - Bridged network, eth + bridge + tap - Bridged network, eth + macvtap + vepa - Bridged network, eth + macvtap + private - Bridged network, eth + macvtap + passthrough - Bridged network, eth + macvtap + bridge Another "future expansion" could be to add: - Bridged network, with VPN Likewise, support for other technologies, such as openvswitch and VDE would each be another entry on this list. (Dan also listed each of the above "+sriov" separately, but that ends up being handled in an orthogonal manner (by just specifying a pool of interfaces for a single network), so I'm only giving the abbreviated list) I. Changes to domain <interface> element ======================================== In many cases, the <interface> element of the domain XML will be identical to what is used now when connecting the interface to a libvirt-style virtual network: <interface type='network'> <source network='red-network'/> <mac address='xx:xx:xx:xx:xx:xx'/> </interface> Depending on the definition of the network "red-network" on the host the guest was started on / migrated to, this could be either a direct (macvtap) connection using one of the various direct modes (vepa/private/bridge/passthrough), a bridge (again, pointed to by the definition of 'red-network'), or a virtual network (using the current network definition syntax). This way the same guest could be migrated not only between macvtap-enabled hosts, but from there to a host using a bridge, or maybe a host in a remote location that used a virtual network with a secure tunnel to connect back to the rest of the red-network. (Part of the migration process would of course check that the destination host had a network of the proper name with adequate available resources, and fail if it didn't; management software at a level above libvirt would probably filter a list of candidate migration destinations based on available networks and any various details of those networks (eg. it could search for only networks using vepa for the connection), and only attempt migration to one that had the matching network available). <virtualport> element of <interface> ------------------------------------ Since mamy of the attributes/sub-elements of <virtualport> (used by some modes of "direct" interface connections) are identical for all interfaces connecting to any given switch, most of the information in <virtualport> will be optional in the domain's interface definition - it can be filled in from a similar <virtualport> element that will be added to the <network> definition. Some parameters in <virtualport> ("instanceid", for example) must be unique for every interface, though, so those will still be specified in the <interface> XML. The two <virtualport> elements will be OR'ed at runtime to arrive at the actual set of parameters that are used. (Open Question: What should be the policy when a parameter is specified in both places? Should one take precedence? Or should it be considered an error?) portgroup attribute of <source> ------------------------------- The <source> element of an interface definition will be able to optionally specify a "portgroup" attribute. If portgroup is *NOT* given, the default portgroup of the network will be used (if a default is defined, otherwise no portgroup will be used). If portgroup *IS* specified, the source network must have a portgroup by that name (or the domain startup/migration will fail), and the attributes of that portgroup will be used for the connection. Here is an example <interface> definition that has both a reduced <virtualport> element, as well as a portgroup attribute: <interface type='network'> <source network='red-network' portgroup='engineering'/> <virtualport type="802.1Qbg"> <parameters managerid="11" typeid="1193047" typeidversion="2" instanceid="09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f"/> </virtualport> <mac address='de:ad:be:ef:ca:fe'/> </interface> (The specifics of what can be in a portgroup are given below) storing the actual chosen/running config in state dir ----------------------------------------------------- Note: the following additions to the XML will only ever be visible in the statedir copy of the domain config, which is used to keep track of the state of running domains in case libvirtd is restarted while domains are still running. The described element cannot be used in a user-generated config file, and will never be present in a domain interface config produced by the libvirt public API, nor by "virsh dumpxml". In order to remind libvirt about which interfaces are actually in use in the event that libvirtd is restarted while domains are still running, the copy of the domain XML stored in "statedir" (/var/lib/libvirt/qemu/*.xml) may have an extra element <actual> stored as a subelement of each <interface>: <interface type='network'> <source network='red-network' portgroup='engineering'/> <virtualport type="802.1Qbg"> <parameters managerid="11" typeid="1193047" typeidversion="2" instanceid="09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f"/> </virtualport> <mac address='de:ad:be:ef:ca:fe'/> <actual type='direct'> <source dev='eth1' mode='vepa'/> </actual> </interface> In short, merging the <auto> element up into <interface> will yield the full interface as it was actually instantiated for the domain. In this case, the interface still has a mac address of de:ad:be:ef:ca:fe, and will use the same <virtualport> parameters, but the actual type of the interface will be 'direct' (so macvtap will be used to connect the interface), and the connection will be via physical device eth1 in vepa mode. network II. Changes to <network> definition =================================== As Dan has pointed out, any additions to <network> must be designed so that existing management applications (written to understand <network> prior to these new additions) will at least recognize that the XML they've been given is for something new that they don't fully understand. At the same time, the new types of network definition should attempt to re-use as much of the existing elements/attributes as possible, both to make it easier to extend these applications, as well as to make the status displays of un-updated applications make as much sense as possible. The new types of network will be specified by extending the choices for <forward mode='....'>. The current modes are: <forward mode='route|nat'/> (in addition to not listing any mode, which equates to "isolated") Here are suggested new modes: <forward mode='bridge|vepa|private|passthrough'/> A description of each: bridge - equivalent to "<interface type='bridge'>" in the interface definition. The bridge device to use would be given in the existing <bridge name='xxx'>. or <interface type='direct'> ... <source mode='bridge'/> (ie, macvtap bridge mode) with the physical interface name given in <forward dev='xxx'> or from the pool of devices given as subelements of <forward> (see below) vepa - same as "<interface type='direct'>..." with <source mode='vepa'/> private - <interface type='direct'> ... <source mode='private'/> passthrough - <interface type='direct'> ... <source mode='passthrough'/> Interface Pools --------------- In many cases, a single host network may have multiple physical network devices associated with it (especially in the case of an SRIOV-capable ethernet card, which will have several "virtual functions" associated with a single physical ethernet connection). The host will at least want to balance the load of multiple guests between these multiple devices, and may even require (in the case of passthrough mode, for example) that only a single guest interface be attached to each host device. The current specification for <forward> only allows for a single "dev" attribute, though. In order to support multiple device names, we will extend <forward> to allow 0 or more <interface> subelements: <forward mode='vepa'> <interface dev='eth10'/> <interface dev='eth11'/> <interface dev='eth12'/> <interface dev='eth13'/> </forward> Note that, as a convenience, *on output* the first of these elements will always be a duplicate of the "dev" attribute in <forward> itself. When sending XML definnitions to libvirt, either a single interface should be send in <forward>, or a pool of them as sub-elements, but not both (if you do this, and the first in the pool matches the one given in <forward>, it will be ignored, but if they don't match, that is an error). In the case of mode='passthrough' (as well as mode='private' if the virtPortProfile has a mode setting of 802.1Qbh), only one guest interface can be connected to a device at a time. libvirt will keep track of which devices are in use, and attempt to assign a free device; failure to assign a device will result in a failure of the domain to start/migrate. For the other direct modes, libvirt will simply keep track of the number of guest interfaces currently using each device, and attempt to keep them balanced. Portgroups ----------- A <portgroup> (subelement of <network>) is just a way of easily putting connections to the network into different classes, with each class having a different level/type of service. Each <network> can have multiple <portgroup> elements, and each <portgroup> has a name, as well as various attributes associated with it. If an interface definition specifies a portgroup, that portgroup's info will be used to modify the interface's setup. If no portgroup is given and one of the network's portgroups has "default='yes'", that default portgroup will be used. If no portgroup is given in the interface definition, and there is no default portgroup, then none will be used. The first thing we will use portgroups for is as an alternate place to specify <virtualport> parameters: <portgroup name='engineering' default='yes'> <virtualport type="802.1Qbg"> <parameters managerid="11" typeid="1193047" typeidversion="2"/> </virtualport> </portgroup> Anything that is valid in an interface's <virtualport> is also valid here. The next thing to specify in a portgroup will be bandwidth limiting / QoS configuration. Since I don't know exactly what's needed for that, I won't specify it here. If anything is specified both directly under <network> and in a <portgroup>, the value in portgroup will take precedence. (Again - what will the precedence of items specified in the <interface> be?) EXAMPLES -------- Examples of 'red-network' for different types of connections (all of these would work with minor variations of the interface XML given above, eg the 'vepa' version would require <virtualport> in the interface that specified an instanceid, and if the <interface> specified a portgroup, it would need to also be in the <network> definition (even if it was empty aside from name).  <network> <name>red-network</name> <bridge name='virbr0'/> <forward mode='route'/> ... </network>  <network> <name>red-network</name> <forward mode='bridge'/> <bridge name='eth0'/> </network>  <network> <name>red-network</name> <forward mode='vepa' dev='eth10'/> <virtualport type='802.1Qbg'> <parameters managerid='11' typeid='1193047' typeidversion='2'/> </virtualport>   <portgroup name='accounting'> <virtualport> <parameters typeid='22'/> </virtualport> </portgroup> <portgroup name='engineering'> <virtualport> <parameters typeid='33'/> </virtualport> </portgroup> </network>  <network> <name>red-network</name> <forward mode='passthrough'> <interface dev='eth10'/> <interface dev='eth11'/> <interface dev='eth12'/> <interface dev='eth13'/> <interface dev='eth14'/> <interface dev='eth15'/> <interface dev='eth16'/> <interface dev='eth17'/> </forward> </network> ============= Keeping Track of Interface Usage by Guests ========================================== While libvirtd is running, each physical interface in a network's pool will maintain a count of how many guest interfaces are using that physical interface. Each guest interface will also maintain information about which network, and which physical interface on that network, it is using. The following situations could occur: 1) A guest is terminated while libvirtd is running. libvirtd will notice this, and decrement the usage count for each interface used by the guest, as maintained in the guest's state info. 2) The host system is rebooted When the libvirt network driver is restarted, no guests will yet be running, so the usage count of each physical interface will be 0, and get incremented as guests are started up. 3) libvirtd is restarted When the network is restarted, the usage count for all physical interfaces will be set to 0, just as if the entire system had been rebooted. One of two situations might be encountered: 3a) The guest is still running when libvirtd is restarted. In this case, the existing state information of the guest will be examined to determine which physical interface usage count to increment. 3b) The guest has been terminated while libvirtd wasn't present. Since the guest is no longer running, its state information will be thrown away.

3 43