- 14 7月, 2017 1 次提交
-
-
由 John Ferlan 提交于
Ensure two empty lines between functions. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 13 7月, 2017 14 次提交
-
-
由 Daniel P. Berrange 提交于
This reverts commit e4b980c8. When a binary links against a .a archive (as opposed to a shared library), any symbols which are marked as 'weak' get silently dropped. As a result when the binary later runs, those 'weak' functions have an address of 0x0 and thus crash when run. This happened with virtlogd and virtlockd because they don't link to libvirt.so, but instead just libvirt_util.a and libvirt_rpc.a. The virRandomBits symbols was weak and so left out of the virtlogd & virtlockd binaries, despite being required by virHashTable functions. Various other binaries like libvirt_lxc, libvirt_iohelper, etc also link directly to .a files instead of libvirt.so, so are potentially at risk of dropping symbols leading to a later runtime crash. This is normal linker behaviour because a weak symbol is not treated as undefined, so nothing forces it to be pulled in from the .a You have to force the linker to pull in weak symbols using -u$SYMNAME which is not a practical approach. This risk is silent bad linkage that affects runtime behaviour is not acceptable for a fix that was merely trying to fix the test suite. So stop using __weak__ again. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
This reverts commit b9473d8b.
-
由 Martin Kletzander 提交于
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Daniel P. Berrange 提交于
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Jiri Denemark 提交于
When libvirt starts a new QEMU domain, it replaces host-model CPUs with the appropriate custom CPU definition. However, when reconnecting to a domain started by older libvirt (< 2.3), the domain would still have a host-model CPU in its active definition. https://bugzilla.redhat.com/show_bug.cgi?id=1463957Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Jiri Denemark 提交于
qemuProcessReconnect will need to call additional functions which were originally defined further in qemu_process.c. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Jiri Denemark 提交于
Separated from qemuProcessUpdateAndVerifyCPU to handle updating of an active guest CPU definition according to live data from QEMU. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Jiri Denemark 提交于
In addition to updating a guest CPU definition the function verifies that all required features are provided to the guest. Let's make it obvious by calling it qemuProcessUpdateAndVerifyCPU. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Jiri Denemark 提交于
Separated from qemuProcessUpdateLiveGuestCPU. The function makes sure a guest CPU provides all features required by a domain definition. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Jiri Denemark 提交于
Separated from qemuProcessUpdateLiveGuestCPU. Its purpose is to fetch guest CPU data from a running QEMU process. The data can later be used to verify and update the active guest CPU definition. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Jiri Denemark 提交于
CPU features unknown to a hypervisor will not be present in dataDisabled even though the features won't naturally be enabled because. Thus any features we asked for which are not in dataEnabled should be considered disabled. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
When checking ABI stability between two domain definitions, we first make migratable copies of them. However, we also asked for the guest CPU to be updated, even though the updated CPU is supposed to be already included in the original definitions. Moreover, if we do this on the destination host during migration, we're potentially updating the definition with according to an incompatible host CPU. While updating the CPU when checking ABI stability doesn't make any sense, it actually just worked because updating the CPU doesn't do anything for custom CPUs (only host-model CPUs are affected) and we updated both definitions in the same way. Less then a year ago commit v2.3.0-rc1~42 stopped updating the CPU in the definition we got internally and only the user supplied definition was updated. However, the same commit started updating host-model CPUs to custom CPUs which are not affected by the request to update the CPU. So it still seemed to work right, unless a user upgraded libvirt 2.2.0 to a newer version while there were some domains with host-model CPUs running on the host. Such domains couldn't be migrated with a user supplied XML since libvirt would complain: Target CPU mode custom does not match source host-model The fix is pretty straightforward, we just need to stop updating the CPU when checking ABI stability. https://bugzilla.redhat.com/show_bug.cgi?id=1463957Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Juan Hernandez 提交于
Currently the scan of the /proc/mounts file used to find cgroup mount points doesn't take into account that mount points may hidden by other mount points. For, example in certain Kubernetes environments the /proc/mounts contains the following lines: cgroup /sys/fs/cgroup/net_prio,net_cls cgroup ... tmpfs /sys/fs/cgroup tmpfs ... cgroup /sys/fs/cgroup/net_cls,net_prio cgroup ... In this particular environment the first mount point is hidden by the second one. The correct mount point is the third one, but libvirt will never process it because it only checks the first mount point for each controller (net_cls in this case). So libvirt will try to use the first mount point, which doesn't actually exist, and the complete detection process will fail. To avoid that issue this patch changes the virCgroupDetectMountsFromFile function so that when there are duplicates it takes the information from the last line in /proc/mounts. This requires removing the previous explicit condition to skip duplicates, and adding code to free the memory used by the processing of duplicated lines. Related-To: https://bugzilla.redhat.com/1468214 Related-To: https://github.com/kubevirt/libvirt/issues/4Signed-off-by: NJuan Hernandez <jhernand@redhat.com>
-
- 12 7月, 2017 5 次提交
-
-
由 Cole Robinson 提交于
Reviewed-by: NAndrea Bolognani <abologna@redhat.com> Signed-off-by: NCole Robinson <crobinso@redhat.com>
-
由 Cole Robinson 提交于
After 426dc5eb qemuCaps and virDomainDefPtr are unused here, remove it from the call stack Reviewed-by: NAndrea Bolognani <abologna@redhat.com> Signed-off-by: NCole Robinson <crobinso@redhat.com>
-
由 Michal Privoznik 提交于
Obviously, old gcc-s ale sad when a variable shares the name with a function. And we do have such variable (added in 4d8a914b): @mount. Rename it to @mountpoint so that compiler's happy again. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
The way we create devices under /dev is highly linux specific. For instance we do mknod(), mount(), umount(), etc. Some platforms are even missing some of these functions. Then again, as declared in qemuDomainNamespaceAvailable(): namespaces are linux only. Therefore, to avoid obfuscating the code by trying to make it compile on weird platforms, just provide a non-linux stub for qemuDomainAttachDeviceMknodRecursive(). At the same time, qemuDomainAttachDeviceMknodHelper() which actually calls the non-existent functions is moved under ifdef __linux__ block since its only caller is in that block too. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1467826 Commit id 'b9b1aa63' was supposed to add logic to set the allocation for sparse files when wr_highest_offset was zero; however, an unconditional setting was done just prior. For block devices, this means allocation is always returning 0 since 'actual-size' will be zero. Remove the unconditional setting and add the note about it being possible to still be zero for block devices. As soon as the guest starts writing to the volume, the allocation value will then be obtainable from qemu via the wr_highest_offset.
-
- 11 7月, 2017 20 次提交
-
-
由 Peter Krempa 提交于
The API documents that it peeks into the VM disk. We can't do that currently for non raw images so report an error.
-
由 Peter Krempa 提交于
Refactor the access to storage driver usage along with qemuDomainStorageFileInit which ensures that we access the file with correct DAC uid/gid.
-
由 Peter Krempa 提交于
Allow specifying offset to read an arbitrary position in the file. This warrants a rename to virStorageFileRead.
-
由 Peter Krempa 提交于
The helper methods for actually accessing the storage objects don't really belong to the main storage driver implementation file. Split them out.
-
由 Peter Krempa 提交于
Use the full storage driver registration method that also fails if one of the storage backends is not present. This makes the test fail if a submodule fails registration, which is useful for testing. Additionally return EXIT_FAILURE as usual in tests rather than -1.
-
由 Daniel P. Berrange 提交于
The Win32 platform will fail to link if you use weak symbols because it is incompatible with exporting symbols in a DLL: Cannot export virRandomGenerateWWN: symbol wrong type (2 vs 3) We only need weak symbols for our test suite to do LD_PRELOAD and this doesn't work on Win32, so we can just drop the hack for Win32 Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
If we exceed a fixed limit in RPC code we get a horrible message like this, if the parameter type is a 'string', because we forgot to initialize the error message type field: $ virsh snapshot-list ostack1 error: too many remote undefineds: 1329 > 1024 It would also be useful to know which RPC call and field was exceeded. So this patch makes us report: $ virsh snapshot-list ostack1 error: too many remote undefineds: 1329 > 1024, in parameter 'names' for 'virDomainSnapshotListNames' Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Ján Tomko 提交于
On domain startup, bind host or bind service can be omitted and we will format a working command line. Extend this to hotplug as well and specify the service to QEMU even if the host is missing. https://bugzilla.redhat.com/show_bug.cgi?id=1452441
-
由 Ján Tomko 提交于
We have a temporary pointer to the currently processed parameter. Use it to save three bytes per use.
-
由 Ján Tomko 提交于
We assign the unsigned long value of the currently processed parameter to a temporary value_ul variable. Use it consistently in all cases.
-
由 Daniel P. Berrange 提交于
Currently all mockable functions are annotated with the 'noinline' attribute. This is insufficient to guarantee that a function can be reliably mocked with an LD_PRELOAD. The C language spec allows the compiler to assume there is only a single implementation of each function. It can thus do things like propagating constant return values into the caller at compile time, or creating multiple specialized copies of the function body each optimized for a different caller. To prevent these optimizations we must also set the 'noclone' and 'weak' attributes. This fixes the test suite when libvirt.so is built with CLang with optimization enabled. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
The TODO macro expands to an fprintf() call and is used in several places in the Xen driver. Anything that wishes to print such debug messages should use the logging macros. In this case though, all the places in the Xen driver should have been raising a formal libvirt error instead. Add proper error handling and delete the TODO macro to prevent future misuse. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
The HOST_NAME_MAX, INET_ADDRSTRLEN and VIR_LOOPBACK_IPV4_ADDR constants are only used by a handful of files, so are better kept in virsocketaddr.h or the source file that uses them. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
We only ever test libvirt with GCC or CLang which provides a GCC compatible compilation environment. Between them, these compilers cover every important operating system platform, even Windows. Mandate their use to make it explicit that we don't care about compilers like Microsoft VCC or other UNIX vendor C compilers. GCC 4.4 was picked as the baseline, since RHEL-6 ships 4.4.7 and that lets us remove a large set of checks. There is a slight issue that CLang reports itself as GCC 4.2, so we must also check if __clang__ is defined. We could check a particular CLang version too, but that would require someone to figure out a suitable min version which is fun because OS-X reports totally different CLang version numbers from CLang builds on Linux/BSD Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Back in this commit: commit b436a8ae Author: Fabian Freyer <fabian.freyer@physik.tu-berlin.de> Date: Thu Jun 9 00:50:35 2016 +0000 gnulib: add getopt module config-post.h was modified to define __GNUC_PREREQ, but the original definition was never removed from internal.h, and that is now dead code since config.h is always the first file included. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Michal Privoznik 提交于
Currently, the only type of chardev that we create the backend for in the namespace is type='dev'. This is not enough, other backends might have files under /dev too. For instance channels might have a unix socket under /dev (well, bind mounted under /dev from a different place). Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1462060 Just like in the previous commit, when attaching a file based device which has its source living under /dev (that is not a device rather than a regular file), calling mknod() is no help. We need to: 1) bind mount device to some temporary location 2) enter the namespace 3) move the mount point to desired place 4) umount it in the parent namespace from the temporary location At the same time, the check in qemuDomainNamespaceSetupDisk makes no longer sense. Therefore remove it. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1462060 When building a qemu namespace we might be dealing with bare regular files. Files that live under /dev. For instance /dev/my_awesome_disk: <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/dev/my_awesome_disk'/> <target dev='vdc' bus='virtio'/> </disk> # qemu-img create -f qcow2 /dev/my_awesome_disk 10M So far we were mknod()-ing them which is obviously wrong. We need to touch the file and bind mount it to the original: 1) touch /var/run/libvirt/qemu/fedora.dev/my_awesome_disk 2) mount --bind /dev/my_awesome_disk /var/run/libvirt/qemu/fedora.dev/my_awesome_disk Later, when the new /dev is built and replaces original /dev the file is going to live at expected location. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Michal Privoznik 提交于
Currently, we silently assume that file we are creating in the namespace is either a link or a device (character or block one). This is not always the case. Therefore instead of doing something wrong, claim about unsupported file type. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Michal Privoznik 提交于
Currently, we silently assume that file we are creating in the namespace is either a link or a device (character or block one). This is not always the case. Therefore instead of doing something wrong, claim about unsupported file type. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-