October 2013 - Devel - libvirt List Archives

[libvirt] [PATCH] Add some notes about secure usage of libvirt
by Daniel P. Berrange 15 Oct '13

15 Oct '13

From: "Daniel P. Berrange" <berrange(a)redhat.com> Start a page describing some of the things that applications using libvirt need to bear in mind to ensure security of their systems. Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- docs/secureusage.html.in | 169 +++++++++++++++++++++++++++++++++++++++++++++++ docs/sitemap.html.in | 4 ++ 2 files changed, 173 insertions(+) create mode 100644 docs/secureusage.html.in diff --git a/docs/secureusage.html.in b/docs/secureusage.html.in new file mode 100644 index 0000000..998a692 --- /dev/null +++ b/docs/secureusage.html.in @@ -0,0 +1,169 @@ +<?xml version="1.0" encoding="UTF-8"?> +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> +<html xmlns="http://www.w3.org/1999/xhtml"> + <body> + + <h1>Secure Usage of Libvirt</h1> + + <ul id="toc"></ul> + + <p> + This page details information that application developers and + administrators of libvirt should be aware of when working with + libvirt, that may have a bearing on security of the system. + </p> + + + <h2><a name="diskimage">Disk image handling</a></h2> + + <h3><a name="diskimageformat">Disk image format probing</a></h3> + + <p> + Historically there have been multiple flaws in QEMU and most + projects using QEMUs, related to handling of disk formats. + The problems occur when a guest is given a virtual disk backed + by raw disk format on the host. If the management application + on the host tries to auto-detect / probe the disk format, it + is vulnerable to a malicious guest which can write a qcow2 + file header into its raw disk. If the management application + subsequently probes the disk, it will see it as a 'qcow2' disk + instead of a 'raw' disk. Since 'qcow2' disks can have a copy + on write backing file, such flaw can be leveraged to read + arbitrary files on the host. The same type of flaw may occur + if the management application allows users to upload pre-created + raw images + </p> + + <p> + <strong>Recommendation:</strong> never attempt to automatically + detect the format of a disk image based on file contents which + are accessible to / originate from an untrusted source. + </p> + + <h3><a name="diskimagebacking">Disk image backing files</a></h3> + + <p> + If a management application allows users to upload pre-created + disk images in non-raw formats, it can be tricked into giving + the user access to arbitrary host files via the copy-on-write + backing file feature. This is because the qcow2 disk format + header contains a filename field which can point to any location. + It can also point to network protocols such as NBD, HTTP, GlusterFS, + RBD and more. This could allow for compromise of almost arbitrary + data accessible on the LAN/WAN. + </p> + + <p> + <strong>Recommendation:</strong> always validate that a disk + image originating from an untrusted source has no backing + file set. If a backing file is seen, reject the image. + </p> + + <h3><a name="diskimagesize">Disk image size validation</a></h3> + + <p> + If an application allows users to upload pre-created disk + images in non-raw formats, it is essential to validate the + logical disk image size, rather than the physical disk + image size. Non-raw disk images have a grow-on-demand + capability, so a user can provide a qcow2 image that may + be only 1 MB in size, but is configured to grow to many + TB in size. + </p> + + <p> + <strong>Recommendation:</strong> if receiving a non-raw disk + image from an untrusted source, validate the logical image + size stored in the disk image metadata against some finite + limit. + </p> + + <h3><a name="diskimageaccess">Disk image data access</a></h3> + + <p> + If an untrusted disk image is ever mounted on the host OS by + a management application or administrator, this opens an + avenue of attacker with which to potentially compromise the + host kernel. Filesystem drivers in OS kernels are often very + complex code and thus may have bugs lurking in them. With + Linux, there are a large number of filesystem drivers, many + of which attract little security analysis attention. Linux + will helpfull probe filesystem formats if not told to use an + explicit format, allowing an attacker the ability to target + specific weak filesystem drivers. Even commonly used and + widely audited filesystems such as <code>ext4</code> have had + <a href="https://lwn.net/Articles/538898/">bugs lurking in them</a> + undetected for years at a time. + </p> + + <p> + <strong>Recommendation:</strong> if there is a need to access + the content of a disk image, use a single-use throwaway virtual + machine to access the data. Never mount disk images on the host + OS. Ideally make use of the <a href="http://libguestfs.org">libguestfs</a> + tools and APIs for accessing disks + </p> + + <h2><a name="migration">Guest migration network</a></h2> + + <p> + Most hypervisors with support for guest migration between hosts + make use of one (or more) network connections. Typically the source + host will connect to some port on the target host to initiate the + migration. There may be separate connections for co-ordinating the + migration, transferring memory state and transferring storage. + If the network over which migration takes place is accessible the + guest, or client applications, there is potential for data leakage + via packet snooping/capture. It is also possible for a malicious + guest or client to make attempts to connect to the target host + to trigger bogus migration operations, or at least inflict a denial + of service attack. + </p> + + <p> + <strong>Recommendations:</strong> there are several things to consider + when performing migration + </p> + + <ul> + <li>Use a specific address for establishing the migration + connection which is accessible only to the virtualization + hosts themselves, not libvirt clients or virtual guests. + Most hypervisors allow the mgmt application to provide + the IP address of the target host as a way to + determine which network migration takes place on</li> + <li>Use an encrypted migration protocol. Some hypervisors + have support for encrypting the migration memory/storage + data. In other cases it can be tunnelled over the libvirtd + RPC protocol connections.</li> + <li>Use a specific address for listening for incoming migration + connections which is accessible only to the virtualization + hosts themselves, not libvirt clients or virtual guests. + Most hypervisors allow the mgmt application to configure + the IP address on which the target host listens.</li> + </ul> + + <h2><a name="storage">Storage encryption</a></h2> + + <p> + Virtual disk images will typically contain confidential data + belonging to the owner of the virtual machine. It is desirable + to protect this against data center administrators as much as + possible. For example, a rogue storage administrator may attempt + to access disk contents directly from a storage host, or a network + administrator/attack may attempt to snoop on data packets relating + to storage access. Use of disk encryption on the virtualization + host can ensure that only the virtualization host administrator + can see the plain text contents of disk images. + </p> + + <p> + <strong>Recommendation:</strong> make use of storage encryption + to protect non-local storage from attack by rogue network / + storage administrators or external attackers. This is particularly + important if the storage protocol itself does not offer any kind + of encryption capabilities. + </p> + + </body> +</html> diff --git a/docs/sitemap.html.in b/docs/sitemap.html.in index a8d2177..d821a9e 100644 --- a/docs/sitemap.html.in +++ b/docs/sitemap.html.in @@ -136,6 +136,10 @@ <a href="archnode.html">Node Devices</a> <span>Enumerating host node devices</span> </li> + <li> + <a href="secureusage.html">Secure usage</a> + <span>Secure usage of the libvirt APIs</span> + </li> </ul> </li> <li> -- 1.8.3.1

