- 15 6月, 2012 10 次提交
-
-
由 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 20 次提交
-
-
由 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)
-
由 Cole Robinson 提交于
On F16 at least, empty volume groups don't have a directory under /dev. The directory only appears once a logical volume is created. This tickles some behavior in BackendStablePath which ends with libvirt sleeping for 5 seconds while waiting for the directory to appear. This causes all sorts of problems for the virStorageVolLookupByPath API which virtinst uses, even if trying to resolve a path that is independent of the logical pool. In reality we don't even need to do that checking since logical pools always have a stable target path. Short circuit the polling in that case. Fixes bug 782261 (cherry picked from commit 275155f6)
-
由 Peter Krempa 提交于
The init script for the daemon requests to start HAL although it has been deprecated long time ago. This patch removes the dependency. (cherry picked from commit 2dcca3ec)
-
由 Michal Privoznik 提交于
It is a good practise to set revents to zero before doing any poll(). Moreover, we should check if event we waited for really occurred or if any of fds we were polling on didn't encountered hangup. (cherry picked from commit 06b9c5b9)
-
由 Michal Privoznik 提交于
As this is needed. Although some functions check for domain being active before obtaining job, we need to check it after, because obtaining job unlocks domain object, during which a state of domain can be changed. (cherry picked from commit 9bc9999b)
-
由 Daniel P. Berrange 提交于
For unknown reasons, the shunloadtest will crash on Fedora 16 inside dlopen() (gdb) bt #0 0x00000000000050e6 in ?? () #1 0x00007ff61a77b9d5 in floor () from /lib64/libm.so.6 #2 0x00007ff61e522963 in _dl_relocate_object () from /lib64/ld-linux-x86-64.so.2 #3 0x00007ff61e5297e6 in dl_open_worker () from /lib64/ld-linux-x86-64.so.2 #4 0x00007ff61e525006 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2 #5 0x00007ff61e52917a in _dl_open () from /lib64/ld-linux-x86-64.so.2 #6 0x00007ff61e0f6f26 in dlopen_doit () from /lib64/libdl.so.2 #7 0x00007ff61e525006 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2 #8 0x00007ff61e0f752f in _dlerror_run () from /lib64/libdl.so.2 #9 0x00007ff61e0f6fc1 in dlopen@@GLIBC_2.2.5 () from /lib64/libdl.so.2 #10 0x0000000000400a15 in main (argc=<optimized out>, argv=<optimized out>) at shunloadtest.c:105 Changing from RTLD_NOW to RTLD_LAZY avoids this problem, but quite possibly does not fix the root cause. * shunloadtest.c: s/NOW/LAZY/ (cherry picked from commit 24d97928)
-
由 Eric Blake 提交于
Over time, Fedora and RHEL RPMs have often backported upstream patches that touched configure.ac and/or Makefile.am; this necessitates rerunning the autotools for the patch to be effective. Making this a one-liner spec tweak will make it easier for future backports to pull patches without having to find all the places to touch to properly use the autotools. Meanwhile, there have been historical instances where an update in the autotools caused FTBFS situations, so this is not on by default. * libvirt.spec.in (enable_autotools): New variable, default off. (BuildRequires): Conditionally add autotools. (%build): Conditionally use them before configure. * mingw32-libvirt.spec.in: Likewise. (cherry picked from commit 9c417636) Conflicts: mingw32-libvirt.spec.in - caused by change in context
-
由 Laine Stump 提交于
One of the xml tests in the test suite was created using a now-deprecated qemu machine type ("fedora-13", which was only ever valid for Fedora builds of qemu). Although strictly speaking it's not necessary to replace it with an actual supported qemu machine type (since the xml in question is never actually sent to qemu), this patch changes it to the actually-supported "pc-0.13" just for general tidiness. (Also, on some Fedora builds which contain a special patch to rid the world of "fedora-13", having it mentioned in the test suite will cause make check to fail.) (cherry picked from commit 7204a9fd)
-
由 Laine Stump 提交于
This patch addresses https://bugzilla.redhat.com/show_bug.cgi?id=760442 When a network has any forward type other than route, nat or none, the network configuration should be done completely external to libvirt - libvirt only uses these types to allow configuring guests in a manner that isn't tied to a specific host (all the host-specific information, in particular interface names, port profile data, and bandwidth configuration is in the network definition, and the guest configuration only references it). Due to a bug in the bridge network driver, libvirt was adding iptables rules for networks with forward type='bridge' etc. any time libvirtd was restarted while one of these networks was active. This patch eliminates that error by only "reloading" iptables rules if forward type is route, nat, or none. (cherry picked from commit ae1232b2)
-
由 Eric Blake 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=738725 Commit ecd8725c tried to silence a spurious warning on the initial libvirt install, and commit ba6cbb18 tried to fix up the logic to the correct Fedora version, but the warning was still present due to a logic bug: since %{fedora} and %{rhel} are never simulatanously set, then 0%{rhel} <= 6 made the %if always true. Checking for minimum versions (via >=) is okay, but checking for maximum versions (via <=) requires a prerequisite test that the platform being tested is non-zero. Also fix a bogus setting of with_libxl (although we previously hard-code with_libxl to 0 for rhel earlier in the file, so this was not as severe a bug). * libvirt.spec.in (with_cgconfig): Don't enable cgconfig on F16. (cherry picked from commit 3b95f284)
-
由 Eric Blake 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=694403 reports that the specfile is incorrectly checking for a running libvirt-guests service. For example, $ LC_ALL=es_ES chkconfig --list libvirt-guests libvirt-guests 0:desactivado 1:desactivado 2:desactivado 3:activo 4:activo 5:activo 6:desactivado will fail to find 5:on, even though it is active. But chkconfig already has a mode where you can silently use the exit status to check for an active service. * libvirt.spec.in (%post): Use simpler chkconfig options, to avoid issues with localization. (cherry picked from commit fea83dde)
-
由 Eric Blake 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=754909 complains that because libvirt didn't require dmidecode, that the logs are noisy and virConnectGetSysinfo needlessly fails. Even 'virt-what' requires dmidecode, so it's not that onerous of a dependency. We may be able to drop this in the future when we move to parsing sysfs data, but for now, listing the dependency will help matters. * libvirt.spec.in (Requires): Sort Requires before BuildRequires. Add dmidecode. (cherry picked from commit e7dfa468) extra requires for with_systemd removed, since the patch that adds that hasn't been backported
-
由 Daniel P. Berrange 提交于
The Mingw32 linker highlighted that the symbols for virtime.h declared in libvirt_private.syms were incorrect * src/libvirt_private.syms: Fix virtime.h symbols (cherry picked from commit b265beda)
-
由 Eric Blake 提交于
We have several directories that are created on the fly, and which only contain state relevant to a running libvirtd process (all located in /var/run). Since the directories are created as needed, and make no sense without a running libvirtd, we want them deleted if libvirt is uninstalled. And in F15 and newer, /var/run is on tmpfs (forcing us to recreate on the fly); which means that someone trying to verify a complete rpm will fail if the directory does not currently exist because libvirtd has not been started since boot. The solution, then, is to mark the directories as %ghost, so that rpm knows that we own them and will clean it up if libvirt is uninstalled, but will no longer create the directory for us at install, nor complain at verify time if the directory does not exist. See https://bugzilla.redhat.com/show_bug.cgi?id=656611. * libvirt.spec.in (%files): Add %ghost to temporary directories that we don't install, but want cleaned up on libvirt removal. (cherry picked from commit 764574f7)
-
由 Daniel P. Berrange 提交于
The virTimestamp and virTimeMs functions in src/util/util.h duplicate functionality from virtime.h, in a non-async signal safe manner. Remove them, and convert all code over to the new APIs. * src/util/util.c, src/util/util.h: Delete virTimeMs and virTimestamp * src/lxc/lxc_driver.c, src/qemu/qemu_domain.c, src/qemu/qemu_driver.c, src/qemu/qemu_migration.c, src/qemu/qemu_process.c, src/util/event_poll.c: Convert to use virtime APIs (cherry picked from commit a8bb75a3) Conflicts: src/lxc/lxc_driver.c src/qemu/qemu_domain.c src/qemu/qemu_driver.c * the patches contained context with extra include files not yet introduced on the branch. src/util/event_poll.c * the branch had context with a call to EVENT_DEBUG that was no longer existing in the original patch.
-
由 Daniel P. Berrange 提交于
Use the new virTimeStringNowRaw() API for generating log timestamps in an async signal safe manner * src/util/logging.c: Use virTimeStringNowRaw (cherry picked from commit 32d3ec74) Conflicts: src/util/logging.c
-
由 Daniel P. Berrange 提交于
The logging APIs need to be able to generate formatted timestamps using only async signal safe functions. This rules out using gmtime/localtime/malloc/gettimeday(!) and much more. Introduce a new internal API which is async signal safe. virTimeMillisNowRaw replacement for gettimeofday. Uses clock_gettime where available, otherwise falls back to the unsafe gettimeofday virTimeFieldsNowRaw replacements for gmtime(), convert a timestamp virTimeFieldsThenRaw into a broken out set of fields. No localtime() replacement is provided, because converting to local time is not practical with only async signal safe APIs. virTimeStringNowRaw replacements for strftime() which print a timestamp virTimeStringThenRaw into a string, using a pre-determined format, with a fixed size buffer (VIR_TIME_STRING_BUFLEN) For each of these there is also a version without the Raw postfix which raises a full libvirt error. These versions are not async signal safe * src/Makefile.am, src/util/virtime.c, src/util/virtime.h: New files * src/libvirt_private.syms: New APis * configure.ac: Check for clock_gettime in -lrt * tests/virtimetest.c, tests/Makefile.am: Test new APIs (cherry picked from commit 3ec12898) Conflicts: src/Makefile.am
-
由 Jiri Denemark 提交于
(cherry picked from commit 11c6e094)
-
由 Jiri Denemark 提交于
Syslog puts the timestamp to every message anyway so this removes redundant data. (cherry picked from commit 2a449549)
-
由 Laine Stump 提交于
When support for was added for PCI multifunction cards (in commit 9f8baf, first included in libvirt 0.9.3), it was done by always turning on the multifunction bit for all PCI devices. Since that time it has been realized that this is not an ideal solution, and that the multifunction bit must be selectively turned on. For example, see https://bugzilla.redhat.com/show_bug.cgi?id=728174 and the discussion before and after https://www.redhat.com/archives/libvir-list/2011-September/msg01036.html This patch modifies multifunction support so that the multifunction=on option is only added to the qemu commandline for a device if its PCI <address> definition has the attribute "multifunction='on'", e.g.: <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0' multifunction='on'/> In practice, the multifunction bit should only be turned on if function='0' AND other functions will be used in the same slot - it usually isn't needed for functions 1-7 (although there are apparently some exceptions, e.g. the Intel X53 according to the QEMU source code), and should never be set if only function 0 will be used in the slot. The test cases have been changed accordingly to illustrate. With this patch in place, if a user attempts to assign multiple functions in a slot without setting the multifunction bit for function 0, libvirt will issue an error when the domain is defined, and the define operation will fail. In the future, we may decide to detect this situation and automatically add multifunction=on to avoid the error; even then it will still be useful to have a manual method of turning on multifunction since, as stated above, there are some devices that excpect it to be turned on for all functions in a slot. A side effect of this patch is that attempts to use the same PCI address for two different devices will now log an error (previously this would cause the domain define operation to fail, but there would be no log message generated). Because the function doing this log was almost completely rewritten, I didn't think it worthwhile to make a separate patch for that fix (the entire patch would immediately be obsoleted). (cherry picked from commit c329db71)
-