- 26 6月, 2014 1 次提交
-
-
由 Peter Krempa 提交于
When creating a new disk mirror the new struct is stored in a separate variable until everything went well. The removed hunk would actually remove existing mirror information for example when the api would be run if a mirror still exists. (cherry picked from commit 02b364e1) This fixes a regression introduced in commit ff5f30b6. Signed-off-by: NEric Blake <eblake@redhat.com> Conflicts: src/qemu/qemu_driver.c - no refactoring of commit 7b7bf001
-
- 11 6月, 2014 1 次提交
-
-
由 Eric Blake 提交于
Jim Fehlig reported a regression found by libvirt-TCK tests: > ~ # perl /usr/share/libvirt-tck/tests/qemu/100-disk-encryption.t ... > ok 4 - defined persistent domain config > # Starting inactive domain config > libvirt error code: 1, message: internal error: unable to execute QEMU command > 'cont': 'drive-ide0-0-1' > (/var/cache/libvirt-tck/300-disk-encryption/demo.qcow2) is encrypted Commit 2279d560 converted a boolean into a pointer with the intent of transferring that pointer out of a temporary object into the caller's data structure. The temporary structure meant that meta->encryption was always NULL on entry, so we could get away with blindly allocating the pointer when the header said so. But later, commit 8823272d tweaked things to do backing chain detection in-place, rather than via a temporary object; this has the net result that meta->encryption can be non-NULL on entry. Not only did this turn the latent behavior into a memory leak, it is also a behavior regression: blindly allocating a new pointer wipes out what secrets we already knew about the chain, making it impossible to restart the domain. Of course, no one in their right mind should be relying on qcow2 encryption - it is fundamentally flawed. And sadly, the TCK tests don't get run often enough, and this shows that our virstoragetest does not exercise encrypted images at all. Otherwise, we could have avoided a release containing this regression. * src/util/virstoragefile.c (virStorageFileGetMetadataInternal): Don't nuke an already-existing encryption. Signed-off-by: NEric Blake <eblake@redhat.com> (cherry picked from commit 1c7eb95c)
-
- 06 6月, 2014 1 次提交
-
-
由 Ján Tomko 提交于
Commit fff74b27 moved the probing into virStorageFileGetMetadataFromBuf but didn't update the format in volume definition. https://bugzilla.redhat.com/show_bug.cgi?id=1104908 (cherry picked from commit c110cdb2) Conflicts: src/storage/storage_backend_fs.c I didn't backport the refactors - febcb89c and effbb11e
-
- 02 6月, 2014 2 次提交
-
-
由 Daniel Veillard 提交于
* docs/news.html.in: update for release * po/*.po*: updated ukrainian localization and regenerated
-
由 Roman Bogorodskiy 提交于
- Document 'domxml-to-native' command - Mention that the nmdm console support needs an appropriate kernel module loaded
-
- 01 6月, 2014 1 次提交
-
-
由 Laine Stump 提交于
Reported by: Roman Bogorodskiy <bogorodskiy@gmail.com> Some of the tests for virTimeLocalOffsetFromUTC set an imaginary timezone that attempts to force dyalight savings time active all the time by setting a start date of 0/00:00:00 and end date of 366/23:59:59. Since the day is 0-based, 366 really means "day 367" which will never occur - this was an attempt to eliminate problems with DST not being active in some cases right around midnight on January 1. Even though it didn't completely solve the problem, it didn't seem to cause harm so it was left in the test timezones. Although Linux glibc doesn't mind having a DST end date of 366, FreeBSD refuses to use such timezones, so the tests fail. This patch changes the 366 to 365. This may or may not cause failure of the remaining DST tests around midnight Jan 1. If so, we will need to disable those tests at year's end too.
-
- 31 5月, 2014 1 次提交
-
-
由 Eric Blake 提交于
On a 32-bit platform: virstringtest.c: In function 'mymain': virstringtest.c:673: warning: this decimal constant is unsigned only in ISO C90 I already had a comment in the file about the 64-bit counterpart; the easiest fix was to make both sites use the standardized macro that is guaranteed to work. * tests/virstringtest.c (mymain): Minimum signed integers are a pain. Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 29 5月, 2014 13 次提交
-
-
由 Peter Krempa 提交于
Currently we don't support mixed (external + internal) snapshots. The code detecting the snapshot type didn't make sure that the memory image was consistent with the snapshot type leading into strange error message: $ virsh snapshot-create-as --domain VM --diskspec vda,snapshot=internal --memspec snapshot=external,file=/tmp/blah error: internal error: unexpected code path Fix the mixed detection code to detect this kind of mistake: $ virsh snapshot-create-as --domain VM --diskspec vda,snapshot=internal --memspec snapshot=external,file=/tmp/blah error: unsupported configuration: mixing internal and external targets for a snapshot is not yet supported
-
由 Peter Krempa 提交于
A internal snapshot of a active VM with the memory snapshot disabled explicitly would actually still take the memory snapshot. Reject it explicitly. Before: $ virsh snapshot-create-as --domain VM --diskspec vda,snapshot=internal --memspec snapshot=no Domain snapshot 1401353155 created After: $ virsh snapshot-create-as --domain VM --diskspec vda,snapshot=internal --memspec snapshot=no error: Operation not supported: internal snapshot of a running VM must include the memory state Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1083345
-
由 Peter Krempa 提交于
For guests backed by gluster volumes (or other network storage) we don't fill the backing chain (see qemuDomainDetermineDiskChain). This leaves the "relPath" field of the top image NULL. This causes a crash in virStorageFileChainLookup() when looking up a backing element for such a disk. Since I'm working on adding support for network storage and one of the steps will make the "relPath" field optional let's use STREQ_NULLABLE instead of STREQ in virStorageFileChainLookup() to avoid the problem.
-
由 Laine Stump 提交于
The original version of virTimeLocalOffsetFromUTC() would fail for certain times of the day if daylight savings time was active. This could most easily be seen by uncommenting the TEST_LOCALOFFSET() cases that include a DST setting. After a lot of experimenting, I found that the way to solve it in almost all test cases is to set tm_isdst = -1 in the struct tm prior to calling mktime(). Once this is done, the correct offset is returned for all test cases at all times except the two hours just after 00:00:00 Jan 1 UTC - during that time, any timezone that is *behind* UTC, and that is supposed to always be in DST will not have DST accounted for in its offset. I believe that the code of virTimeLocalOffsetFromUTC() actually is correct for all cases, but the problem still encountered is due to our inability to come up with a TZ string that properly forces DST to *always* be active. Since a modfication of the (currently fixed) expected result data to account for this would necessarily use the same functions that we're trying to test, I've instead just made the test program conditionally bypass the problematic cases if the current date is either December 31 or January 1. This way we get maximum testing during 363 days of the year, but don't get false failures on Dec 31 and Jan 1.
-
由 Eric Blake 提交于
* tools/virsh.pod (attach-disk): Drop duplicate --config, fix typo in --sourcetype. Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Eric Blake 提交于
Use correct variable name. * m4/virt-selinux.m4: Fix one last variable name.
-
由 Jim Fehlig 提交于
Commit 292d3f2d fixed the build with libselinux 2.3, but missed some suggestions by eblake https://www.redhat.com/archives/libvir-list/2014-May/msg00977.html This patch changes the macro introduced in 292d3f2d to either be empty in the case of newer libselinux, or contain 'const' in the case of older libselinux. The macro is then used directly in tests/securityselinuxhelper.c.
-
由 Cédric Bosdonnat 提交于
Several function signatures changed in libselinux 2.3, now taking a 'const char *' instead of 'security_context_t'. The latter is defined in selinux/selinux.h as typedef char *security_context_t; Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Peter Krempa 提交于
Even successful start of a VM from a managed save image would spam the logs with the following message: Unable to restore from managed state [path]. Maybe the file is corrupted? Re-arrange the logic to output the warning only when the image is corrupted. The flaw was introduced in commit cfc28c66.
-
由 Peter Krempa 提交于
Now that virStorageFileGetMetadataFromBuf is used only for remote filesystems, don't canonicalize the path in it.
-
由 Peter Krempa 提交于
Use virStorageFileGetMetadataFromFD instead in virStorageBackendProbeTarget as it now returns all required data and the storage file is already open in a filedescriptor. Also fix improper error code being returned when virFileReadHeaderFD would fail as virStorageBackendUpdateVolTargetInfoFD would set the return code to 0.
-
由 Peter Krempa 提交于
Add argument to return backing file format of a file probed by virStorageFileGetMetadataFromFD so that it can be used in place of virStorageFileGetMetadataFromBuf.
-
由 Eric Blake 提交于
qemu 2.0 added the ability to commit the active layer, but slightly differently than what libvirt had been anticipating in its implementation of the virDomainBlockCommit call. As a result, if you attempt to do a 'virsh blockcommit $dom vda', qemu gets into a state where it is waiting on libvirt to end the job, while libvirt is waiting on qemu to end the job, and the guest is effectively hung with regards to further commands for that block device. I have patches coming down the pipeline that will add full support for blockcommit of the active layer when coupled with qemu 2.0 or later; but they depend on Peter's improvements to block job handling and form enough of a new feature that they are not ready for inclusion in the 1.2.5 release. So for now, just reject the attempt, rather than letting the user get stuck. This is no worse than the behavior of qemu 1.7 rejecting the job. * src/qemu/qemu_driver.c (qemuDomainBlockCommit): Reject active commit. Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 28 5月, 2014 1 次提交
-
-
由 Dan Kenigsberg 提交于
The documentation of the functions should match the argument name in the actual function signature. Signed-off-by: NDan Kenigsberg <danken@redhat.com>
-
- 27 5月, 2014 2 次提交
-
-
由 Olivia Yin 提交于
QEMU ppce500 board uses the legacy -serial option. Other PPC boards don't give any way to explicitly wire in a -chardev except pseries which uses -device spapr-vty with -chardev. Add test case for -serial option for ppce500 Signed-off-by: NOlivia Yin <Hong-Hua.Yin@freescale.com> Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
由 Olivia Yin 提交于
ppce500v2 is not machine supported by official release of QEMU. It should be replaced by ppce500. Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
- 26 5月, 2014 6 次提交
-
-
由 Daniel Veillard 提交于
Raised by ukrainian translator Yuri Chornoivan https://fedora.transifex.com/projects/p/libvirt/translate/#uk/strings/25483059
-
由 Ján Tomko 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1088787 Clean up unix socket files for chardevs using mode='bind', like we clean up the monitor socket. They are created by QEMU on startup and not really useful after shutting it down.
-
由 Laine Stump 提交于
For a clock element as above, libvirt simply converts current system time with localtime_r(), then starts qemu with a time string that doesn't contain any timezone information. So, from qemu's point of view, the -rtc string it gets for: <clock offset='variable' basis='utc' adjustment='10800'/> is identical to the -rtc string it gets for: <clock offset='variable' basis='localtime' adjustment='0'/> (assuming the host is in a timezone that is 10800 seconds ahead of UTC, as is the case on the machine where this message is being written). Since the commandlines are identical, qemu will behave identically after this point in either case. There are two problems in the case of basis='localtime' though: Problem 1) If the guest modifies its RTC, for example to add 20 seconds, the RTC_CHANGE event from qemu will then contain offset:20 in both cases. But libvirt will have saved the original adjustment into adjustment0, and will add that value onto the offset in the event. This means that in the case of basis=;utc', it will properly emit an event with offset:10820, but in the case of basis='localtime' the event will contain offset:20, which is *not* the new offset of the RTC from UTC (as the event it documented to provide). Problem 2) If the guest is migrated to another host that is in a different timezone, or if it is migrated or saved/restored after the DST status has changed from what it was when the guest was originally started, the newly restarted guest will have a different RTC (since it will be based on the new localtime, which could have shifted by several hours). The solution to both of these problems is simple - rather than maintaining the original adjustment value along with "basis='localtime'" in the domain status, when the domain is started we convert the adjustment offset to one relative to UTC, and set the status to "basis='utc'". Thus, whatever the RTC offset was from UTC when it was initially started, that offset will be maintained when migrating across timezones and DST settings, and the RTC_CHANGE events will automatically contain the proper offset (which should by definition always be relative to UTC). This fixes a problem that was implied but not openly stated in: https://bugzilla.redhat.com/show_bug.cgi?id=964177
-
由 Laine Stump 提交于
commit e31b5cf3 attempted to fix libvirt's VIR_DOMAIN_EVENT_ID_RTC_CHANGE, which is documentated to always provide the new offset of the domain's real time clock from UTC. The problem was that, in the case that qemu is provided with an "-rtc base=x" where x is an absolute time (rather than "utc" or "localtime"), the offset sent by qemu's RTC_CHANGE event is *not* the new offset from UTC, but rather is the sum of all changes to the domain's RTC since it was started with base=x. So, despite what was said in commit e31b5cf3, if we assume that the original value stored in "adjustment" was the offset from UTC at the time the domain was started, we can always determine the current offset from UTC by simply adding the most recent (i.e. current) offset from qemu to that original adjustment. This patch accomplishes that by storing the initial adjustment in the domain's status as "adjustment0". Each time a new RTC_CHANGE event is received from qemu, we simply add adjustment0 to the value sent by qemu, store that as the new adjustment, and forward that value on to any event handler. This patch (*not* e31b5cf3, which should be reverted prior to applying this patch) fixes: https://bugzilla.redhat.com/show_bug.cgi?id=964177 (for the case where basis='utc'. It does not fix basis='localtime')
-
由 Laine Stump 提交于
This reverts commit e31b5cf3. This commit attempted to work around a bug in the offset value reported by qemu's RTC_CHANGE event in the case that a variable base date was given on the qemu commandline. The patch mixed up the math involved in arriving at the corrected offset to report, and in the process added an unnecessary private attribute to the clock element. Since that element is private/internal and not used by anyone else, it makes sense to simplify things by removing it.
-
由 Laine Stump 提交于
Since there isn't a single libc API to get this value, this patch supplies one which gets the value by grabbing current time, then converting that into a struct tm with gmtime_r(), then back to a time_t using mktime. The returned value is the difference between UTC and localtime in seconds. If localtime is ahead of UTC (east) the offset will be a positive number, and if localtime is behind UTC (west) the offset will be negative. This function should be POSIX-compliant, and is threadsafe, but not async signal safe. If it was ever necessary to know this value in a child process, we could cache it with a one-time init function when libvirtd starts, then just supply the cached value, but that complexity isn't needed for current usage; that would also have the problem that it might not be accurate after a local daylight savings boundary. (If it weren't for DST, we could simply replace this entire function with "-timezone"; timezone contains the offset of the current timezone (negated from what we want) but doesn't account for DST. And in spite of being guaranteed by POSIX, it isn't available on older versions of mingw.) Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 23 5月, 2014 11 次提交
-
-
由 Peter Krempa 提交于
Add storage driver based functions to access headers of storage files for metadata extraction. Along with this patch a local filesystem and gluster via libgfapi implementation is provided. The gluster implementation is based on code of the saferead_lim function.
-
由 Peter Krempa 提交于
To allow using the storage driver APIs to access files on various storage sources in a universal fashion possibly on storage such as nfs with root squash we'll need to store the desired uid/gid in the metadata. Add new initialisation API that will store the desired uid/gid and a wrapper for the current use. Additionally add docs for the two APIs.
-
由 Peter Krempa 提交于
Currently the protocol type with index 0 was NBD which made it hard to distinguish whether the protocol type was actually assigned. Add a new protocol type with index 0 to distinguish it explicitly.
-
由 Peter Krempa 提交于
Skip networked storage but continue iteration through backing chain to iterate through all the local paths in the backing chain.
-
由 Peter Krempa 提交于
Print the debug statements of individual file access functions from the main API functions instead of the individual backend functions. Also enhance initialization debug messages on a per-backend basis.
-
由 Peter Krempa 提交于
The gluster volume name was previously stored as part of the source path string. This is unfortunate when we want to do operations on the path as the volume is used separately. Parse and store the volume name separately for gluster storage volumes and use the newly stored variable appropriately.
-
由 Peter Krempa 提交于
Refactor the function to accept a virStorageSourcePtr instead of just the path, add a check to run it only on local storage and fix callers (possibly by using a newly introduced wrapper that wraps a path in the virStorageSource struct for legacy code)
-
由 Peter Krempa 提交于
Refresh the disk backing chains when reconnecting to a qemu process after daemon restart. There are a few internal fields that don't get refreshed from the XML. Until we are able to do that, let's reload all the metadata by the backing chain crawler.
-
由 Jiri Denemark 提交于
This is similar to the previous commit in that we need to explicitly send migrate_cancel when libvirt detects an error other than those reported by query-migrate. However, the possibility to hit such error is pretty small.
-
由 Jiri Denemark 提交于
When QEMU reports failed or cancelled migration, we don't need to send it migrate_cancel QMP command. But in all other error paths, such as if we detect broken connection to a destination daemon or something else happens inside libvirt, we need to explicitly send migrate_cancel command instead of relying on the migration to be implicitly cancelled when destination QEMU is killed. Because we were not doing so, one could end up with a paused domain after failed migration. https://bugzilla.redhat.com/show_bug.cgi?id=1098833
-
由 Jiri Denemark 提交于
The current error message is error: use virDomainMigrateToURI3 for peer-to-peer migration which is correct but a bit misleading because the client did not specify VIR_MIGRATE_PEER2PEER flag. This patch changes the error message to error: cannot perform tunnelled migration without using peer2peer flag which is consistent with the error reported by older migration APIs. Reported by Rich Jones in https://bugzilla.redhat.com/show_bug.cgi?id=1095924
-