- Devel - libvirt List Archives

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

04 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 04 Jan '13

04 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 04 Jan '13

04 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

[libvirt] [PATCH] qemu: Detect VGA_QXL capability correctly
by Michal Privoznik 04 Jan '13

04 Jan '13

Since 4c993d8a we failed to set this important capability, which allows starting a domain with QXL video card. We set DEVICE_QXL capability bit instead, which is not necessary wrong. Anyway, if qemu supports the new '-device qxl' it supports older '-vga qxl' as well. The latter is used for the primary (the first) qxl video card, the former for other video cards. --- Other approach is to set QEMU_CAPS_VGA_QXL unconditionally as supported by all qemu-1.2+ in qemuCapsInitQMPBasic(). But I think this one is slightly nicer. src/qemu/qemu_capabilities.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c index f49a31c..e16bc70 100644 --- a/src/qemu/qemu_capabilities.c +++ b/src/qemu/qemu_capabilities.c @@ -2018,6 +2018,9 @@ qemuCapsProbeQMPObjects(qemuCapsPtr caps, /* Prefer -chardev spicevmc (detected earlier) over -device spicevmc */ if (qemuCapsGet(caps, QEMU_CAPS_CHARDEV_SPICEVMC)) qemuCapsClear(caps, QEMU_CAPS_DEVICE_SPICEVMC); + /* If qemu supports newer -device qxl it supports -vga qxl as well */ + if (qemuCapsGet(caps, QEMU_CAPS_DEVICE_QXL)) + qemuCapsSet(caps, QEMU_CAPS_VGA_QXL); return 0; } -- 1.8.0.2

5 6

[libvirt] libvirt unable to start domains
by Zeeshan Ali (Khattak) 04 Jan '13

04 Jan '13

Hi, I updated my libvirt git clone and install yesterday (after about a month or so) and now I can't start domains: $ virsh start fedora18 error: Failed to start domain fedora18 error: unsupported configuration: This QEMU does not support QXL graphics adapters While libvirt is self-built, I'm using qemu 1.2.2-1.fc18 from vanila Fedora 18 repo. Just to be clear, qemu was not updated before the problem appeared, only libvirt. Here is the libvirtd log: http://static.fi/~zeenix/tmp/libvirtd-session-zeenix.log (13 MB). Also attaching the domain config. -- Regards, Zeeshan Ali (Khattak) FSF member#5124

5 10

[libvirt] [PATCH v2 0/8] Dump domain's IP addresses
by Michal Privoznik 04 Jan '13

04 Jan '13

It's been a while since I tried get this in. I've reworked the patches, the exposed API, and start new round of reviews. Moreover, during work I've come to point, where extending qemu guest agent seemed wise: http://lists.nongnu.org/archive/html/qemu-devel/2012-12/msg03264.html Therefore I am introducing 'flags' field, which can contain some boolean values we don't have yet, e.g. IFF_UP, IFF_PROMISC, etc. Re: 'dstaddr' field in struct _virDomainInterfaceIPAddress; It's basically a join of: union { char *dstaddr; /* for IFF_POINTOPOINT interface */ char *broadaddr; /* for IFF_BROADCAST interface */ } Since an interface cannot has both flags set (see man 3 getifaddrs) I've joined both into one 'char *dstaddr'. I know it is not mnemonic as the union, so I left it for discussion. I can change it if you want to. diff to v1: -don't return array of objects, but array of pointer to objects instead Michal Privoznik (8): Introduce virDomainInterfacesAddresses API Introduce virDomainInterfaceFree API qemu_agent: Implement 'guest-network-get-interfaces' command handling qemu: Implement qemuDomainInterfacesAddresses virsh: Expose virDomainInterfacesAddresses remote: Implement virDomainInterfacesAddresses python: Expose virDomainInterfacesAddresses python: create example for dumping domain IP addresses daemon/remote.c | 140 ++++++++++++++++++++++++++++++++ examples/python/Makefile.am | 2 +- examples/python/README | 1 + examples/python/domipaddrs.py | 50 ++++++++++++ include/libvirt/libvirt.h.in | 51 ++++++++++++ python/generator.py | 3 + python/libvirt-override-api.xml | 7 ++ python/libvirt-override.c | 120 ++++++++++++++++++++++++++++ src/driver.h | 6 ++ src/libvirt.c | 107 +++++++++++++++++++++++++ src/libvirt_public.syms | 7 ++ src/qemu/qemu_agent.c | 171 ++++++++++++++++++++++++++++++++++++++++ src/qemu/qemu_agent.h | 2 + src/qemu/qemu_driver.c | 68 ++++++++++++++++ src/remote/remote_driver.c | 94 ++++++++++++++++++++++ src/remote/remote_protocol.x | 27 ++++++- src/remote_protocol-structs | 27 +++++++ tools/virsh-domain.c | 104 ++++++++++++++++++++++++ 18 files changed, 985 insertions(+), 2 deletions(-) create mode 100755 examples/python/domipaddrs.py -- 1.8.0.2