2 2

[libvirt] [PATCH] virsh: move command cpu-baseline from domain group to host group.
by liyang 15 Oct '13

15 Oct '13

cpu-baseline command can compute baseline CPU for a set of given CPUs, I think it should not belong to domain group, but now it belongs to host group, so I moved the related source from virsh-domain.c to virsh-host.c Signed-off-by: Li Yang <liyang.fnst(a)cn.fujitsu.com> --- tools/virsh-domain.c | 116 ------------------------------------------------- tools/virsh-host.c | 117 ++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 117 insertions(+), 116 deletions(-) diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c index 42c9920..8fc6c59 100644 --- a/tools/virsh-domain.c +++ b/tools/virsh-domain.c @@ -6107,116 +6107,6 @@ cleanup: } /* - * "cpu-baseline" command - */ -static const vshCmdInfo info_cpu_baseline[] = { - {.name = "help", - .data = N_("compute baseline CPU") - }, - {.name = "desc", - .data = N_("Compute baseline CPU for a set of given CPUs.") - }, - {.name = NULL} -}; - -static const vshCmdOptDef opts_cpu_baseline[] = { - {.name = "file", - .type = VSH_OT_DATA, - .flags = VSH_OFLAG_REQ, - .help = N_("file containing XML CPU descriptions") - }, - {.name = "features", - .type = VSH_OT_BOOL, - .help = N_("Show features that are part of the CPU model type") - }, - {.name = NULL} -}; - -static bool -cmdCPUBaseline(vshControl *ctl, const vshCmd *cmd) -{ - const char *from = NULL; - bool ret = false; - char *buffer; - char *result = NULL; - char **list = NULL; - unsigned int flags = 0; - int count = 0; - - xmlDocPtr xml = NULL; - xmlNodePtr *node_list = NULL; - xmlXPathContextPtr ctxt = NULL; - virBuffer buf = VIR_BUFFER_INITIALIZER; - size_t i; - - if (vshCommandOptBool(cmd, "features")) - flags |= VIR_CONNECT_BASELINE_CPU_EXPAND_FEATURES; - - if (vshCommandOptStringReq(ctl, cmd, "file", &from) < 0) - return false; - - if (virFileReadAll(from, VSH_MAX_XML_FILE, &buffer) < 0) - return false; - - /* add a separate container around the xml */ - virBufferStrcat(&buf, "<container>", buffer, "</container>", NULL); - if (virBufferError(&buf)) - goto no_memory; - - VIR_FREE(buffer); - buffer = virBufferContentAndReset(&buf); - - - if (!(xml = virXMLParseStringCtxt(buffer, from, &ctxt))) - goto cleanup; - - if ((count = virXPathNodeSet("//cpu[not(ancestor::cpus)]", - ctxt, &node_list)) == -1) - goto cleanup; - - if (count == 0) { - vshError(ctl, _("No host CPU specified in '%s'"), from); - goto cleanup; - } - - list = vshCalloc(ctl, count, sizeof(const char *)); - - for (i = 0; i < count; i++) { - if (!(list[i] = virXMLNodeToString(xml, node_list[i]))) { - vshSaveLibvirtError(); - goto cleanup; - } - } - - result = virConnectBaselineCPU(ctl->conn, - (const char **)list, count, flags); - - if (result) { - vshPrint(ctl, "%s", result); - ret = true; - } - -cleanup: - xmlXPathFreeContext(ctxt); - xmlFreeDoc(xml); - VIR_FREE(result); - if (list != NULL && count > 0) { - for (i = 0; i < count; i++) - VIR_FREE(list[i]); - } - VIR_FREE(list); - VIR_FREE(buffer); - VIR_FREE(node_list); - - return ret; - -no_memory: - vshError(ctl, "%s", _("Out of memory")); - ret = false; - goto cleanup; -} - -/* * "cpu-stats" command */ static const vshCmdInfo info_cpu_stats[] = { @@ -10517,12 +10407,6 @@ const vshCmdDef domManagementCmds[] = { .flags = 0 }, #endif - {.name = "cpu-baseline", - .handler = cmdCPUBaseline, - .opts = opts_cpu_baseline, - .info = info_cpu_baseline, - .flags = 0 - }, {.name = "cpu-compare", .handler = cmdCPUCompare, .opts = opts_cpu_compare, diff --git a/tools/virsh-host.c b/tools/virsh-host.c index 1d1bb97..b69de7c 100644 --- a/tools/virsh-host.c +++ b/tools/virsh-host.c @@ -35,6 +35,7 @@ #include "virbuffer.h" #include "viralloc.h" #include "virsh-domain.h" +#include "virfile.h" #include "virxml.h" #include "virtypedparam.h" #include "virstring.h" @@ -193,6 +194,116 @@ cleanup: } /* + * "cpu-baseline" command + */ +static const vshCmdInfo info_cpu_baseline[] = { + {.name = "help", + .data = N_("compute baseline CPU") + }, + {.name = "desc", + .data = N_("Compute baseline CPU for a set of given CPUs.") + }, + {.name = NULL} +}; + +static const vshCmdOptDef opts_cpu_baseline[] = { + {.name = "file", + .type = VSH_OT_DATA, + .flags = VSH_OFLAG_REQ, + .help = N_("file containing XML CPU descriptions") + }, + {.name = "features", + .type = VSH_OT_BOOL, + .help = N_("Show features that are part of the CPU model type") + }, + {.name = NULL} +}; + +static bool +cmdCPUBaseline(vshControl *ctl, const vshCmd *cmd) +{ + const char *from = NULL; + bool ret = false; + char *buffer; + char *result = NULL; + char **list = NULL; + unsigned int flags = 0; + int count = 0; + + xmlDocPtr xml = NULL; + xmlNodePtr *node_list = NULL; + xmlXPathContextPtr ctxt = NULL; + virBuffer buf = VIR_BUFFER_INITIALIZER; + size_t i; + + if (vshCommandOptBool(cmd, "features")) + flags |= VIR_CONNECT_BASELINE_CPU_EXPAND_FEATURES; + + if (vshCommandOptStringReq(ctl, cmd, "file", &from) < 0) + return false; + + if (virFileReadAll(from, VSH_MAX_XML_FILE, &buffer) < 0) + return false; + + /* add a separate container around the xml */ + virBufferStrcat(&buf, "<container>", buffer, "</container>", NULL); + if (virBufferError(&buf)) + goto no_memory; + + VIR_FREE(buffer); + buffer = virBufferContentAndReset(&buf); + + + if (!(xml = virXMLParseStringCtxt(buffer, from, &ctxt))) + goto cleanup; + + if ((count = virXPathNodeSet("//cpu[not(ancestor::cpus)]", + ctxt, &node_list)) == -1) + goto cleanup; + + if (count == 0) { + vshError(ctl, _("No host CPU specified in '%s'"), from); + goto cleanup; + } + + list = vshCalloc(ctl, count, sizeof(const char *)); + + for (i = 0; i < count; i++) { + if (!(list[i] = virXMLNodeToString(xml, node_list[i]))) { + vshSaveLibvirtError(); + goto cleanup; + } + } + + result = virConnectBaselineCPU(ctl->conn, + (const char **)list, count, flags); + + if (result) { + vshPrint(ctl, "%s", result); + ret = true; + } + +cleanup: + xmlXPathFreeContext(ctxt); + xmlFreeDoc(xml); + VIR_FREE(result); + if (list != NULL && count > 0) { + for (i = 0; i < count; i++) + VIR_FREE(list[i]); + } + VIR_FREE(list); + VIR_FREE(buffer); + VIR_FREE(node_list); + + return ret; + +no_memory: + vshError(ctl, "%s", _("Out of memory")); + ret = false; + goto cleanup; +} + +/* * "maxvcpus" command */ static const vshCmdInfo info_maxvcpus[] = { @@ -955,6 +1066,12 @@ const vshCmdDef hostAndHypervisorCmds[] = { .info = info_hostname, .flags = 0 }, + {.name = "cpu-baseline", + .handler = cmdCPUBaseline, + .opts = opts_cpu_baseline, + .info = info_cpu_baseline, + .flags = 0 + }, {.name = "maxvcpus", .handler = cmdMaxvcpus, .opts = opts_maxvcpus, -- 1.7.1 -- Regards, -------------------------------------------------- Li Yang TEL：+86+25-86630566-8529 EMail：liyang.fnst(a)cn.fujitsu.com --------------------------------------------------

3 6

[libvirt] [PATCH 00/23] Better approach to add the "pvticketlocks" feature
by Peter Krempa 15 Oct '13

15 Oct '13

The paravirtual spinlock feature was introduced recently into the qemu and linux code base. To test it you need the most recent -rc version of the linux kernel and the git version of qemu. As the requirements to activate this feature in the guest are really volatile (kernel support, qemu support .. .) I decided to improve the original version so that it detects if the feature was actually enabled in the guest. This avoids possible problems with breaking guest ABI when migrating between two hosts with different kernels. Additionally we may start enforcin other features too. This patchset is partialy based on Jiri's work on getting actual cpu definition from a running qemu. Jiri Denemark (8): cpu: Add support for loading and storing CPU data cpu: x86: Rename struct cpuX86cpuid as virCPUx86CPUID cpu: x86: Rename struct cpuX86Data as virCPUx86Data cpu: x86: Rename x86DataFree() as virCPUx86DataFree() cpu: x86: Rename x86MakeCPUData as virCPUx86MakeData cpu: x86: Rename x86DataAddCpuid as virCPUx86DataAddCPUID cpu: Export few x86-specific APIs qemu: Add monitor APIs to fetch CPUID data from QEMU Peter Krempa (15): schema: Rename option to make it reusable conf: Clean up few error messages qemu: command: Fix macro indentation cpu: x86: Rename data_iterator and DATA_ITERATOR_INIT cpu: x86: Fix return types of x86cpuidMatch and x86cpuidMatchMasked cpu: x86: Fix function header formatting and whitespace cpu: x86: Use whitespace to clarify context and use consistent labels cpu: x86: Clean up error messages in x86VendorLoad() qemu: Clean up check of maximum cpu count supported by a machine type cpu_x86: Refactor storage of CPUID data to add support for KVM features cpu: x86: Parse the CPU feature map only once cpu: x86: Add internal CPUID features support and KVM feature bits conf: Refactor storing and usage of feature flags qemu: Add support for paravirtual spinlocks in the guest qemu: process: Validate specific CPUID flags of a guest docs/formatdomain.html.in | 7 + docs/schemas/domaincommon.rng | 18 +- src/conf/domain_conf.c | 200 ++++-- src/conf/domain_conf.h | 3 +- src/cpu/cpu.c | 41 ++ src/cpu/cpu.h | 16 +- src/cpu/cpu_x86.c | 699 ++++++++++++--------- src/cpu/cpu_x86.h | 9 + src/cpu/cpu_x86_data.h | 26 +- src/libvirt_private.syms | 8 + src/libxl/libxl_conf.c | 9 +- src/lxc/lxc_container.c | 6 +- src/qemu/qemu_command.c | 31 +- src/qemu/qemu_monitor.c | 21 + src/qemu/qemu_monitor.h | 3 + src/qemu/qemu_monitor_json.c | 107 ++++ src/qemu/qemu_monitor_json.h | 3 + src/qemu/qemu_process.c | 50 +- src/vbox/vbox_tmpl.c | 45 +- src/xenapi/xenapi_driver.c | 10 +- src/xenapi/xenapi_utils.c | 22 +- src/xenxs/xen_sxpr.c | 20 +- src/xenxs/xen_xm.c | 30 +- tests/Makefile.am | 1 + .../qemumonitorjson-getcpu-empty.data | 2 + .../qemumonitorjson-getcpu-empty.json | 46 ++ .../qemumonitorjson-getcpu-filtered.data | 4 + .../qemumonitorjson-getcpu-filtered.json | 46 ++ .../qemumonitorjson-getcpu-full.data | 5 + .../qemumonitorjson-getcpu-full.json | 46 ++ .../qemumonitorjson-getcpu-host.data | 6 + .../qemumonitorjson-getcpu-host.json | 45 ++ tests/qemumonitorjsontest.c | 76 +++ .../qemuxml2argv-pv-spinlock-disabled.args | 5 + .../qemuxml2argv-pv-spinlock-disabled.xml | 26 + .../qemuxml2argv-pv-spinlock-enabled.args | 5 + .../qemuxml2argv-pv-spinlock-enabled.xml | 26 + tests/qemuxml2argvtest.c | 2 + tests/qemuxml2xmltest.c | 2 + 39 files changed, 1279 insertions(+), 448 deletions(-) create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-getcpu-empty.data create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-getcpu-empty.json create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-getcpu-filtered.data create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-getcpu-filtered.json create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-getcpu-full.data create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-getcpu-full.json create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-getcpu-host.data create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-getcpu-host.json create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pv-spinlock-disabled.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pv-spinlock-disabled.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pv-spinlock-enabled.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pv-spinlock-enabled.xml -- 1.8.3.2

1 24

[libvirt] [PATCH] xenapi: Fix build after const correctnes changes
by Peter Krempa 15 Oct '13

15 Oct '13

In commit d24677090f1c0596ac1585cc233d6e130b9bb75f the header of one of the post parse callbacks was changed, but the function used as the callback in the xenapi driver wasn't adapted. This resulted into: CC xenapi/libvirt_driver_xenapi_la-xenapi_utils.lo xenapi/xenapi_driver.c:63:5: error: initialization from incompatible pointer type [-Werror] xenapi/xenapi_driver.c:63:5: error: (near initialization for 'xenapiDomainDefParserConfig.devicesPostParseCallback') [-Werror] --- src/xenapi/xenapi_driver.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/xenapi/xenapi_driver.c b/src/xenapi/xenapi_driver.c index bca19af..4b522c0 100644 --- a/src/xenapi/xenapi_driver.c +++ b/src/xenapi/xenapi_driver.c @@ -45,7 +45,7 @@ static int xenapiDomainDeviceDefPostParse(virDomainDeviceDefPtr dev, - virDomainDefPtr def, + const virDomainDef *def, virCapsPtr caps ATTRIBUTE_UNUSED, void *opaque ATTRIBUTE_UNUSED) { -- 1.8.3.2

1 1

[libvirt] [PATCH 00/15] fix misuse of 'const fooPtr'
by Eric Blake 14 Oct '13

14 Oct '13

Mostly cleanup, but at least one bug fix (xen was instantiating a memballoon device too early, during the post-parse callback of the first device rather than after all devices were known). Spawned by the conversation here: https://www.redhat.com/archives/libvir-list/2013-September/thread.html#01311 Eric Blake (15): maint: avoid 'const fooPtr' in public API maint: avoid 'const fooPtr' in hashes maint: avoid 'const fooPtr' in several util files maint: avoid 'const fooPtr' in virnet files maint: avoid 'const fooPtr' in cpu files maint: avoid 'const fooPtr' in nwfilter files maint: avoid 'const fooPtr' in tests maint: avoid 'const fooPtr' in python bindings maint: fix awkward typing of virDomainChrGetDomainPtrs maint: avoid 'const fooPtr' in domain_conf maint: avoid 'const fooPtr' in conf maint: avoid 'const fooPtr' in security maint: avoid 'const fooPtr' in qemu maint: avoid 'const fooPtr' in all remaining places build: syntax check to avoid 'const fooPtr' cfg.mk | 8 ++ include/libvirt/libvirt.h.in | 6 +- python/generator.py | 11 -- python/libvirt-override.c | 4 +- src/conf/cpu_conf.c | 6 +- src/conf/cpu_conf.h | 8 +- src/conf/domain_conf.c | 164 ++++++++++++++++++------------ src/conf/domain_conf.h | 33 +++--- src/conf/interface_conf.c | 30 +++--- src/conf/interface_conf.h | 15 ++- src/conf/netdev_vlan_conf.c | 4 +- src/conf/netdev_vlan_conf.h | 4 +- src/conf/network_conf.c | 44 ++++---- src/conf/network_conf.h | 28 ++--- src/conf/node_device_conf.c | 14 +-- src/conf/node_device_conf.h | 14 +-- src/conf/nwfilter_conf.c | 6 +- src/conf/nwfilter_conf.h | 8 +- src/conf/nwfilter_params.c | 52 +++++----- src/conf/nwfilter_params.h | 32 +++--- src/conf/secret_conf.c | 8 +- src/conf/secret_conf.h | 4 +- src/conf/snapshot_conf.c | 6 +- src/conf/snapshot_conf.h | 6 +- src/cpu/cpu.c | 8 +- src/cpu/cpu.h | 16 +-- src/cpu/cpu_arm.c | 3 +- src/cpu/cpu_powerpc.c | 9 +- src/cpu/cpu_s390.c | 3 +- src/cpu/cpu_x86.c | 18 ++-- src/libxl/libxl_domain.c | 2 +- src/lxc/lxc_domain.c | 4 +- src/lxc/lxc_process.c | 4 +- src/nwfilter/nwfilter_dhcpsnoop.c | 12 +-- src/nwfilter/nwfilter_dhcpsnoop.h | 3 +- src/nwfilter/nwfilter_ebiptables_driver.c | 18 ++-- src/nwfilter/nwfilter_gentech_driver.c | 23 +++-- src/nwfilter/nwfilter_gentech_driver.h | 11 +- src/nwfilter/nwfilter_learnipaddr.c | 9 +- src/nwfilter/nwfilter_learnipaddr.h | 4 +- src/openvz/openvz_driver.c | 2 +- src/qemu/qemu_bridge_filter.c | 10 +- src/qemu/qemu_bridge_filter.h | 10 +- src/qemu/qemu_command.c | 34 +++---- src/qemu/qemu_conf.c | 2 +- src/qemu/qemu_domain.c | 5 +- src/qemu/qemu_driver.c | 2 +- src/qemu/qemu_hostdev.c | 2 +- src/qemu/qemu_monitor_json.c | 2 +- src/security/security_apparmor.c | 22 ++-- src/security/security_selinux.c | 2 +- src/uml/uml_driver.c | 15 +-- src/util/virbuffer.c | 8 +- src/util/virbuffer.h | 8 +- src/util/virebtables.c | 4 +- src/util/virebtables.h | 6 +- src/util/virhash.c | 21 ++-- src/util/virhash.h | 19 ++-- src/util/virmacaddr.c | 16 +-- src/util/virmacaddr.h | 16 +-- src/util/virnetdev.c | 20 ++-- src/util/virnetdev.h | 8 +- src/util/virnetdevbandwidth.c | 6 +- src/util/virnetdevbandwidth.h | 7 +- src/util/virnetdevmacvlan.c | 22 ++-- src/util/virnetdevmacvlan.h | 12 +-- src/util/virnetdevopenvswitch.c | 3 +- src/util/virnetdevopenvswitch.h | 3 +- src/util/virnetdevtap.c | 2 +- src/util/virnetdevtap.h | 4 +- src/util/virnetdevvlan.c | 6 +- src/util/virnetdevvlan.h | 6 +- src/util/virnetdevvportprofile.c | 28 ++--- src/util/virnetdevvportprofile.h | 10 +- src/util/virnetlink.c | 10 +- src/util/virnetlink.h | 8 +- src/util/virsocketaddr.c | 54 +++++----- src/util/virsocketaddr.h | 52 +++++----- src/xen/xen_driver.c | 12 ++- src/xen/xm_internal.c | 4 +- tests/cputest.c | 4 +- tests/qemucapabilitiestest.c | 2 +- tests/qemumonitorjsontest.c | 21 ++-- tests/virhashtest.c | 8 +- 84 files changed, 625 insertions(+), 555 deletions(-) -- 1.8.3.1

2 33

[libvirt] [PATCH] esx: Fix floppy.fileName handling in the vmx file parser
by Geoff Hickey 14 Oct '13

14 Oct '13

The vmx file parsing code was reporting errors when parsing floppy.fileName entries if the filename didn't end in .flp. There is no such restriction in ESX; even using the GUI to configure floppy filenames you can specify any arbitrary file with any extension. Fix by changing the vmx parsing code so that it uses the floppy.fileType value to determine whether floppy.fileName refers to a block device or a regular file. Also remove code that would have generated an error if no floppy.fileName was specified. This is not an error either. --- src/vmx/vmx.c | 28 ++++------------------------ 1 file changed, 4 insertions(+), 24 deletions(-) diff --git a/src/vmx/vmx.c b/src/vmx/vmx.c index 36bc338..48487f8 100644 --- a/src/vmx/vmx.c +++ b/src/vmx/vmx.c @@ -2250,27 +2250,14 @@ virVMXParseDisk(virVMXContext *ctx, virDomainXMLOptionPtr xmlopt, virConfPtr con goto cleanup; } } else if (device == VIR_DOMAIN_DISK_DEVICE_FLOPPY) { - if (virFileHasSuffix(fileName, ".flp")) { - if (fileType != NULL) { - if (STRCASENEQ(fileType, "file")) { - virReportError(VIR_ERR_INTERNAL_ERROR, - _("Expecting VMX entry '%s' to be 'file' but " - "found '%s'"), fileType_name, fileType); - goto cleanup; - } - } - - (*def)->type = VIR_DOMAIN_DISK_TYPE_FILE; - (*def)->src = ctx->parseFileName(fileName, ctx->opaque); - - if ((*def)->src == NULL) { - goto cleanup; - } - } else if (fileType != NULL && STRCASEEQ(fileType, "device")) { + if (fileType != NULL && STRCASEEQ(fileType, "device")) { (*def)->type = VIR_DOMAIN_DISK_TYPE_BLOCK; (*def)->src = fileName; fileName = NULL; + } else if (fileType != NULL && STRCASEEQ(fileType, "file")) { + (*def)->type = VIR_DOMAIN_DISK_TYPE_FILE; + (*def)->src = ctx->parseFileName(fileName, ctx->opaque); } else { virReportError(VIR_ERR_INTERNAL_ERROR, _("Invalid or not yet handled value '%s' " @@ -3538,13 +3525,6 @@ virVMXFormatFloppy(virVMXContext *ctx, virDomainDiskDefPtr def, virBufferAsprintf(buffer, "floppy%d.fileType = \"file\"\n", unit); if (def->src != NULL) { - if (! virFileHasSuffix(def->src, ".flp")) { - virReportError(VIR_ERR_INTERNAL_ERROR, - _("Image file for floppy '%s' has unsupported " - "suffix, expecting '.flp'"), def->dst); - return -1; - } - fileName = ctx->formatFileName(def->src, ctx->opaque); if (fileName == NULL) { -- 1.8.1.2

2 1

[libvirt] [RESEND][PATCHv5 0/4] write separate module for hostdev passthrough
by Chunyan Liu 14 Oct '13

14 Oct '13

[rebased to latest libvirt code for applying and reviewing the patches] These patches implements a separate module for hostdev passthrough so that it could be shared by different drivers and can maintain a global state of a host device. Plus, add passthrough to libxl driver, and change qemu driver and lxc driver to use hostdev common library instead of their own hostdev APIs. --- Changes to v4: * change the way checking hypervisor driver name to decide whether use pciback or pci-stub as stub driver, instead, using driver callback to handle that. * remove get active/inactive list APIs from hostdev common library since currently no code uses them. * add nodedev-detach/reattach/reset to libxl driver * other fixes to Daniel and Jim's comments v4 is here: https://www.redhat.com/archives/libvir-list/2013-August/msg00806.html Changes to v3: * fix Jim's comments v3 is here: https://www.redhat.com/archives/libvir-list/2013-August/msg00019.html Changes to v2: * add patches for qemu driver and lxc driver, use common library APIs instead of their own hostdev APIs. * add APIs for nodedev-detach and nodedev-reattach calling. * rename functions to use unified prefix 'virHostdev' * use VIR_ONCE_GLOBAL_INIT() as others instead of previous Init and Cleanup. * use VIR_STRDUP instead of strdup * rebase to latest code v2 is here: https://www.redhat.com/archives/libvir-list/2013-June/msg00263.html Chunyan Liu (4): add hostdev passthrough common library add pci passthrough to libxl driver change qemu driver to use hostdev common library change lxc driver to use hostdev common library docs/schemas/domaincommon.rng | 1 + po/POTFILES.in | 3 +- src/Makefile.am | 3 +- src/conf/domain_conf.c | 3 +- src/conf/domain_conf.h | 1 + src/libvirt_private.syms | 15 + src/libxl/libxl_conf.c | 63 ++ src/libxl/libxl_conf.h | 4 + src/libxl/libxl_domain.c | 9 + src/libxl/libxl_driver.c | 443 ++++++++++++++- src/lxc/lxc_conf.h | 4 - src/lxc/lxc_driver.c | 45 +- src/lxc/lxc_hostdev.c | 413 ------------- src/lxc/lxc_hostdev.h | 43 -- src/lxc/lxc_process.c | 21 +- src/qemu/qemu_command.c | 1 - src/qemu/qemu_conf.h | 9 +- src/qemu/qemu_domain.c | 9 + src/qemu/qemu_driver.c | 72 +-- src/qemu/qemu_hostdev.c | 1289 --------------------------------------- src/qemu/qemu_hostdev.h | 72 --- src/qemu/qemu_hotplug.c | 126 ++--- src/qemu/qemu_process.c | 34 +- src/util/virhostdev.c | 1335 +++++++++++++++++++++++++++++++++++++++++ src/util/virhostdev.h | 104 ++++ src/util/virpci.c | 28 +- src/util/virpci.h | 9 +- src/util/virscsi.c | 26 +- src/util/virscsi.h | 8 +- src/util/virusb.c | 27 +- src/util/virusb.h | 8 +- 31 files changed, 2195 insertions(+), 2033 deletions(-) delete mode 100644 src/lxc/lxc_hostdev.c delete mode 100644 src/lxc/lxc_hostdev.h delete mode 100644 src/qemu/qemu_hostdev.c delete mode 100644 src/qemu/qemu_hostdev.h create mode 100644 src/util/virhostdev.c create mode 100644 src/util/virhostdev.h

2 8

[libvirt] libvirt URI for "UNIX abstract namespace"?
by Philipp Hahn 14 Oct '13

14 Oct '13

Hello, while trying to reproduce a performance problem I had to fake 95 hosts with 300 VMs. My idea was to setup 95 users with each one running a session libvirtd. When adding them to our management system I had was troubled with finding the right libvirt URI, as the default session UNIX socket is in the "abstract ns", which has no file system representation. I solved that by explicitly starting the session libvirtds with a custom config only specifying a physical socket path: for ((h=0;h<95;h+=1));do su -c "/usr/sbin/libvirtd -f <(echo "unix_sock_dir=\"/home/host$h/.libvirt\"") -d" "host$h";done 1. is there a way to specify an libvirt URI using the abstract ns? 2. Does anybody know another/better way to simulate many hosts with many VMs? Thanks in advance. Philipp PS: libvirt-0.9.12 -- Philipp Hahn Open Source Software Engineer hahn(a)univention.de Univention GmbH be open. fon: +49 421 22 232- 0 Mary-Somerville-Str.1 D-28359 Bremen fax: +49 421 22 232-99 http://www.univention.de/ Director:Peter H. Ganten HRB 20755 Amtsgericht Bremen UID:DE 220 051 310

