- Devel - libvirt List Archives

[libvirt] [PATCH 0/5] Add support to define new domain using an OVA package.
by Ata E Husain Bohra 06 Jan '13

06 Jan '13

This patch aims to extend libvirt functionality to define new domain using a given OVA package. The patch consist of multiple commits divided mainly into two categories: Infrastructure support: ----------------------- Patch 1,2 and 5 lays the foundation work including: 1. Libvirt Public API support. 2. OVA file handling and parsing operations. 3. virsh command. ESX specific implementation: --------------------------- Patch 3 and 4 adds implementation support to define new domain for a ESX hypervisor. NOTE: ----- During development of this patch, I have fixed two issues with exisiting ESX hypervisor driver, they are posted as seperate reviews: 1. https://www.redhat.com/archives/libvir-list/2012-December/msg01377.html 2. https://www.redhat.com/archives/libvir-list/2013-January/msg00007.html Above patches are necessary for proper functioning of the proposed feature. Ata E Husain Bohra (5): Public API to allow defining new domain using OVA file Parsing and file handling operations for an OVA file ESX: CURL routine to allow file upload to the server ESX: Driver support to define new domain using an OVA pacakge virsh: Command to define new domain using OVA package. include/libvirt/libvirt.h.in | 3 + po/POTFILES.in | 1 + src/Makefile.am | 1 + src/driver.h | 5 + src/esx/esx_driver.c | 573 +++++++++++++++++++++++++- src/esx/esx_vi.c | 147 ++++++- src/esx/esx_vi.h | 35 +- src/esx/esx_vi_generator.input | 862 +++++++++++++++++++++++++++++++++++++++- src/esx/esx_vi_generator.py | 13 +- src/esx/esx_vi_types.c | 13 +- src/libvirt.c | 58 +++ src/libvirt_public.syms | 5 + src/util/virova.c | 463 +++++++++++++++++++++ src/util/virova.h | 68 ++++ tools/virsh-domain.c | 44 ++ 15 files changed, 2264 insertions(+), 27 deletions(-) create mode 100644 src/util/virova.c create mode 100644 src/util/virova.h -- 1.7.9.5

1 0

[libvirt] [PATCH] Install virtlockd.{socket, service} non executable
by Guido Günther 05 Jan '13

05 Jan '13

since they're not scripts but systemd service files. --- src/Makefile.am | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/Makefile.am b/src/Makefile.am index f7a9b91..0cfc1ed 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -1687,9 +1687,9 @@ DISTCLEANFILES += virtlockd.service virtlockd.socket install-systemd: virtlockd.service virtlockd.socket install-sysconfig $(MKDIR_P) $(DESTDIR)$(SYSTEMD_UNIT_DIR) - $(INSTALL_SCRIPT) virtlockd.service \ + $(INSTALL_DATA) virtlockd.service \ $(DESTDIR)$(SYSTEMD_UNIT_DIR)/ - $(INSTALL_SCRIPT) virtlockd.socket \ + $(INSTALL_DATA) virtlockd.socket \ $(DESTDIR)$(SYSTEMD_UNIT_DIR)/ uninstall-systemd: uninstall-sysconfig -- 1.7.10.4

3 5

[libvirt] [PATCH 0/4] Fix segfault while redefining snapshots and allow redefinition of external snapshots
by Peter Krempa 05 Jan '13

05 Jan '13

This series fixes two issues while redefining snapshots: 1) Segfault when disk alignment of the new snapshot failed (patch 3) 2) Failure to redefine external snapshots. A check was missing to align disks for external snapshots. (patch 4) Peter Krempa (4): snapshot: conf: Make virDomainSnapshotIsExternal more reusable snapshot: qemu: Separate logic blocks with newlines snapshot: qemu: Fix segfault and vanishing snapshots when redefining snapshot: qemu: Allow redefinition of external snapshots src/conf/snapshot_conf.c | 14 ++++++++---- src/conf/snapshot_conf.h | 1 + src/libvirt_private.syms | 1 + src/qemu/qemu_driver.c | 57 +++++++++++++++++++++++++++++++++++------------- 4 files changed, 54 insertions(+), 19 deletions(-) -- 1.8.0.2

