- 31 10月, 2012 8 次提交
-
-
由 Michal Privoznik 提交于
-
由 Martin Kletzander 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=871312 Recent fixes made almost all the right steps to make emulator pinned to the cpuset of the whole domain in case <emulatorpin> isn't specified, but qemudDomainGetEmulatorPinInfo still reports all the CPUs even when cpuset is specified. This patch fixes that.
-
由 Peter Krempa 提交于
There are multiple reasons canonicalize_file_name() used in absolutePathFromBaseFile helper can fail. This patch enhances error reporting from that helper.
-
由 Martin Kletzander 提交于
When there is no 'qemu-kvm' binary and the emulator used for a machine is, for example, 'qemu-system-x86_64' that, by default, runs without kvm enabled, libvirt still supplies '-no-kvm' option to this process, even though it does not recognize such option (making the start of a domain fail in that case). This patch fixes building a command-line for QEMU machines without KVM acceleration and is based on following assumptions: - QEMU_CAPS_KVM flag means that QEMU is running KVM accelerated machines by default (without explicitly requesting that using a command-line option). It is the closest to the truth according to the code with the only exception being the comment next to the flag, so it's fixed in this patch as well. - QEMU_CAPS_ENABLE_KVM flag means that QEMU is, by default, running without KVM acceleration and in case we need KVM acceleration it needs to be explicitly instructed to do so. This is partially true for the past (this option essentially means that QEMU recognizes the '-enable-kvm' option, even though it's almost the same).
-
由 Gene Czarcinski 提交于
Three FORWARD chain rules are added and two INPUT chain rules are added when a network is started but only the FORWARD chain rules are removed when the network is destroyed.
-
由 Eric Blake 提交于
I noticed this while answering a list question about Java bindings of volume creation. All other functions that take xml logged xmlDesc. * src/libvirt.c (virStorageVolCreateXML) (virStorageVolCreateXMLFrom): Use consistent spelling of xmlDesc, and log the argument.
-
由 Guido Günther 提交于
to avoid ENAMETOOLONG: https://buildd.debian.org/status/fetch.php?pkg=libvirt&arch=amd64&ver=1.0.0~rc1-1&stamp=1351453521
-
由 Laine Stump 提交于
This patch resolves: https://bugzilla.redhat.com/show_bug.cgi?id=871201 If libvirt is restarted after updating the dnsmasq or radvd packages, a subsequent "virsh net-destroy" will fail to kill the dnsmasq/radvd process. The problem is that when libvirtd restarts, it re-reads the dnsmasq and radvd pidfiles, then does a sanity check on each pid it finds, including checking that the symbolic link in /proc/$pid/exe actually points to the same file as the path used by libvirt to execute the binary in the first place. If this fails, libvirt assumes that the process is no longer alive. But if the original binary has been replaced, the link in /proc is set to "$binarypath (deleted)" (it literally has the string " (deleted)" appended to the link text stored in the filesystem), so even if a new binary exists in the same location, attempts to resolve the link will fail. In the end, not only is the old dnsmasq/radvd not terminated when the network is stopped, but a new dnsmasq can't be started when the network is later restarted (because the original process is still listening on the ports that the new process wants). The solution is, when the initial "use stat to check for identical inodes" check for identity between /proc/$pid/exe and $binpath fails, to check /proc/$pid/exe for a link ending with " (deleted)" and if so, truncate that part of the link and compare what's left with the original binarypath. A twist to this problem is that on systems with "merged" /sbin and /usr/sbin (i.e. /sbin is really just a symlink to /usr/sbin; Fedora 17+ is an example of this), libvirt may have started the process using one path, but /proc/$pid/exe lists a different path (indeed, on F17 this is the case - libvirtd uses /sbin/dnsmasq, but /proc/$pid/exe shows "/usr/sbin/dnsmasq"). The further bit of code to resolve this is to call virFileResolveAllLinks() on both the original binarypath and on the truncated link we read from /proc/$pid/exe, and compare the results. The resulting code still succeeds in all the same cases it did before, but also succeeds if the binary was deleted or replaced after it was started.
-
- 30 10月, 2012 9 次提交
-
-
由 Peter Krempa 提交于
A mild case of dyslexia caused that commit 012f9b19 specifies wrong mask for the smap cpu feature flag. This patch fixes that mistake.
-
由 Peter Krempa 提交于
The test data contained extra \0 bytes after newlines probably due to a kernel off-by-one bug.
-
由 Michal Privoznik 提交于
through which user set under what permissions does sanlock daemon run so libvirt will set the same permissions for files exposed to it.
-
由 Vladislav Bogdanov 提交于
-
由 Vladislav Bogdanov 提交于
-
由 Martin Kletzander 提交于
After separating 5.x and 5.1 versions of ESX, we forgot to add 5.1 into the list of allowed connections, so connections to 5.1 fail since v1.0.0-rc1-5-g1e7cd395
-
由 Eric Blake 提交于
Ever since commit eefb881d, ATTRIBUTE_NONNULL has normally been a no-op under gcc (since it tends to cause more bugs than it cures given gcc's current lame implementation of the attribute). However, the macro is still useful to Coverity and other static-analysis tools, but only if we use it correctly. Coverity follows gcc's lead in accepting function declarations with attributes at the end, but function bodies must attach attributes to the return type. That is, these are valid: void foo(void *arg) ATTRIBUTE_NONNULL(1); void ATTRIBUTE_NONNULL(1) foo(void *arg); void ATTRIBUTE_NONNULL(1) foo(void *arg) {} but this is not: void foo(void *arg) ATTRIBUTE_NONNULL(1) {} even though you don't get a compile failure until you do static analysis. Bug introduced in commit 80533ca2, with these symptoms: nodeinfo.c:206: error: expected ',' or ';' before '{' token cc1: warning: unrecognized command line option "-Wno-suggest-attribute=const" cc1: warning: unrecognized command line option "-Wno-suggest-attribute=pure" make[3]: *** [libvirt_driver_la-nodeinfo.lo] Error 1 * src/nodeinfo.c (virNodeParseNode): Fix syntax error when non-null attribute is in use.
-
由 Eric Blake 提交于
Commit 34e8f63a altered virfile.o to drag in additional symbols, which in turn led to pulling in other .o files and eventually causing a link failure when systemtap probes are enabled, such as: ./.libs/libvirt_util.a(libvirt_util_la-event_poll.o): In function `virEventPollRunOnce': /home/dummy/libvirt/src/util/event_poll.c:614: undefined reference to `libvirt_event_poll_run_semaphore' ./.libs/libvirt_util.a(libvirt_util_la-event_poll.o):(.note.stapsdt+0x24): undefined reference to `libvirt_event_poll_add_handle_semaphore' Even though libvirt_iohelper and libvirt_parthelper don't directly use the portion of virfile.o that drags in probing, it was easier to satisfy the linker and get the build back up, than to figure out whether it is even possible or worth trying to disentangle the mess. * src/Makefile.am (libvirt_iohelper_LDADD) (libvirt_parthelper_LDADD): Use libvirt_probes.lo when needed.
-
由 Michal Privoznik 提交于
Currently, we use iohelper when saving/restoring a domain. However, if there's some kind of error (like I/O) it is not propagated to libvirt. Since it is not qemu who is doing the actual write() it will not get error. The iohelper does. Therefore we should check for iohelper errors as it makes libvirt more user friendly.
-
- 29 10月, 2012 3 次提交
-
-
由 Peter Krempa 提交于
And drop a stray space at the end of the first line of the warning.
-
由 Ján Tomko 提交于
In the XML warning, we print a virsh command line that can be used to edit that XML. This patch prints UUIDs if the entity name contains special characters (like shell metacharacters, or "--" that would break parsing of the XML comment). If the entity doesn't have a UUID, just print the virsh command that can be used to edit it.
-
由 Jiri Denemark 提交于
This reverts commit 8d75e47e. Libvirt was never released with support for migration cookies without hostuuid.
-
- 28 10月, 2012 1 次提交
-
-
- 27 10月, 2012 17 次提交
-
-
由 Eric Blake 提交于
Introduced in commit 0039a32f. * src/qemu/qemu_process.c (qemuPrepareCpumap): s/covert/convert/
-
由 Eric Blake 提交于
When using block copy to pivot over to a new chain, the backing files for the new chain might still need labeling (particularly if the user passes --reuse-ext with a relative backing file name). Relabeling a file that is already labeled won't hurt, so this just labels the entire chain at the point of the pivot. Doing the relabel of the chain uses the fact that we already safely probed the file type of an external file at the start of the block copy. * src/qemu/qemu_driver.c (qemuDomainBlockPivot): Relabel chain before asking qemu to pivot.
-
由 Eric Blake 提交于
Use the recent addition of qemuDomainPrepareDiskChainElement to obtain locking manager lease, permit a block device through cgroups, and set the SELinux label; then audit the fact that we hand a new file over to qemu. Alas, releasing the lease and label at the end of the mirroring is a trickier prospect (we would have to trace the backing chain of both source and destination, and be sure not to revoke rights to any part of the chain that is shared), so for now, virDomainBlockJobAbort still leaves things with additional access granted (as block-pull and block-commit have the same problem of not clamping access after completion, a future cleanup would cover all three commands). * src/qemu/qemu_driver.c (qemuDomainBlockCopy): Set up labeling.
-
由 Eric Blake 提交于
Support the REUSE_EXT flag, in part by copying sanity checks from snapshot code. This code introduces a case of probing an external file for its type; such an action would be a security risk if the existing file is supposed to be raw but the contents resemble some other format; however, since the virDomainBlockRebase API has a flag to force treating the file as raw rather than probe, we can assume that probing is safe in all other instances. Besides, if we don't probe or force raw, then qemu will. * src/qemu/qemu_driver.c (qemuDomainBlockRebase): Allow REUSE_EXT flag. (qemuDomainBlockCopy): Wire up flag, and add some sanity checks.
-
由 Eric Blake 提交于
Minimal patch to wire up all the pieces in the previous patches to actually enable a block copy job. By minimal, I mean that qemu creates the file (that is, no REUSE_EXT flag support yet), SELinux must be disabled, a lock manager is not informed, and the audit logs aren't updated. But those will be added as improvements in future patches. This patch is designed so that if we ever add a future API virDomainBlockCopy with more bells and whistles (such as letting the user specify a destination image format different than the source), where virDomainBlockRebase is a wrapper around the simpler portions of the new functionality, then the new API can just reuse the new qemuDomainBlockCopy function and already support _SHALLOW and _REUSE_EXT flags. Also note that libvirt.c already filtered the new flags if _COPY is not present, so that we are not impacting the case of BlockRebase being a wrapper around BlockPull. * src/qemu/qemu_driver.c (qemuDomainBlockCopy): New function. (qemuDomainBlockRebase): Call it when appropriate.
-
由 Eric Blake 提交于
Since libvirt drops locks between issuing a monitor command and getting a response, it is possible for libvirtd to be restarted before getting a response on a block-job-complete command; worse, it is also possible for the guest to shut itself down during the window while libvirtd is down, ending the qemu process. A management app needs to know if the pivot happened (and the destination file contains guest contents not in the source) or failed (and the source file contains guest contents not in the destination), but since the job is finished, 'query-block-jobs' no longer tracks the status of the job, and if the qemu process itself has disappeared, even 'query-block' cannot be checked to ask qemu its current state. At the time of this patch, the design for persistent bitmap has not been clarified, so a followup patch will be needed once qemu actually figures out how to expose it, and we figure out how to use it. In the meantime, we have a solution that avoids the worst of the problem. [This problem was first analyzed with the RHEL 6.3 __com.redhat_drive-reopen command; which partly explains why upstream qemu 1.3 ditched the drive-reopen idea and went with block-job-complete plus persistent bitmap instead.] If we surround 'drive-reopen' with a pause/resume pair, then we can guarantee that the guest cannot modify either source or destination files in the window of libvirtd uncertainty, and the management app is guaranteed that either libvirt knows the outcome and reported it correctly; or that on libvirtd restart, the guest will still be paused and that the qemu process cannot have disappeared due to guest shutdown; and use that as a clue that the management app must implement recovery protocol, with both source and destination files still being in sync and with 'query-block' still being an option as part of that recovery. My testing shows that the pause window will typically be only a fraction of a second. * src/qemu/qemu_driver.c (qemuDomainBlockPivot): Pause around drive-reopen. (qemuDomainBlockJobImpl): Update caller.
-
由 Eric Blake 提交于
This is the bare minimum to end a copy job (of course, until a later patch adds the ability to start a copy job, this patch doesn't do much in isolation; I've just split the patches to ease the review). This patch intentionally avoids SELinux, lock manager, and audit actions. Also, if libvirtd restarts at the exact moment that a 'block-job-complete' is in flight, the proposed proper way to detect the outcome of that would be with a persistent bitmap and some additional query commands when libvirtd restarts. This patch is enough to test the common case of success when used correctly, while saving the subtleties of proper cleanup for worst-case errors for later. When a mirror job is started, cancelling the job safely reverts back to the source disk, regardless of whether the destination is in phase 1 (streaming, in which case the destination is worthless) or phase 2 (mirroring, in which case the destination is synced up to the source at the time of the cancel). Our existing code does just fine in either phase, other than some bookkeeping cleanup; this implements live block copy. Ideas for future enhancements via new flags: Depending on when persistent bitmap support is added, it may be worth adding a VIR_DOMAIN_REBASE_COPY_ATOMIC flag that fails up front if we detect an older qemu with risky pivot operation. Interesting side note: while snapshot-create --disk-only creates a copy of the disk at a point in time by moving the domain on to a new file (the copy is the file now in the just-extended backing chain), blockjob --abort of a copy job creates a copy of the disk while keeping the domain on the original file. There may be potential improvements to the snapshot code to exploit block copy over multiple disks all at one point in time. And, if 'block-job-cancel' were made part of 'transaction', you could copy multiple disks at the same point in time without pausing the domain. This also implies we may want to add a --quiesce flag to virDomainBlockJobAbort, so that when breaking a mirror (whether by cancel or pivot), the side of the mirror that we are abandoning is at least in a stable state with regards to guest I/O. * src/qemu/qemu_driver.c (qemuDomainBlockJobAbort): Accept new flag. (qemuDomainBlockPivot): New helper function. (qemuDomainBlockJobImpl): Implement it.
-
由 Eric Blake 提交于
Handle the new type of block copy event and info. Of course, this patch does nothing until a later patch actually allows the creation/abort of a block copy job. * include/libvirt/libvirt.h.in (VIR_DOMAIN_BLOCK_JOB_READY): New block job status. * src/libvirt.c (virDomainBlockRebase): Document the event. * src/qemu/qemu_monitor_json.c (eventHandlers): New event. (qemuMonitorJSONHandleBlockJobReady): New function. (qemuMonitorJSONGetBlockJobInfoOne): Translate new job type. (qemuMonitorJSONHandleBlockJobImpl): Handle new event and job type. * src/qemu/qemu_process.c (qemuProcessHandleBlockJob): Recognize the event to minimize snooping. * src/qemu/qemu_driver.c (qemuDomainBlockJobImpl): Snoop a successful info query to save effort on a pivot request.
-
由 Eric Blake 提交于
For now, disk migration via block copy job is not implemented in libvirt. But when we do implement it, we have to deal with the fact that qemu does not yet provide an easy way to re-start a qemu process with mirroring still intact. Paolo has proposed an idea for a persistent dirty bitmap that might make this possible, but until that design is complete, it's hard to say what changes libvirt would need. Even something like 'virDomainSave' becomes hairy, if you realize the implications that 'virDomainRestore' would be stuck with recreating the same mirror layout. But if we step back and look at the bigger picture, we realize that the initial client of live storage migration via disk mirroring is oVirt, which always uses transient domains, and that if a transient domain is destroyed while a mirror exists, oVirt can easily restart the storage migration by creating a new domain that visits just the source storage, with no loss in data. We can make life a lot easier by being cowards for now, forbidding certain operations on a domain. This patch guarantees that we never get in a state where we would have to restart a domain with a mirroring block copy, by preventing saves, snapshots, migration, hot unplug of a disk in use, and conversion to a persistent domain (thankfully, it is still relatively easy to 'virsh undefine' a running domain to temporarily make it transient, run tests on 'virsh blockcopy', then 'virsh define' to restore the persistence). Later, if the qemu design is enhanced, we can relax our code. The change to qemudDomainDefine looks a bit odd for undoing an assignment, rather than probing up front to avoid the assignment, but this is because of how virDomainAssignDef combines both a lookup and assignment into a single function call. * src/conf/domain_conf.h (virDomainHasDiskMirror): New prototype. * src/conf/domain_conf.c (virDomainHasDiskMirror): New function. * src/libvirt_private.syms (domain_conf.h): Export it. * src/qemu/qemu_driver.c (qemuDomainSaveInternal) (qemuDomainSnapshotCreateXML, qemuDomainRevertToSnapshot) (qemuDomainBlockJobImpl, qemudDomainDefine): Prevent dangerous actions while block copy is already in action. * src/qemu/qemu_hotplug.c (qemuDomainDetachDiskDevice): Likewise. * src/qemu/qemu_migration.c (qemuMigrationIsAllowed): Likewise.
-
由 Eric Blake 提交于
Upstream qemu 1.3 is adding two new monitor commands, 'drive-mirror' and 'block-job-complete'[1], which can drive live block copy and storage migration. [Additionally, RHEL 6.3 had backported an earlier version of most of the same functionality, but under the names '__com.redhat_drive-mirror' and '__com.redhat_drive-reopen' and with slightly different JSON arguments, and has been using patches similar to these upstream patches for several months now.] The libvirt API virDomainBlockRebase as already committed for 0.9.12 is flexible enough to expose the basics of block copy, but some additional features in the 'drive-mirror' qemu command, such as setting error policy, setting granularity, or using a persistent bitmap, may later require a new libvirt API virDomainBlockCopy. I will wait to add that API until we know more about what qemu 1.3 will finally provide. This patch caters only to the upstream qemu 1.3 interface, although I have proven that the changes for RHEL 6.3 can be isolated to just qemu_monitor_json.c, and the rest of this series will gracefully handle either interface once the JSON differences are papered over in a downstream patch. For consistency with other block job commands, libvirt must handle the bandwidth argument as MiB/sec from the user, even though qemu exposes the speed argument as bytes/sec; then again, qemu rounds up to cluster size internally, so using MiB hides the worst effects of that rounding if you pass small numbers. [1]https://lists.gnu.org/archive/html/qemu-devel/2012-10/msg04123.html * src/qemu/qemu_capabilities.h (QEMU_CAPS_DRIVE_MIRROR) (QEMU_CAPS_DRIVE_REOPEN): New bits. * src/qemu/qemu_capabilities.c (qemuCaps): Name them. * src/qemu/qemu_monitor_json.c (qemuMonitorJSONCheckCommands): Set them. (qemuMonitorJSONDriveMirror, qemuMonitorDrivePivot): New functions. * src/qemu/qemu_monitor_json.h (qemuMonitorJSONDriveMirror) (qemuMonitorDrivePivot): Declare them. * src/qemu/qemu_monitor.c (qemuMonitorDriveMirror) (qemuMonitorDrivePivot): New passthroughs. * src/qemu/qemu_monitor.h (qemuMonitorDriveMirror) (qemuMonitorDrivePivot): Declare them.
-
由 Laine Stump 提交于
This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=862515 which describes inconsistencies in dealing with duplicate mac addresses on network devices in a domain. (at any rate, it resolves *almost* everything, and prints out an informative error message for the one problem that isn't solved, but has a workaround.) A synopsis of the problems: 1) you can't do a persistent attach-interface of a device with a mac address that matches an existing device. 2) you *can* do a live attach-interface of such a device. 3) you *can* directly edit a domain and put in two devices with matching mac addresses. 4) When running virsh detach-device (live or config), only MAC address is checked when matching the device to remove, so the first device with the desired mac address will be removed. This isn't always the one that's wanted. 5) when running virsh detach-interface (live or config), the only two items that can be specified to match against are mac address and model type (virtio, etc) - if multiple netdevs match both of those attributes, it again just finds the first one added and assumes that is the only match. Since it is completely valid to have multiple network devices with the same MAC address (although it can cause problems in many cases, there *are* valid use cases), what is needed is: 1) remove the restriction that prohibits doing a persistent add of a netdev with a duplicate mac address. 2) enhance the backend of virDomainDetachDeviceFlags to check for something that *is* guaranteed unique (but still work with just mac address, as long as it yields only a single results. This patch does three things: 1) removes the check for duplicate mac address during a persistent netdev attach. 2) unifies the searching for both live and config detach of netdevices in the subordinate functions of qemuDomainModifyDeviceFlags() to use the new function virDomainNetFindIdx (which matches mac address and PCI address if available, checking for duplicates if only mac address was specified). This function returns -2 if multiple matches are found, allowing the callers to print out an appropriate message. Steps 1 & 2 are enough to fully fix the problem when using virsh attach-device and detach-device (which require an XML description of the device rather than a bunch of commandline args) 3) modifies the virsh detach-interface command to check for multiple matches of mac address and show an error message suggesting use of the detach-device command in cases where there are multiple matching mac addresses. Later we should decide how we want to input a PCI address on the virsh commandline, and enhance detach-interface to take a --address option, eliminating the need to use detach-device * src/conf/domain_conf.c * src/conf/domain_conf.h * src/libvirt_private.syms * added new virDomainNetFindIdx function * removed now unused virDomainNetIndexByMac and virDomainNetRemoveByMac * src/qemu/qemu_driver.c * remove check for duplicate max from qemuDomainAttachDeviceConfig * use virDomainNetFindIdx/virDomainNetRemove instead of virDomainNetRemoveByMac in qemuDomainDetachDeviceConfig * use virDomainNetFindIdx instead of virDomainIndexByMac in qemuDomainUpdateDeviceConfig * src/qemu/qemu_hotplug.c * use virDomainNetFindIdx instead of a homespun loop in qemuDomainDetachNetDevice. * tools/virsh-domain.c: modified detach-interface command as described above
-
由 Eric Blake 提交于
It turns out that the cpuacct results properly account for offline cpus, and always returns results for every possible cpu, not just the online ones. So there is no need to check the map of online cpus in the first place, merely only a need to know the maximum possible cpu. Meanwhile, virNodeGetCPUBitmap had a subtle change from returning the maximum id to instead returning the width of the bitmap (one larger than the maximum id) in commit 2f4c5338, which made this code encounter some off-by-one logic leading to bad error messages when a cpu was offline: $ virsh cpu-stats dom error: Failed to virDomainGetCPUStats() error: An error occurred, but the cause is unknown Cleaning this up unraveled a chain of other unused variables. * src/qemu/qemu_driver.c (qemuDomainGetPercpuStats): Drop pointless check for cpumap changes, and use correct number of cpus. Simplify signature. (qemuDomainGetCPUStats): Adjust caller. * src/nodeinfo.h (nodeGetCPUCount): New prototype. (nodeGetCPUBitmap): Drop unused parameter. * src/nodeinfo.c (nodeGetCPUBitmap): Likewise. (nodeGetCPUMap): Adjust caller. (nodeGetCPUCount): New function. * src/libvirt_private.syms (nodeinfo.h): Export it.
-
由 Eric Blake 提交于
* tools/Makefile.am: Fix tab damage in previous patch.
-
由 Eric Blake 提交于
Patch 61299a1c fixed a long-standing pod error in the man page. But we should be preventing these up front. See also https://bugzilla.redhat.com/show_bug.cgi?id=870273 * tools/Makefile.am (virt-xml-validate.1, virt-pki-validate.1) (virt-host-validate.1, virt-sanlock-cleanup.8, virsh.1): Reject pod conversion errors. * daemon/Makefile.am ($(srcdir)/libvirtd.8.in): Likewise.
-
由 Eric Blake 提交于
Commit 246143b6 fixed a warning on older gcc, but caused a warning on newer gcc. ../../src/rpc/virnetserverservice.c: In function 'virNetServerServiceNewPostExecRestart': ../../src/rpc/virnetserverservice.c:277:41: error: pointer targets in passing argument 3 of 'virJSONValueObjectGetNumberUint' differ in signedness [-Werror=pointer-sign] * src/rpc/virnetserverservice.c: Use correct types.
-
由 Eric Blake 提交于
With older gcc and 64-bit size_t, the compiler issues a real warning: rpc/virnetserverservice.c:277: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] Introduced in commit 0cc79255. Depending on machine endianness, this warning represents a real bug that could mis-interpret the value by a factor of 2^32. I don't know why I couldn't get newer gcc to report the same warning message. * src/rpc/virnetserverservice.c (virNetServerServiceNewPostExecRestart): Use temporary instead.
-
由 Laine Stump 提交于
Found this when building on RHEL5: parallels/parallels_storage.c: In function 'parallelsStorageOpen': parallels/parallels_storage.c:180: error: 'for' loop initial declaration used outside C99 mode (and similar error in parallels_driver.c). This was in spite of configuring with "-Wno-error".
-
- 26 10月, 2012 2 次提交
-
-
由 Philipp Hahn 提交于
Replace '%' by '&' for correct escaping of '>' in Domain specification. Signed-off-by: NPhilipp Hahn <hahn@univention.de>
-
由 Peter Krempa 提交于
Sorting of the .gitignore file was broken after the last addition. After a clean build the scripts re-sort it making the working tree dirty.
-