3 10

[libvirt] problem in pciFindStubDriver
by Chunyan Liu 04 Jan '13

04 Jan '13

For Xen PV guests, pciback is the only working driver, pci-stub doesn't work. Current function finds pci-stub driver first, if pci-stub doesn't exist, find pciback. It won't work for Xen PV guests since it will find pci-stub driver and return, but in fact it needs pciback. One way is to prefer pciback rather than pci-stub like in following patch. But that will change the behaviour of other drivers too. Is there any preferred aprroach to handle this? diff --git a/src/util/virpci.c b/src/util/virpci.c index 5971764..c0a1c05 100644 --- a/src/util/virpci.c +++ b/src/util/virpci.c @@ -861,22 +861,22 @@ pciFindStubDriver(void) int probed = 0; recheck: - if (pciDriverDir(&drvpath, "pci-stub") < 0) { + if (pciDriverDir(&drvpath, "pciback") < 0) { return NULL; } if (virFileExists(drvpath)) { VIR_FREE(drvpath); - return "pci-stub"; + return "pciback"; } - if (pciDriverDir(&drvpath, "pciback") < 0) { + if (pciDriverDir(&drvpath, "pci-stub") < 0) { return NULL; } if (virFileExists(drvpath)) { VIR_FREE(drvpath); - return "pciback"; + return "pci-stub"; } VIR_FREE(drvpath);

2 1

[libvirt] [PATCH] qemu: Don't parse log output when starting up a domain
by Michal Privoznik 04 Jan '13

04 Jan '13