2 10

[libvirt] [PATCH 0/4 v2] ivshmem support
by Osier Yang 05 Jan '13

05 Jan '13

v1 - v2: * Change attribute "model" to be a sub-element instead. NOTE: Since the invshmem server socket path is not created by QEMU, but by an external app called "ivshmem_server", It's not good to construct the socket path in libvirt with a solid rule, and force the user to figure out what the path is libvirt uses first and use that for "ivshmem_server". Thus it's the user's business to set the selinux context on the socket path so that the qemu process could be started successfully when selinux is enabled. Shawn Furrow proposed a patch more than a month ago: https://www.redhat.com/archives/libvir-list/2012-September/msg01612.html But this is a complete different implementation. Considering there could be other memory related devices in futuer, this introduces a new device model, called "memory device", instead of a specific device like "ivshmem", though only "ivshmem" is supported currently. Please refer to PATCH 1/4 for more details. CC'ed to Cam and Shawn, to see if there is advise on the documents. Osier Yang (4): docs: Add documents for memory device conf: Parse and format memory device XML qemu: Add cap flag QEMU_CAPS_IVSHMEM qemu: Build command line for ivshmem device docs/formatdomain.html.in | 40 +++++ docs/schemas/domaincommon.rng | 40 +++++ src/conf/domain_conf.c | 195 +++++++++++++++++++++- src/conf/domain_conf.h | 27 +++ src/libvirt_private.syms | 3 + src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 85 ++++++++++ src/util/util.c | 5 + src/util/util.h | 2 + tests/qemuhelptest.c | 12 +- tests/qemuxml2argvdata/qemuxml2argv-ivshmem.args | 7 + tests/qemuxml2argvdata/qemuxml2argv-ivshmem.xml | 34 ++++ tests/qemuxml2argvtest.c | 2 + 14 files changed, 450 insertions(+), 5 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-ivshmem.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-ivshmem.xml -- 1.7.7.6

5 12

[libvirt] [PATCH 0/5] Add API to tunnel channels
by John Eckersberg 05 Jan '13

05 Jan '13

This series enables the qemu driver to tunnel a virtio channel. This is useful for a remote session to communicate with a guest channel via the streaming API. This was originally fleshed out a while back in this thread: https://www.redhat.com/archives/libvir-list/2011-September/msg01049.html This implements only item (3) in that list. The new API is nearly identical to the existing virDomainOpenConsole API, except it works on channels, and supports UNIX sockets in addition to PTYs for channel source type. This is my first libvirt patch, please be gentle :) John Eckersberg (5): api: Add API to tunnel a guest channel via stream conf: Rename virconsole.* to virchrdev.* conf: Rename console-specific identifiers to be more generic conf: Add unix socket support to virChrdevOpen qemu: Implement virDomainOpenChannel API configure.ac | 48 ++--- include/libvirt/libvirt.h.in | 16 ++ po/POTFILES.in | 2 +- src/Makefile.am | 8 +- src/conf/virchrdev.c | 442 +++++++++++++++++++++++++++++++++++++++++++ src/conf/virchrdev.h | 37 ++++ src/conf/virconsole.c | 414 ---------------------------------------- src/conf/virconsole.h | 36 ---- src/driver.h | 7 + src/libvirt.c | 61 ++++++ src/libvirt_private.syms | 8 +- src/libvirt_public.syms | 5 + src/qemu/qemu_domain.c | 4 +- src/qemu/qemu_domain.h | 4 +- src/qemu/qemu_driver.c | 81 +++++++- src/remote/remote_driver.c | 1 + src/remote/remote_protocol.x | 9 +- src/remote_protocol-structs | 6 + 18 files changed, 697 insertions(+), 492 deletions(-) create mode 100644 src/conf/virchrdev.c create mode 100644 src/conf/virchrdev.h delete mode 100644 src/conf/virconsole.c delete mode 100644 src/conf/virconsole.h -- 1.7.11.7

