- 16 6月, 2012 1 次提交
-
-
由 Cole Robinson 提交于
-
- 15 6月, 2012 28 次提交
-
-
由 Daniel P. Berrange 提交于
(cherry picked from commit f94d9c57)
-
由 Daniel P. Berrange 提交于
* libvirt.pc.in: Add missing '/api/' in path * libvirt.spec.in, mingw32-libvirt.spec.in: s/apis/api/ (cherry picked from commit 5452e88c)
-
由 Wen Congyang 提交于
If we migrate to fd, spec->fwdType is not MIGRATION_FWD_DIRECT, we will close spec->dest.fd.local in qemuMigrationRun(). So we should set spec->dest.fd.local to -1 in qemuMigrationRun(). Bug present since 0.9.5 (commit 32617617). (cherry picked from commit b19c236d)
-
由 Wen Congyang 提交于
We should not set *outfd or *errfd if virExecWithHook() failed because the caller may close these fds. Bug present since v0.4.5 (commit 60ed1d2a). (cherry picked from commit 746ff701)
-
由 Eric Blake 提交于
Wen Congyang reported that we have a double-close bug if we fail virFDStreamOpenInternal, since childfd duplicated one of the fds[] array contents. In truth, since we always transfer both members of fds to other variables, we should close the fds through those other names, and just use fds[] for pipe(). Bug present since 0.9.0 (commit e886237a). * src/fdstream.c (virFDStreamOpenFileInternal): Swap scope of childfd and fds[], to avoid a double close. (cherry picked from commit f3cfc7c8)
-
由 Eric Blake 提交于
KAMEZAWA Hiroyuki reported a nasty double-free bug when virCommand is used to convert a string into input to a child command. The problem is that the poll() loop of virCommandProcessIO would close() the write end of the pipe in order to let the child see EOF, then the caller virCommandRun() would also close the same fd number, with the second close possibly nuking an fd opened by some other thread in the meantime. This in turn can have all sorts of bad effects. The bug has been present since the introduction of virCommand in commit f16ad06f. This is based on his first attempt at a patch, at https://bugzilla.redhat.com/show_bug.cgi?id=823716 * src/util/command.c (_virCommand): Drop inpipe member. (virCommandProcessIO): Add argument, to avoid closing caller's fd without informing caller. (virCommandRun, virCommandNewArgs): Adjust clients. (cherry picked from commit da831afc) Conflicts: src/util/command.c
-
由 Wen Congyang 提交于
virCommandRunAsync() will set errfd if it succeed. We should close it if virFDStreamOpenInternal() fails. (cherry picked from commit 655cffa0)
-
由 Wen Congyang 提交于
If the system does not support bypass cache, we will close fd, but it is uninitialized. (cherry picked from commit 0a045f01)
-
由 Daniel P. Berrange 提交于
The uhci1, uhci2, uhci3 companion controllers for ehci1 must have a master start port set. Since this value is predictable we should set it automatically if the app does not supply it (cherry picked from commit 03b804a2)
-
由 Daniel P. Berrange 提交于
Currently each USB2 companion controller gets put on a separate PCI slot. Not only is this wasteful of PCI slots, but it is not in compliance with the spec for USB2 controllers. The master echi1 and all companion controllers should be in the same slot, with echi1 in function 7, and uhci1-3 in functions 0-2 respectively. * src/qemu/qemu_command.c: Special case handling of USB2 controllers to apply correct pci slot assignment * tests/qemuxml2argvdata/qemuxml2argv-usb-ich9-ehci-addr.args, tests/qemuxml2argvdata/qemuxml2argv-usb-ich9-ehci-addr.xml: Expand test to cover automatic slot assignment (cherry picked from commit 1ebd52cb) Conflicts: tests/qemuxml2xmltest.c
-
由 Daniel P. Berrange 提交于
The virDomainDeviceInfoIsSet API was only checking if an address or alias was set in the struct. Thus if only a rom bar setting / filename, boot index, or USB master value was set, they could be accidentally dropped when formatting XML (cherry picked from commit 2c195fdb) Conflicts: src/conf/domain_conf.c (crobinso: some elements aren't in maint branch, drop them)
-
由 Serge E. Hallyn 提交于
The glibc ones (intentionally) cannot handle ptys opened in a devpts not mounted at /dev/pts. Drop the (un-exported, unused) virFileOpenTtyAt. Signed-off-by: NSerge Hallyn <serge.hallyn@canonical.com> Signed-off-by: NEric Blake <eblake@redhat.com> (cherry picked from commit 80710c69) Conflicts: src/lxc/lxc_controller.c
-
由 Stefan Bader 提交于
When using the xm/xend stack to manage instances there is a bug that causes the emulated interfaces to be unusable when the vif config contains type=ioemu. The current code already has a special quirk to not use this keyword if no specific model is given for the emulated NIC (defaulting to rtl8139). Essentially it works because regardless of the type argument,i the Xen stack always creates emulated and paravirt interfaces and lets the guest decide which one to use. So neither xl nor xm stack actually require the type keyword for emulated NICs. Signed-off-by: NStefan Bader <stefan.bader@canonical.com> (cherry picked from commit 10c31135)
-
由 Stefan Bader 提交于
On newer xend (v3.x and after) there is no state and domid reported for inactive domains. When initially creating connections this is handled in various places by assigning domain->id = -1. But once an instance has been running, the id is set to the current domain id. And it does not change when the instance is shut down. So when querying the domain info, the hypervisor driver, which gets asked first will indicate it cannot find information, then the xend driver is asked and will set the status to NOSTATE because it checks for the -1 domain id. Checking domain/status for 0 seems to be more reliable for that. One note: I am not sure whether the domain->id also should get set back to -1 whenever any sub-driver thinks the instance is no longer running. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=746007 BugLink: http://bugs.launchpad.net/bugs/929626Signed-off-by: NStefan Bader <stefan.bader@canonical.com> (cherry picked from commit 26e9ef47) (crobinso: Add Stefan to AUTHORS. maint only)
-
由 Philipp Hahn 提交于
filename is not initialized to NULL while it's unconditionally freed in the error path. Signed-off-by: NPhilipp Hahn <hahn@univention.de> (cherry picked from commit 360afebf)
-
由 Philipp Hahn 提交于
On CentOS5 with xen-3.0.3: Program received signal SIGSEGV, Segmentation fault. virFree (ptrptr=0x8) at util/memory.c:310 310 free(*(void**)ptrptr); (gdb) bt #0 virFree (ptrptr=0x8) at util/memory.c:310 #1 0x00002aaaaae167c8 in xenXMDomainDefineXML (conn=0x694e80, xml=0x6b2ce0 "P\fk") at xen/xm_internal.c:1199 #2 0x00002aaaaae070d7 in xenUnifiedDomainDefineXML (conn=0x8, xml=0x6ac040 "<domain type='xen'>\n <name>pv</name>\n <uuid>20291bc0-453a-4d6c-c6ac-4e5af63b932c</uuid>\n <memory>1048576</memory>\n <currentMemory>1048576</currentMemory>\n <vcpu>1</vcpu>\n <os>\n <type arch='x8"...) at xen/xen_driver.c:1524 #3 0x00002aaaaada7803 in virDomainDefineXML (conn=0x694e80, xml=0x6ac040 "<domain type='xen'>\n <name>pv</name>\n <uuid>20291bc0-453a-4d6c-c6ac-4e5af63b932c</uuid>\n <memory>1048576</memory>\n <currentMemory>1048576</currentMemory>\n <vcpu>1</vcpu>\n <os>\n <type arch='x8"...) at libvirt.c:7823 #4 0x0000000000426173 in cmdEdit (ctl=0x7fffffffb8e0, cmd=<value optimized out>) at virsh.c:14882 #5 0x000000000041c9ce in vshCommandRun (ctl=0x7fffffffb8e0, cmd=0x658c50) at virsh.c:17712 #6 0x000000000042c3b9 in main (argc=1, argv=<value optimized out>) at virsh.c:19317 Signed-off-by: NPhilipp Hahn <hahn@univention.de> (cherry picked from commit 046b0a69)
-
由 Cole Robinson 提交于
It just doesn't really make sense and confuses virt-manager (cherry picked from commit efb0839c) Conflicts: src/xenxs/xen_sxpr.c
-
由 Guido Günther 提交于
On xen 4.1 I observed configurations that look like: (image (hvm (kernel '') (loader '/foo/bar') )) The kernel element is there but unset. This leads to an empty <kernel/> element in the XML and even worse makes us skip the boot order parsing and therefore not emit a <boot device='$dev>'/> element which breaks CD booting. (cherry picked from commit dca1a6b4)
-
由 Guido Günther 提交于
otherwise a missing UUID in a domain config just shows: error: An error occurred, but the cause is unknown Now we have: error: configuration file syntax error: config value uuid was missing (cherry picked from commit c5d2984c)
-
由 Guido Günther 提交于
(cherry picked from commit 6dd8532d)
-
由 Radu Caragea 提交于
The stream lock is unlocked twice instead of being locked and then unlocked. Probably a typo. (cherry picked from commit 107f51b6) Conflicts: AUTHORS
-
由 Peter Krempa 提交于
This patch adds another callback to a FDstream object. The original callback is used by the daemon stream driver to handle events. This callback is called if and only if the stream is about to be closed. This might be used to handle cleanup steps after a fdstream exits. This will be used later on in ensuring mutually exclusive access to consoles. * src/fdstream.c: - emit the callback, when stream is being closed - add data structures needed to handle the callback - add function to register callback * src/fdstream.h: - define function prototypes for the callback (cherry picked from commit 0c4bfdda)
-
由 Peter Krempa 提交于
This patch causes the fdstream driver to call the stream event callback if virStreamAbort() is called on a stream using this driver. A remote handler for a stream can only detect changes via stream events, so this event callback is necessary in order to enable a daemon to abort a stream in such a way that the client will see the change. * src/fdstream.c: - modify close function to call stream event callback (cherry picked from commit 95fdc1bc)
-
由 Daniel P. Berrange 提交于
Due to the asynchronous nature of streams, we might continue to receive some stream packets from the server even after we have shutdown the stream on the client side. These should be discarded silently, rather than raising an error in the RPC layer. * src/rpc/virnetclient.c: Discard stream data silently (cherry picked from commit a38710bd)
-
由 Daniel P. Berrange 提交于
Very occasionally the sequence of events from poll would result in getting a HANGUP on its own, instead of a HANGUP+READABLE at the same time. In the former case we would send back an error event to the client, but never send the empty packet to indicate EOF. (cherry picked from commit 1d46b2e9)
-
由 Daniel P. Berrange 提交于
If we receive an error on the stream, set the EOF marker so that any further (bogus) incoming data is dropped. * src/rpc/virnetclientstream.c: Set EOF on stream (cherry picked from commit bc61aa12)
-
由 Marc-André Lureau 提交于
Do not crash if virStreamFinish is called after error. ==11000== Invalid read of size 4 ==11000== at 0x373A8099A0: pthread_mutex_lock (pthread_mutex_lock.c:51) ==11000== by 0x4C7CADE: virMutexLock (threads-pthread.c:85) ==11000== by 0x4D57C31: virNetClientStreamRaiseError (virnetclientstream.c:203) ==11000== by 0x4D385E4: remoteStreamFinish (remote_driver.c:3541) ==11000== by 0x4D182F9: virStreamFinish (libvirt.c:14157) ==11000== by 0x40FDC4: cmdScreenshot (virsh.c:3075) ==11000== by 0x42BA40: vshCommandRun (virsh.c:14922) ==11000== by 0x42ECCA: main (virsh.c:16381) ==11000== Address 0x59b86c0 is 16 bytes inside a block of size 216 free'd ==11000== at 0x4A06928: free (vg_replace_malloc.c:427) ==11000== by 0x4C69E2B: virFree (memory.c:310) ==11000== by 0x4D57B56: virNetClientStreamFree (virnetclientstream.c:184) ==11000== by 0x4D3DB7A: remoteDomainScreenshot (remote_client_bodies.h:1812) ==11000== by 0x4CFD245: virDomainScreenshot (libvirt.c:2903) ==11000== by 0x40FB73: cmdScreenshot (virsh.c:3029) ==11000== by 0x42BA40: vshCommandRun (virsh.c:14922) ==11000== by 0x42ECCA: main (virsh.c:16381) (cherry picked from commit be5ec766)
-
由 Daniel P. Berrange 提交于
commit 984840a2 removed the notification of waiting calls when VIR_NET_CONTINUE messages arrive. This was to fix the case of a virStreamAbort() call being prematurely notified of completion. The problem is that sometimes there are dummy calls from a virStreamRecv() call waiting that *do* need to be notified. These dummy calls should have a status VIR_NET_CONTINUE. So re-add the notification upon VIR_NET_CONTINUE, but only if the waiter also has a status of VIR_NET_CONTINUE. * src/rpc/virnetclient.c: Notify waiting call if stream data arrives * src/rpc/virnetclientstream.c: Mark dummy stream read packet with status VIR_NET_CONTINUE (cherry picked from commit cb610092)
-
- 18 5月, 2012 10 次提交
-
-
由 Eric Blake 提交于
Ever since commit c964b6aa, make was trying to find the timestamp of '""./apibuild.py".stamp"', but only touching 'apibuild.py.stamp', and thus always rebuilding. Reported by Daniel P. Berrange. * docs/Makefile.am (APIBUILD, APIBUILD_STAMP): Omit bogus quotes. (cherry picked from commit c0057d9a)
-
由 Daniel P. Berrange 提交于
Language bindings may well want to use the libvirt-api.xml and libvirt-qemu-api.xml files to either auto-generate themselves, or sanity check the manually written bindings for completeness. Currently these XML files are not installed as standard, merely ending up as a %doc file in the RPM. This changes them to be installed into $prefix/share/libvirt/apis/ The *-refs.xml files are not installed, since those are only useful during generation of the online API doc files. The pkg-config file is enhanced so that you can query the install location of the API files. eg # pkg-config --variable=libvirt_qemu_api libvirt /home/berrange/builder/i686-pc-mingw32/sys-root/mingw/share/libvirt/libvirt-qemu-api.xml * docs/Makefile.am: Install libvirt-api.xml & libvirt-qemu-api.xml * libvirt.pc.in: Add vars for querying API install location * libvirt.spec.in, mingw32-libvirt.spec.in: Include API XML files (cherry picked from commit c95c90ee)
-
由 Eric Blake 提交于
On rawhide, gcc is new enough to output new DWARF information that pdwtags has not yet learned, but the resulting 'make check' output was rather confusing: $ make -C src check ... GEN virkeepaliveprotocol-structs die__process_function: DW_TAG_INVALID (0x4109) @ <0x58c> not handled! WARNING: your pdwtags program is too old WARNING: skipping the virkeepaliveprotocol-structs test WARNING: install dwarves-1.3 or newer ... $ pdwtags --version v1.9 I've filed the pdwtags deficiency as https://bugzilla.redhat.com/show_bug.cgi?id=772358 * src/Makefile.am (PDWTAGS): Don't leave -t file behind on version mismatch. Soften warning message, since 1.9 is newer than 1.3. Don't leak stderr from broken version. (cherry picked from commit cf6d3625)
-
由 Eric Blake 提交于
CC libvirt_driver_xenapi_la-xenapi_driver.lo xenapi/xenapi_driver.c: In function 'xenapiDomainGetVcpus': xenapi/xenapi_driver.c:1209:21: error: variable 'cpus' set but not used [-Werror=unused-but-set-variable] * src/xenapi/xenapi_driver.c (xenapiDomainGetVcpus): Silence compiler warning. (cherry picked from commit 787b0a22)
-
由 Eric Blake 提交于
I got these distcheck failures with sanlock enabled: ERROR: files left in build directory after distclean: ./tools/virt-sanlock-cleanup ./src/locking/qemu-sanlock.conf * src/Makefile.am (DISTCLEANFILES) [HAVE_SANLOCK]: Clean built file. * tools/Makefile.am (DISTCLEANFILES): Likewise. (cherry picked from commit c654ba88) plus tweak to DISTCLEANFILES from commit ddf3bd32, although that full commit is too invasive to backport
-
由 Eric Blake 提交于
I am getting this failure with 'make distcheck': GEN ../../src/remote_protocol-structs /bin/sh: ../../src/remote_protocol-structs-t: Permission denied make[4]: *** [../../src/remote_protocol-structs] Error 1 since it attempts a sub-run of a VPATH 'make check' where $(srcdir) is intentionally read-only. I'm not sure which commit introduced the problem, although I suspect it was around 62dee6fa when I refactored protocol struct checking to be more powerful. $(@F) is required by POSIX, and although it is not yet portable to all make implementations, we already require GNU make. * src/Makefile.am (PDWTAGS): Generate temp file into current directory, since $(srcdir) is read-only during distcheck. (cherry picked from commit 2d45ae5a)
-
由 Cole Robinson 提交于
We were using the libvirt release version (like 0.9.11) and not the configure version (which for stable releases is 0.9.11.X) Most other places got this right so hopefully that's all the fallout from the version format change :) Signed-off-by: NCole Robinson <crobinso@redhat.com> (cherry picked from commit 002b18b3)
-
由 Cole Robinson 提交于
Use a witness file approach like we do for python/generator.py, as suggested by Eric. Fixes the build issue reported here: https://www.redhat.com/archives/libvir-list/2012-April/msg01435.htmlSigned-off-by: NCole Robinson <crobinso@redhat.com> (cherry picked from commit c964b6aa) Conflicts: .gitignore - context with other commits not backported
-
由 Cole Robinson 提交于
Since for stable releases, some test files were over the 99 char limit for traditional tar filenames. Suggested by Osier here: https://www.redhat.com/archives/libvir-list/2012-April/msg01435.htmlSigned-off-by: NCole Robinson <crobinso@redhat.com> (cherry picked from commit ddd6bef4)
-
由 Daniel P. Berrange 提交于
Every now & then, with parallel builds, we get a failure to validate hvsupport.html.in. I eventually noticed that this is because we get 2 instances of the generator running at once. We already list hvsupport.html.in in BUILT_SOURCES but this was not working. It turns out the flaw is that we were adding deps to the 'all:' target instead of the 'all-am:' target. BUILT_SOURCES is a dep of 'all', so any custom targets written in Makefile.am must use 'all-am:' so that they don't get run until BUILT_SOURCES are completely generated * docs/Makefile.am: s/all/all-am/ (cherry picked from commit 4f4b496e) (cherry picked from commit 26fdec39)
-
- 17 5月, 2012 1 次提交
-
-
由 Eric Blake 提交于
I hit a VERY weird testsuite failure on rawhide, which included _binary_ output to stderr, followed by a hang waiting for me to type something! (Here, using ^@ for NUL): $ ./commandtest TEST: commandtest WARNING: gnome-keyring:: couldn't send data: Bad file descriptor .WARNING: gnome-keyring:: couldn't send data: Bad file descriptor .WARNING: gnome-keyring:: couldn't send data: Bad file descriptor WARNING: gnome-keyring:: couldn't send data: Bad file descriptor .8^@^@^@8^@^@^@^A^@^@^@^Bay^A^@^@^@)PRIVATE-GNOME-KEYRING-PKCS11-PROTOCOL-V-1 I finally traced it to the fact that gnome-keyring, called via gnutls_global_init which is turn called by virNetTLSInit, opens an internal fd that it expects to communicate to via a pthread_atfork handler (never mind that it violates POSIX by using non-async-signal-safe functions in that handler: https://bugzilla.redhat.com/show_bug.cgi?id=772320). Our problem stems from the fact that we pulled the rug out from under the library's expectations by closing an fd that it had just opened. While we aren't responsible for fixing the bugs in that pthread_atfork handler, we can at least avoid the bugs by not closing the fd in the first place. * tests/commandtest.c (mymain): Avoid closing fds that were opened by virInitialize. (cherry picked from commit 74ff5750)
-