Despite our great effort we still parsed qemu log output. We wouldn't notice unless qemu changed the format of the logs slightly. Anyway, now we should gather all interesting knobs like pty paths from monitor. Moreover, since for historical reasons the first console can be just an alias to the first serial port, we need to check this and copy the pty path if that's the case to the first console. --- src/qemu/qemu_capabilities.c | 7 +++++++ src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_process.c | 20 ++++++++++++++++++-- 3 files changed, 26 insertions(+), 2 deletions(-) diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c index 17e6679..f49a31c 100644 --- a/src/qemu/qemu_capabilities.c +++ b/src/qemu/qemu_capabilities.c @@ -1695,6 +1695,7 @@ qemuCapsPtr qemuCapsNewCopy(qemuCapsPtr caps) virBitmapCopy(ret->flags, caps->flags); + ret->usedQMP = caps->usedQMP; ret->version = caps->version; ret->kvmVersion = caps->kvmVersion; ret->arch = caps->arch; @@ -2633,3 +2634,9 @@ qemuCapsCacheFree(qemuCapsCachePtr cache) virMutexDestroy(&cache->lock); VIR_FREE(cache); } + +bool +qemuCapsUsedQMP(qemuCapsPtr caps) +{ + return caps->usedQMP; +} diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h index 3457852..1417d7f 100644 --- a/src/qemu/qemu_capabilities.h +++ b/src/qemu/qemu_capabilities.h @@ -241,4 +241,5 @@ int qemuCapsParseDeviceStr(qemuCapsPtr caps, const char *str); VIR_ENUM_DECL(qemuCaps); +bool qemuCapsUsedQMP(qemuCapsPtr caps); #endif /* __QEMU_CAPABILITIES_H__*/ diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index eac6553..ff88192 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -1532,6 +1532,7 @@ qemuProcessFindCharDevicePTYsMonitor(virDomainObjPtr vm, virHashTablePtr paths) { bool chardevfmt = qemuCapsGet(caps, QEMU_CAPS_CHARDEV); + int i = 0; if (qemuProcessLookupPTYs(vm->def->serials, vm->def->nserials, paths, chardevfmt) < 0) @@ -1544,8 +1545,23 @@ qemuProcessFindCharDevicePTYsMonitor(virDomainObjPtr vm, if (qemuProcessLookupPTYs(vm->def->channels, vm->def->nchannels, paths, chardevfmt) < 0) return -1; + /* For historical reasons, console[0] can be just an alias + * for serial[0]; That's why we need to update it as well */ + if (vm->def->nconsoles) { + virDomainChrDefPtr chr = vm->def->consoles[0]; + + if (vm->def->nserials && + chr->deviceType == VIR_DOMAIN_CHR_DEVICE_TYPE_CONSOLE && + chr->targetType == VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SERIAL) { + /* yes, the first console is just an alias for serials[0] */ + i = 1; + if (virDomainChrSourceDefCopy(&chr->source, + &((vm->def->serials[0])->source)) < 0) + return -1; + } + } - if (qemuProcessLookupPTYs(vm->def->consoles, vm->def->nconsoles, + if (qemuProcessLookupPTYs(vm->def->consoles + i, vm->def->nconsoles - i, paths, chardevfmt) < 0) return -1; @@ -1650,7 +1666,7 @@ qemuProcessWaitForMonitor(virQEMUDriverPtr driver, virHashTablePtr paths = NULL; qemuDomainObjPrivatePtr priv; - if (pos != -1) { + if (!qemuCapsUsedQMP(caps) && pos != -1) { if ((logfd = qemuDomainOpenLog(driver, vm, pos)) < 0) return -1; -- 1.8.0.2

3 5

[libvirt] [ESX:Error] HTTP 403 error for CURL upload operation
by Ata Bohra 04 Jan '13

04 Jan '13

Hi Everyone, Merry Christmas and Happy New Year! I'm trying to upload disk to ESX 5.0 server using the URL obtained by the server (during VM installation process); I'm using libcurl support in libvirt to upload the disk, but I get this error on file upload:----------------------* About to connect() to <ip> port 443 (#1) * Trying <ip>... * connected * found 153 certificates in /etc/ssl/certs/ca-certificates.crt * server certificate verification SKIPPED * compression: NULL * cipher: AES-128-CBC * MAC: SHA1 > PUT /ha-nfc/52c6d592-7636-67c5-29f3-d5b373be4f42/disk-0.vmdk HTTP/1.1 User-Agent: libvirt-esx Host: <ip> Accept: */* Cookie: vmware_soap_session="521af33d-2bbe-38aa-21e8-13d474ccb023" Content-Type: text/xml; charset=UTF-8 SOAPAction: "urn:vim25" Content-Length: 7021568< HTTP/1.1 403 Forbidden < Date: Sun, 30 Dec 2012 01:28:19 GMT < Connection: close < Content-Type: text; charset=plain < Content-Length: 44 ----------------------To achieve this operation I've added a routine to support file Upload (for ESX driver as currently it only support buffer upload), I verified its functioning my uploading a file using datastore based URL:(http(s)//<ip>/file??dcPath=ha-datacenter?dsName=xxx). CURL options provided by me are; ----------- curl_easy_setopt(curl->handle, CURLOPT_UPLOAD, 1L); curl_easy_setopt(curl->handle, CURLOPT_URL, url); curl_easy_setopt(curl->handle, CURLOPT_READDATA, <data pointer>); curl_easy_setopt(curl->handle, CURLOPT_INFILESIZE_LARGE, (curl_off_t) fileData->size); curl_easy_setopt(curl->handle, CURLOPT_READFUNCTION, <read function>); curl_easy_setopt(curl->handle, CURLOPT_VERBOSE, 1);------------------------ My understanding is there needs to be some tuning done to ESX server to accept this upload operation, please suggest if anyone has faced this issue before. Thanks!Ata

2 3