- Devel - libvirt List Archives

[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

[libvirt] RFC: An "embedded" mode for QEMU/LXC drivers
by Daniel P. Berrange 04 Jan '13

04 Jan '13

This is something I was thinking about a little over the christmas break. I've no intention of implementing this in the immediate future, but wanted to post it while it was fresh in my mind. Historically we have had 2 ways of using the stateful drivers like QEMU/LXC/UML/etc. - "system mode" - privileged libvirtd, one per host, started at boot - "session mode" - unprivileged libvirtd, one per non-root user, autostarted Within context of each daemon, VM name uniqueness is enforced. Operating via the daemon means that all applications connected to libvirtd get the same world view. This single world view is exactly what you want when dealing with server / cloud / desktop virtualization, because it means tools like 'virt-top', 'virt-viewer', 'virsh' can see the same VMs as virt-manager / oVirt / OpenStack / Boxes / etc. Recently we've seen increasing importance of a new use case which I will refer to as "embedded" virtualization. The best example of this use case is libguestfs which has long run a dedicated QEMU instance, but just now switched to using libvirtd. The other use case is virt-sandbox which is doing application confinement using LXC/KVM. In both these cases, operating via libvirtd is sub-optimal. Users of so called "embedded" virtualization, explicitly don't want to have interaction with other libvirt applications. They likely don't even want to expose the concept of virtualization to their users. For them virtualization is intended to be just a hidden impl detail of their application. Some issues which arise when using embedded virtualization - Need to invent sensible unique names for each VM launched. This leads to pollution of logfiles for QEMU instances run. - User sees libguestfs / virt-sandbox VMs in virt-manager / oVirt which they may then try to "manage", breaking libguestfs / etc - Disassociated process context, so if 'virt-sandbox' is placed in a cgroup, the VMs it launches are in a different cgroup. Likewise if custom env variables are set, work is needed to propagate those to VMs. This leads me to wonder whether it is worth exploring the idea of a new type of libvirt connection. - "embed mode" - no libvirtd, driver runs in application context The idea here is to take libvirtd out of the equation and directly use the QEMU driver code in the libvirt.so client / application. Since libvirtd (mostly) uses the same APIs as the public libvirt.so clients, there isn't much required to make this work. - A way for the application to invoke virStateInit for the driver - Application must provide an event loop impl - A way to specify alternative dirs for logs/state/config/etc An application would access this mode using a different path for the driver, and specifying the path to use for logs/state/config etc. eg libguestfs might use qemu:///embed?statedir=/tmp/libguestfsXXXXX/ to get an instance of the QEMU driver that is completely private to itself. One question is whether there should be a single embed instance per process, or whether an application should be allowed to open multiple completely isolated embed instances. The latter might require is to eliminate more static variables in our code. This kind of embedded mode is not without its downsides though - How to access virtual network / storage / node device APIs ? - Extra SELinux policy work to allow each app to have the same kind of privileges that libvirtd has to let it start VMs - How to troubleshoot - can't use things like 'virsh qemu-monitor-command' since the embedded instance is private to the application in question. One answer to the latter question, might be to actually allow the application to expose the same RPC service as libvirtd does. So virsh could connect to libguestfs using qemu:///embed?socketdir=/tmp/libguestfsXXXXX/libvirt-sock For the question of network/storage/node device access, the long term answer is probably to split up the system libvirtd instance into separate pieces. eg a virtnodedeviced, virtnetworkd, virstoraged, virtqemud, virtlxcd, etc. Now a client app would connect to their embedded QEMU instances, but to the shared nodedevice/network/storage daemons. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|

3 2

[libvirt] Build failed in Jenkins: libvirt-build #472
by Jenkins CI 04 Jan '13

04 Jan '13

See <http://honk.sigxcpu.org:8001/job/libvirt-build/472/changes> Changes: [eblake] maint: update to latest gnulib ------------------------------------------ [...truncated 5806 lines...] GEN wchar.h GEN wctype.h make all-am make[3]: Entering directory `<http://honk.sigxcpu.org:8001/job/libvirt-build/ws/gnulib/lib'> CC allocator.lo CC areadlink.lo CC base64.lo CC binary-io.lo CC bitrotate.lo CC c-ctype.lo CC c-strcasecmp.lo CC c-strncasecmp.lo CC c-strcasestr.lo CC careadlinkat.lo CC cloexec.lo CC count-one-bits.lo CC md5.lo CC sha256.lo CC dirname-lgpl.lo CC basename-lgpl.lo CC stripslash.lo CC fd-hook.lo CC freading.lo CC localcharset.lo CC lock.lo CC malloca.lo CC nonblocking.lo CC passfd.lo CC physmem.lo CC pipe2.lo CC sig-handler.lo CC sockets.lo CC stat-time.lo CC stdio.lo CC strnlen1.lo CC sys_socket.lo CC tempname.lo CC threadlib.lo CC unistd.lo CC wctype-h.lo CC xsize.lo CC asnprintf.lo CC fclose.lo CC fcntl.lo CC fflush.lo CC fpurge.lo CC fseek.lo CC fseeko.lo CC ioctl.lo CC mktime.lo CC perror.lo CC printf-args.lo CC printf-parse.lo CC strerror.lo CC strerror_r.lo CC vasnprintf.lo CCLD libgnu.la GEN charset.alias GEN ref-add.sed GEN ref-del.sed make[3]: Leaving directory `<http://honk.sigxcpu.org:8001/job/libvirt-build/ws/gnulib/lib'> make[2]: Leaving directory `<http://honk.sigxcpu.org:8001/job/libvirt-build/ws/gnulib/lib'> Making all in include make[2]: Entering directory `<http://honk.sigxcpu.org:8001/job/libvirt-build/ws/include'> Making all in libvirt make[3]: Entering directory `<http://honk.sigxcpu.org:8001/job/libvirt-build/ws/include/libvirt'> make[3]: Nothing to be done for `all'. make[3]: Leaving directory `<http://honk.sigxcpu.org:8001/job/libvirt-build/ws/include/libvirt'> make[3]: Entering directory `<http://honk.sigxcpu.org:8001/job/libvirt-build/ws/include'> make[3]: Nothing to be done for `all-am'. make[3]: Leaving directory `<http://honk.sigxcpu.org:8001/job/libvirt-build/ws/include'> make[2]: Leaving directory `<http://honk.sigxcpu.org:8001/job/libvirt-build/ws/include'> Making all in src make[2]: Entering directory `<http://honk.sigxcpu.org:8001/job/libvirt-build/ws/src'> GEN libvirt.syms GEN libvirt.def make all-am make[3]: Entering directory `<http://honk.sigxcpu.org:8001/job/libvirt-build/ws/src'> CC libvirt_util_la-viralloc.lo CC libvirt_util_la-virarch.lo CC libvirt_util_la-viratomic.lo CC libvirt_util_la-viraudit.lo CC libvirt_util_la-virauth.lo CC libvirt_util_la-virauthconfig.lo CC libvirt_util_la-virbitmap.lo CC libvirt_util_la-virbuffer.lo CC libvirt_util_la-vircgroup.lo CC libvirt_util_la-vircommand.lo CC libvirt_util_la-virconf.lo CC libvirt_util_la-virdbus.lo CC libvirt_util_la-virdnsmasq.lo CC libvirt_util_la-virebtables.lo CC libvirt_util_la-virerror.lo CC libvirt_util_la-virevent.lo CC libvirt_util_la-vireventpoll.lo CC libvirt_util_la-virfile.lo CC libvirt_util_la-virhash.lo CC libvirt_util_la-virhashcode.lo CC libvirt_util_la-virhook.lo CC libvirt_util_la-virinitctl.lo CC libvirt_util_la-viriptables.lo CC libvirt_util_la-virjson.lo CC libvirt_util_la-virkeycode.lo CC libvirt_util_la-virkeyfile.lo CC libvirt_util_la-virlockspace.lo CC libvirt_util_la-virlog.lo CC libvirt_util_la-virmacaddr.lo CC libvirt_util_la-virnetdev.lo CC libvirt_util_la-virnetdevbandwidth.lo CC libvirt_util_la-virnetdevbridge.lo CC libvirt_util_la-virnetdevmacvlan.lo CC libvirt_util_la-virnetdevopenvswitch.lo CC libvirt_util_la-virnetdevtap.lo CC libvirt_util_la-virnetdevveth.lo CC libvirt_util_la-virnetdevvlan.lo CC libvirt_util_la-virnetdevvportprofile.lo CC libvirt_util_la-virnetlink.lo CC libvirt_util_la-virnodesuspend.lo CC libvirt_util_la-virobject.lo CC libvirt_util_la-virpci.lo CC libvirt_util_la-virpidfile.lo CC libvirt_util_la-virprocess.lo CC libvirt_util_la-virrandom.lo CC libvirt_util_la-virsexpr.lo CC libvirt_util_la-virsocketaddr.lo CC libvirt_util_la-virstatslinux.lo CC libvirt_util_la-virstoragefile.lo CC libvirt_util_la-virstring.lo CC libvirt_util_la-virsysinfo.lo CC libvirt_util_la-virthread.lo CC libvirt_util_la-virthreadpool.lo CC libvirt_util_la-virtime.lo CC libvirt_util_la-virtypedparam.lo CC libvirt_util_la-virusb.lo CC libvirt_util_la-viruri.lo CC libvirt_util_la-virutil.lo CC libvirt_util_la-viruuid.lo CC libvirt_util_la-virxml.lo CCLD libvirt_util.la CC libvirt_conf_la-netdev_bandwidth_conf.lo CC libvirt_conf_la-netdev_vport_profile_conf.lo CC libvirt_conf_la-netdev_vlan_conf.lo CC libvirt_conf_la-capabilities.lo CC libvirt_conf_la-domain_conf.lo CC libvirt_conf_la-domain_audit.lo CC libvirt_conf_la-domain_nwfilter.lo CC libvirt_conf_la-snapshot_conf.lo CC libvirt_conf_la-domain_event.lo CC libvirt_conf_la-network_conf.lo CC libvirt_conf_la-nwfilter_params.lo CC libvirt_conf_la-nwfilter_ipaddrmap.lo CC libvirt_conf_la-nwfilter_conf.lo CC libvirt_conf_la-node_device_conf.lo CC libvirt_conf_la-storage_conf.lo CC libvirt_conf_la-storage_encryption_conf.lo CC libvirt_conf_la-interface_conf.lo CC libvirt_conf_la-secret_conf.lo CC libvirt_conf_la-cpu_conf.lo CC libvirt_conf_la-virconsole.lo CC libvirt_conf_la-device_conf.lo CCLD libvirt_conf.la CC libvirt_cpu_la-cpu.lo CC libvirt_cpu_la-cpu_generic.lo CC libvirt_cpu_la-cpu_x86.lo CC libvirt_cpu_la-cpu_s390.lo CC libvirt_cpu_la-cpu_arm.lo CC libvirt_cpu_la-cpu_map.lo CC libvirt_cpu_la-cpu_powerpc.lo CCLD libvirt_cpu.la CC libvirt_vmx_la-vmx.lo CCLD libvirt_vmx.la CC libvirt_xenxs_la-xen_sxpr.lo CC libvirt_xenxs_la-xen_xm.lo CCLD libvirt_xenxs.la CC libvirt_driver_la-driver.lo CC libvirt_driver_la-datatypes.lo CC libvirt_driver_la-fdstream.lo CC libvirt_driver_la-nodeinfo.lo CC libvirt_driver_la-libvirt.lo CC libvirt_driver_la-lock_manager.lo CC libvirt_driver_la-lock_driver_nop.lo CC libvirt_driver_la-domain_lock.lo CCLD libvirt_driver.la CC libvirt_driver_test_la-test_driver.lo CCLD libvirt_driver_test.la CC libvirt_driver_remote_la-remote_driver.lo CC libvirt_driver_remote_la-remote_protocol.lo CC libvirt_driver_remote_la-qemu_protocol.lo CC libvirt_net_rpc_client_la-virnetclientprogram.lo CC libvirt_net_rpc_client_la-virnetclientstream.lo CC libvirt_net_rpc_client_la-virnetclient.lo CCLD libvirt-net-rpc-client.la CC libvirt_net_rpc_server_la-virnetserverprogram.lo CC libvirt_net_rpc_server_la-virnetserverservice.lo CC libvirt_net_rpc_server_la-virnetserverclient.lo CC libvirt_net_rpc_server_la-virnetservermdns.lo CC libvirt_net_rpc_server_la-virnetserver.lo CCLD libvirt-net-rpc-server.la CC libvirt_net_rpc_la-virnetmessage.lo CC libvirt_net_rpc_la-virnetprotocol.lo CC libvirt_net_rpc_la-virnetsocket.lo CC libvirt_net_rpc_la-virnettlscontext.lo CC libvirt_net_rpc_la-virkeepaliveprotocol.lo CC libvirt_net_rpc_la-virkeepalive.lo CC libvirt_net_rpc_la-virnetsaslcontext.lo CCLD libvirt-net-rpc.la CCLD libvirt_driver_remote.la CC libvirt_driver_openvz_la-openvz_conf.lo CC libvirt_driver_openvz_la-openvz_driver.lo CC libvirt_driver_openvz_la-openvz_util.lo CCLD libvirt_driver_openvz.la CC libvirt_driver_vmware_la-vmware_driver.lo CC libvirt_driver_vmware_la-vmware_conf.lo CCLD libvirt_driver_vmware.la CC libvirt_driver_vbox_la-vbox_glue.lo CC libvirt_driver_vbox_la-vbox_driver.lo CC libvirt_driver_vbox_la-vbox_V2_2.lo CC libvirt_driver_vbox_la-vbox_V3_0.lo CC libvirt_driver_vbox_la-vbox_V3_1.lo CC libvirt_driver_vbox_la-vbox_V3_2.lo CC libvirt_driver_vbox_la-vbox_V4_0.lo CC libvirt_driver_vbox_la-vbox_V4_1.lo CCLD libvirt_driver_vbox.la CC libvirt_security_manager_la-security_driver.lo CC libvirt_security_manager_la-security_nop.lo CC libvirt_security_manager_la-security_stack.lo CC libvirt_security_manager_la-security_dac.lo CC libvirt_security_manager_la-security_manager.lo CC libvirt_security_manager_la-security_selinux.lo CCLD libvirt_security_manager.la CCLD libvirt.la ./.libs/libvirt_util.a(libvirt_util_la-virnetdevtap.o): In function `rpl_fwrite': <http://honk.sigxcpu.org:8001/job/libvirt-build/ws/src/../gnulib/lib/stdio.h>:903: multiple definition of `rpl_fwrite' ./.libs/libvirt_util.a(libvirt_util_la-virnetdev.o):<http://honk.sigxcpu.org:8001/job/libvirt-build/ws/src/../gnulib/lib/stdio.h>:903: first defined here ./.libs/libvirt_util.a(libvirt_util_la-virnetlink.o): In function `rpl_fwrite': <http://honk.sigxcpu.org:8001/job/libvirt-build/ws/src/../gnulib/lib/stdio.h>:903: multiple definition of `rpl_fwrite' ./.libs/libvirt_util.a(libvirt_util_la-virnetdev.o):<http://honk.sigxcpu.org:8001/job/libvirt-build/ws/src/../gnulib/lib/stdio.h>:903: first defined here ../gnulib/lib/.libs/libgnu.a(stdio.o): In function `rpl_fwrite': <http://honk.sigxcpu.org:8001/job/libvirt-build/ws/gnulib/lib/stdio.h>:903: multiple definition of `rpl_fwrite' ./.libs/libvirt_util.a(libvirt_util_la-virnetdev.o):<http://honk.sigxcpu.org:8001/job/libvirt-build/ws/src/../gnulib/lib/stdio.h>:903: first defined here collect2: error: ld returned 1 exit status make[3]: *** [libvirt.la] Error 1 make[3]: Leaving directory `<http://honk.sigxcpu.org:8001/job/libvirt-build/ws/src'> make[2]: *** [all] Error 2 make[2]: Leaving directory `<http://honk.sigxcpu.org:8001/job/libvirt-build/ws/src'> make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `<http://honk.sigxcpu.org:8001/job/libvirt-build/ws/'> make: *** [all] Error 2 Build step 'Execute shell' marked build as failure

4 12

[libvirt] Jenkins build is back to normal : libvirt-syntax-check #437
by Jenkins CI 03 Jan '13

03 Jan '13

See <http://honk.sigxcpu.org:8001/job/libvirt-syntax-check/437/>

1 0

[libvirt] Build failed in Jenkins: libvirt-check #441
by Jenkins CI 03 Jan '13

03 Jan '13

See <http://honk.sigxcpu.org:8001/job/libvirt-check/441/> ------------------------------------------ Started by upstream project "libvirt-build" build number 482 [workspace] $ /bin/sh -xe /tmp/hudson1110434311877203261.sh + make check Making check in gnulib/lib make[1]: Entering directory `<http://honk.sigxcpu.org:8001/job/libvirt-check/ws/gnulib/lib'> make check-am make[2]: Entering directory `<http://honk.sigxcpu.org:8001/job/libvirt-check/ws/gnulib/lib'> make[2]: Nothing to be done for `check-am'. make[2]: Leaving directory `<http://honk.sigxcpu.org:8001/job/libvirt-check/ws/gnulib/lib'> make[1]: Leaving directory `<http://honk.sigxcpu.org:8001/job/libvirt-check/ws/gnulib/lib'> Making check in include make[1]: Entering directory `<http://honk.sigxcpu.org:8001/job/libvirt-check/ws/include'> Making check in libvirt make[2]: Entering directory `<http://honk.sigxcpu.org:8001/job/libvirt-check/ws/include/libvirt'> make[2]: Nothing to be done for `check'. make[2]: Leaving directory `<http://honk.sigxcpu.org:8001/job/libvirt-check/ws/include/libvirt'> make[2]: Entering directory `<http://honk.sigxcpu.org:8001/job/libvirt-check/ws/include'> make[2]: Nothing to be done for `check-am'. make[2]: Leaving directory `<http://honk.sigxcpu.org:8001/job/libvirt-check/ws/include'> make[1]: Leaving directory `<http://honk.sigxcpu.org:8001/job/libvirt-check/ws/include'> Making check in src /bin/bash: line 9: 28650 Segmentation fault make $local_target make: *** [check-recursive] Error 1 Build step 'Execute shell' marked build as failure

1 0