2 1

[libvirt] [PATCH 1/3] Revert "VMX: Some serial ports are not actually connected"
by Doug Goldstein 14 Oct '13

14 Oct '13

This reverts commit dba04e7fa070a79415ea16141ad2e2ebd4f23033. This change was unfortunately not correct. We should have been changing the boolean argument supplied. --- src/vmx/vmx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/vmx/vmx.c b/src/vmx/vmx.c index 38b7cc0..9906a9c 100644 --- a/src/vmx/vmx.c +++ b/src/vmx/vmx.c @@ -2718,7 +2718,7 @@ virVMXParseSerial(virVMXContext *ctx, virConfPtr conf, int port, /* vmx:fileName -> def:data.file.path */ if (virVMXGetConfigString(conf, fileName_name, &fileName, false) < 0) { - goto ignore; + goto cleanup; } /* vmx:network.endPoint -> def:data.tcp.listen */ -- 1.8.1.5

2 3

[libvirt] [PATCHv2] rpc: Retrieve peer PID via new getsockopt() for Mac
by Doug Goldstein 14 Oct '13

14 Oct '13

While LOCAL_PEERCRED on the BSDs does not return the pid information of the peer, Mac OS X 10.8 added LOCAL_PEERPID to retrieve the pid so we should use that when its available to get that information. --- v2: * Make LOCAL_PEERPID call non-fatal in case the user built the binary on a system that supports it but then runs it on a kernel that does not support it --- src/rpc/virnetsocket.c | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/src/rpc/virnetsocket.c b/src/rpc/virnetsocket.c index e8cdfa6..7126c4f 100644 --- a/src/rpc/virnetsocket.c +++ b/src/rpc/virnetsocket.c @@ -1195,12 +1195,29 @@ int virNetSocketGetUNIXIdentity(virNetSocketPtr sock, return -1; } - /* PID and process creation time are not supported on BSDs */ + /* PID and process creation time are not supported on BSDs by + * LOCAL_PEERCRED. + */ *pid = -1; *timestamp = -1; *uid = cr.cr_uid; *gid = cr.cr_gid; +# ifdef LOCAL_PEERPID + /* Exists on Mac OS X 10.8 for retrieving the peer's PID */ + cr_len = sizeof(*pid); + + if (getsockopt(sock->fd, VIR_SOL_PEERCRED, LOCAL_PEERPID, pid, &cr_len) < 0) { + virReportSystemError(errno, "%s", + _("Failed to get client socket PID")); + /* Don't treat this as fatal, but do set the value to something sane + * in case the user built this on a system that has LOCAL_PEERPID + * defined but the kernel does not actually support it. + */ + *pid = -1; + } +# endif + virObjectUnlock(sock); return 0; } -- 1.8.1.5

2 2