4 21

[libvirt] [PATCH] build: fix mingw rpm build
by Eric Blake 05 Jan '13

05 Jan '13

Commit d13155c changed which files get installed for the libvirt-guests service, but did not touch up the mingw spec file. As a result, rpmbuild complained: RPM build errors: Installed (but unpackaged) file(s) found: /usr/i686-w64-mingw32/sys-root/mingw/libexec/libvirt-guests.sh /usr/x86_64-w64-mingw32/sys-root/mingw/libexec/libvirt-guests.sh which in turn breaks ./autobuild.sh when cross-compilers are present. * mingw-libvirt.spec.in: Remove files not relevant to mingw. --- Pushing under the build-breaker rule. mingw-libvirt.spec.in | 2 ++ 1 file changed, 2 insertions(+) diff --git a/mingw-libvirt.spec.in b/mingw-libvirt.spec.in index 4695895..f1540b3 100644 --- a/mingw-libvirt.spec.in +++ b/mingw-libvirt.spec.in @@ -177,6 +177,8 @@ rm -rf $RPM_BUILD_ROOT%{mingw64_datadir}/gtk-doc/* rm -rf $RPM_BUILD_ROOT%{mingw32_libexecdir}/libvirt_iohelper.exe rm -rf $RPM_BUILD_ROOT%{mingw64_libexecdir}/libvirt_iohelper.exe +rm -rf $RPM_BUILD_ROOT%{mingw32_libexecdir}/libvirt-guests.sh +rm -rf $RPM_BUILD_ROOT%{mingw64_libexecdir}/libvirt-guests.sh # Mingw32 -- 1.8.0.2

1 0

[libvirt] [PATCH] network: fix check for ambiguous lookup
by Eric Blake 05 Jan '13

05 Jan '13

gcc -O2 complained: ../../src/conf/network_conf.c: In function 'virNetworkDefUpdateDNSSrv': ../../src/conf/network_conf.c:3232: error: 'foundIdx' may be used uninitialized in this function [-Wuninitialized] It turned out to be a spurious warning (we didn't use foundIdx unless foundCt was non-zero). But in investigating that, I noticed a worse problem: we were using 'if (foundCt > 1)', but since foundCt was bool, it could never be > 1. * src/conf/network_conf.c (virNetworkDefUpdateDNSHost): Use correct type. (virNetworkDefUpdateDNSSrv): Likewise, and silence compiler warning. --- Pushing under the build-breaker rule in order to shut up the gcc warning, and under the trivial rule to fix the wrong type. src/conf/network_conf.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/conf/network_conf.c b/src/conf/network_conf.c index f949f79..d185b46 100644 --- a/src/conf/network_conf.c +++ b/src/conf/network_conf.c @@ -1,7 +1,7 @@ /* * network_conf.c: network XML handling * - * Copyright (C) 2006-2012 Red Hat, Inc. + * Copyright (C) 2006-2013 Red Hat, Inc. * Copyright (C) 2006-2008 Daniel P. Berrange * * This library is free software; you can redistribute it and/or @@ -3138,7 +3138,7 @@ virNetworkDefUpdateDNSHost(virNetworkDefPtr def, virNetworkDNSHostDef host; bool isAdd = (command == VIR_NETWORK_UPDATE_COMMAND_ADD_FIRST || command == VIR_NETWORK_UPDATE_COMMAND_ADD_LAST); - bool foundCt = 0; + int foundCt = 0; memset(&host, 0, sizeof(host)); @@ -3229,12 +3229,12 @@ virNetworkDefUpdateDNSSrv(virNetworkDefPtr def, /* virNetworkUpdateFlags */ unsigned int fflags ATTRIBUTE_UNUSED) { - int ii, foundIdx, ret = -1; + int ii, foundIdx = -1, ret = -1; virNetworkDNSDefPtr dns = &def->dns; virNetworkDNSSrvDef srv; bool isAdd = (command == VIR_NETWORK_UPDATE_COMMAND_ADD_FIRST || command == VIR_NETWORK_UPDATE_COMMAND_ADD_LAST); - bool foundCt = 0; + int foundCt = 0; memset(&srv, 0, sizeof(srv)); -- 1.7.1

1 0

[libvirt] [PATCH 2/2] target-i386: Disable kvm_mmu_op by default on pc-1.4
by Eduardo Habkost 05 Jan '13

05 Jan '13

The kvm_mmu_op feature was removed from the kernel since v3.3 (released in March 2012), it was marked for removal since January 2011 and it's slower than shadow or hardware assisted paging (see kernel commit fb92045843). It doesn't make sense to keep it enabled by default. Also, keeping it enabled by default would cause unnecessary hassle when libvirt start using the "enforce" option. Signed-off-by: Eduardo Habkost <ehabkost(a)redhat.com> --- Cc: kvm(a)vger.kernel.org Cc: Michael S. Tsirkin <mst(a)redhat.com> Cc: Gleb Natapov <gleb(a)redhat.com> Cc: Marcelo Tosatti <mtosatti(a)redhat.com> Cc: libvir-list(a)redhat.com Cc: Jiri Denemark <jdenemar(a)redhat.com> I was planning to reverse the logic of the compat init functions and make pc_init_pci_1_3() enable kvm_mmu_op and then call pc_init_pci_1_4(). But that would require changing pc_init_pci_no_kvmclock() and pc_init_isa() as well. So to keep the changes simple, I am keeping the pattern used when pc_init_pci_1_3() was introduced, making pc_init_pci_1_4() disable kvm_mmu_op and then call pc_init_pci_1_3(). --- hw/pc_piix.c | 11 ++++++++++- target-i386/cpu.c | 8 ++++++++ target-i386/cpu.h | 1 + 3 files changed, 19 insertions(+), 1 deletion(-) diff --git a/hw/pc_piix.c b/hw/pc_piix.c index 99747a7..a6bf645 100644 --- a/hw/pc_piix.c +++ b/hw/pc_piix.c @@ -217,6 +217,7 @@ static void pc_init1(MemoryRegion *system_memory, } } +/* machine init function for pc-0.14 - pc-1.2 */ static void pc_init_pci(QEMUMachineInitArgs *args) { ram_addr_t ram_size = args->ram_size; @@ -232,12 +233,20 @@ static void pc_init_pci(QEMUMachineInitArgs *args) initrd_filename, cpu_model, 1, 1); } +/* machine init function for pc-1.3 */ static void pc_init_pci_1_3(QEMUMachineInitArgs *args) { enable_kvm_pv_eoi(); pc_init_pci(args); } +/* machine init function for pc-1.4 */ +static void pc_init_pci_1_4(QEMUMachineInitArgs *args) +{ + disable_kvm_mmu_op(); + pc_init_pci_1_3(args); +} + static void pc_init_pci_no_kvmclock(QEMUMachineInitArgs *args) { ram_addr_t ram_size = args->ram_size; @@ -285,7 +294,7 @@ static QEMUMachine pc_machine_v1_4 = { .name = "pc-1.4", .alias = "pc", .desc = "Standard PC", - .init = pc_init_pci_1_3, + .init = pc_init_pci_1_4, .max_cpus = 255, .is_default = 1, }; diff --git a/target-i386/cpu.c b/target-i386/cpu.c index 808001a..ec877c7 100644 --- a/target-i386/cpu.c +++ b/target-i386/cpu.c @@ -157,6 +157,14 @@ void enable_kvm_pv_eoi(void) #endif } +void disable_kvm_mmu_op(void) +{ +#ifdef CONFIG_KVM + if (kvm_enabled()) + kvm_default_features &= ~(1UL << KVM_FEATURE_MMU_OP); +#endif +} + void host_cpuid(uint32_t function, uint32_t count, uint32_t *eax, uint32_t *ebx, uint32_t *ecx, uint32_t *edx) { diff --git a/target-i386/cpu.h b/target-i386/cpu.h index 1283537..27c8d0c 100644 --- a/target-i386/cpu.h +++ b/target-i386/cpu.h @@ -1219,5 +1219,6 @@ void do_smm_enter(CPUX86State *env1); void cpu_report_tpr_access(CPUX86State *env, TPRAccess access); void enable_kvm_pv_eoi(void); +void disable_kvm_mmu_op(void); #endif /* CPU_I386_H */ -- 1.7.11.7

2 2

[libvirt] [PATCH 0/9] target-i386: make "enforce" flag work as it should
by Eduardo Habkost 05 Jan '13

05 Jan '13

This changes the -cpu check/enforce code to work as it should: it will check every single CPUID bit to make sure it is supported by the host. The changes are a bit intrusive, but: - The longer we take to make "enforce" strict as it should (and make libvirt finally use it), more users will have VMs with migration-unsafe unpredictable guest ABIs. For this reason, I would like to get this into QEMU 1.4. - The changes in this series should affect only users that are already using the "enforce" flag, and I believe whoever is using the "enforce" flag really want the strict behavior introduced by this series. This series is based on Andreas' qom-cpu branch, and depends on the series: Subject: [PATCH 0/2] Disable kvm_mmu_op by default on pc-1.4 Message-Id: <1357311145-16410-1-git-send-email-ehabkost(a)redhat.com> Git tree for reference: git://github.com/ehabkost/qemu-hacks.git cpu-enforce-all.v1 https://github.com/ehabkost/qemu-hacks/tree/cpu-enforce-all.v1 Eduardo Habkost (9): target-i386: kvm: -cpu host: Use GET_SUPPORTED_CPUID for SVM features target-i386: kvm: Enable all supported KVM features for -cpu host target-i386: check/enforce: Fix CPUID leaf numbers on error messages target-i386: check/enforce: Do not ignore "hypervisor" flag target-i386: check/enforce: Check all CPUID.80000001H.EDX bits target-i386: check/enforce: Check SVM flag support as well target-i386: check/enforce: Eliminate check_feat field target-i386: Call kvm_check_features_against_host() only if CONFIG_KVM is set target-i386: check/enforce: Check all feature words target-i386/cpu.c | 73 +++++++++++++++++++++++++++++++++++++++---------------- target-i386/cpu.h | 3 +++ 2 files changed, 55 insertions(+), 21 deletions(-) -- 1.7.11.7

3 12

[libvirt] [PATCH] Fix substitution of sbindir in virtlockd.service
by Jim Fehlig 04 Jan '13

04 Jan '13

The makefile rule substitutes variables delimited by '::', but the virtlockd service files uses '@'. Change the service file to match the makefile rule. --- src/locking/virtlockd.service.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/locking/virtlockd.service.in b/src/locking/virtlockd.service.in index a9f9f93..dad7c19 100644 --- a/src/locking/virtlockd.service.in +++ b/src/locking/virtlockd.service.in @@ -5,7 +5,7 @@ After=syslog.target [Service] EnvironmentFile=-/etc/sysconfig/virtlockd -ExecStart=@sbindir@/virtlockd +ExecStart=::sbindir::/virtlockd ExecReload=/bin/kill -HUP $MAINPID # Loosing the locks is a really bad thing that will # cause the machine to be fenced (rebooted), so make -- 1.8.0.1

2 3