- 13 2月, 2015 1 次提交
-
-
由 Pavel Hrdina 提交于
Commit b6a2828e introduced new functions to set process scheduler. There is a small typo in ELSE path for systems where scheduler is not available. Also some of the definitions were introduced later in kernel. For example RHEL-5 is running on kernel 2.6.18, but SCHED_IDLE was introduces in 2.6.23 [1] and SCHED_BATCH in 2.6.16 [1]. We should not count only on existence of function sched_setscheduler(), we must also check for existence of used macros as they might not be defined. [1] see 'man 7 sched' Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
- 12 2月, 2015 11 次提交
-
-
由 Daniel P. Berrange 提交于
While the main storage driver code allows the flag VIR_STORAGE_VOL_RESIZE_SHRINK to be set, none of the backend drivers are supporting it. At the very least this can work for plain file based volumes since we just ftruncate() them to the new size. It does not work with qcow2 volumes, but we can arguably delegate to qemu-img for error reporting for that instead of second guessing this for ourselves: $ virsh vol-resize --shrink /home/berrange/VirtualMachines/demo.qcow2 2G error: Failed to change size of volume 'demo.qcow2' to 2G error: internal error: Child process (/usr/bin/qemu-img resize /home/berrange/VirtualMachines/demo.qcow2 2147483648) unexpected exit status 1: qemu-img: qcow2 doesn't support shrinking images yet qemu-img: This image does not support resize See also https://bugzilla.redhat.com/show_bug.cgi?id=1021802
-
由 Daniel P. Berrange 提交于
The qemuDomainHelperGetVcpus attempted to report an error when the vcpupids info was NULL. Unfortunately earlier code would clamp the value of 'maxinfo' to 0 when nvcpupids was 0, so the error reporting would end up being skipped. This lead to 'virsh vcpuinfo <dom>' just returning an empty list instead of giving the user a clear error.
-
由 Daniel P. Berrange 提交于
If a previous commit I fixed the incorrect handling of vcpu pids for TCG mode QEMU: commit b07f3d82 Author: Daniel P. Berrange <berrange@redhat.com> Date: Thu Dec 18 16:34:39 2014 +0000 Don't setup fake CPU pids for old QEMU The code assumes that def->vcpus == nvcpupids, so when we setup fake CPU pids for old QEMU with nvcpupids == 1, we cause the later code to read off the end of the array. This has fun results like sche_setaffinity(0, ...) which changes libvirtd's own CPU affinity, or even better sched_setaffinity($RANDOM, ...) which changes the affinity of a random OS process. The intent was that this would merely disable the ability to set per-vCPU affinity. It should still have been possible to set VM level host CPU affinity. Unfortunately, when you set <vcpu cpuset='0-1'>4</vcpu>, the XML parser will internally take this & initialize an entry in the def->cputune.vcpupin array for every VCPU. IOW this is implicitly being treated as <cputune> <vcpupin cpuset='0-1' vcpu='0'/> <vcpupin cpuset='0-1' vcpu='1'/> <vcpupin cpuset='0-1' vcpu='2'/> <vcpupin cpuset='0-1' vcpu='3'/> </cputune> Even more fun, the faked cputune elements are hidden from view when querying the live XML, because their cpuset mask is the same as the VM default cpumask. The upshot was that it was impossible to set VM level CPU affinity. To fix this we must update qemuProcessSetVcpuAffinities so that it only reports a fatal error if the per-VCPU cpu mask is different from the VM level cpu mask. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
When initializing a libxl_domain_build_info struct with libxl_domain_build_info_init(), VNC is enabled by default. As a result, VMs configured with no graphics still have VNC enabled. This behavior is a regression wrt to the legacy Xen driver. Signed-off-by: NMarek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
-
Do not silently ignore its value. LibXL support only one address, so refuse multiple IPs. Signed-off-by: NMarek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
-
由 Martin Kletzander 提交于
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1178986Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
In order for QEMU vCPU (and other) threads to run with RT scheduler, libvirt needs to take care of that so QEMU doesn't have to run privileged. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1178986Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
This function uses sched_setscheduler() function so it works with processes and threads as well (even threads not created by us, which is what we'll need in the future). Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Laine Stump 提交于
Prior to commit 7d5bf484 (first appearing in libvirt 1.2.2), the status XML of a domain's interface was missing a lot of important information; mainly it just output the config of the interface, plus the name of the tap device and qemu device alias. Commit 7d5bf484 changed the status XML to include many important bits of information that were required to make network "hook" scripts useful - bandwidth information, vlan tag, the name of the bridge (or physical device in the case of macvtap) that the tap/macvtap device was attached to - the commit log for 7d5bf484 has a very detailed explanation of the change. For quick reference - in the example given there, prior to the change, status XML looked like figure [C]: <interface type='network'> <source network='testnet' portgroup='admin'/> <target dev='macvtap0'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> and after the change, it looked like figure [E]: <interface type='direct'> <source dev='p4p1_0' mode='bridge'/> <bandwidth> <inbound average='1000' peak='5000' burst='1024'/> <outbound average='128' peak='256' burst='256'/> </bandwidth> <target dev='macvtap0'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> You'll notice that bandwidth info, physdev, and macvtap mode have been added, but the network and portgroup names are now missing - I didn't think that this information was of any use once the needed bandwidth/vlan/etc config had been pulled from the network/portgroup. I was wrong. A few months after that change a user on IRC asked what happened to portgroup in the status XML and described how he used it (more or less as a tag to decide what external information to use in a hook script that was run at startup/migration time - see http://wiki.libvirt.org/page/OVS_and_PVLANS ). At that time I planned to make a patch to re-add portgroup, but life intervened as that was just prior to a transatlantic move involving several weeks of "vacation". During this time I somehow forgot to make the patch, and also mistakenly remembered that I *had* made it. Subsequent to this, as a part of mprivozn's work to add support for network-specific hooks, I did re-add the output of the network name in status XML, but once again completely forgot about portgroup. This was in commit a3609121 (first appearing in libvirt 1.2.11). This made the status XML from the above example look like this: <interface type='direct'> <source network='testnet' dev='p4p1_0' mode='bridge'/> <bandwidth> <inbound average='1000' peak='5000' burst='1024'/> <outbound average='128' peak='256' burst='256'/> </bandwidth> <target dev='macvtap0'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> *This* patch just adds the portgroup back to the status XML, so the same example interface will look like this: <interface type='direct'> <source network='testnet' portgroup='admin' dev='p4p1_0' mode='bridge'/> <bandwidth> <inbound average='1000' peak='5000' burst='1024'/> <outbound average='128' peak='256' burst='256'/> </bandwidth> <target dev='macvtap0'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> The result is that the status XML now contains all information about how the interface is setup (bandwidth, physical device, tap device, etc), in addition to pointers to its origin (the network and portgroup).
-
由 Laine Stump 提交于
virDomainGraphicsListenSetAddress() and virDomainGraphicsListenSetNetwork() both set their respective char* to NULL directly when asked to set it to NULL, which is okay as long as it's already set to NULL. If these functions are ever called to clear a listen object that has a valid string in address or network, it will end up leaking the old value. Currently that doesn't happen, so this is just a preemptive strike.
-
由 Laine Stump 提交于
Prior to 0.9.4, libvirt only supported a single listen, and it had to be an IP address: <graphics listen='1.2.3.4' ..../> Starting with 0.9.4, a graphics element could have a <listen> subelement (actually the grammar supports multiples, but all of the drivers only support a single <listen> per <graphics>), and that listen element can be of type='address' or type='network'. For type='address', <listen> also has an attribute called 'address' which contains the IP address for listening: <graphics ....> <listen type='address' address='1.2.3.4' .../> </graphics> type can also be "network", and in that case listen will have a "network" attribute which will contain the name of a libvirt network: <graphics ....> <listen type='network' network='testnet' .../> </graphics> At domain start (or migrate) time, libvirt will attempt to find an IP address associated with that network (e.g. the IP address of the bridge device used by the network, or the physical device listed in <forward dev='physdev'/>) and fill in that address in the status XML: <graphics ....> <listen type='network' network='testnet' address='1.2.3.4' .../> </graphics> In the case that a <graphics> element has a <listen> subelement of type='address', that listen subelement's "address" attribute is backfilled into the parent graphics element's "listen" *attribute* for backward compatibility (so that a management application unaware of the separate <listen> element can still learn the listen address). This backfill should be done with the IP learned from type='network' as well, and that's what this patch does: <graphics listen='1.2.3.4' ....> <listen type='network' network='testnet' address='1.2.3.4' .../> </graphics> This is a continuation of the fix for: https://bugzilla.redhat.com/show_bug.cgi?id=1191016
-
- 11 2月, 2015 5 次提交
-
-
由 John Ferlan 提交于
In the event we're falling into the code that tries to create the file in a forked environment (VIR_FILE_OPEN_FORK) we pass different mode bits, but those are never set because the virFileOpenForceOwnerMode has a check if the OPEN_FORCE_MODE bit is set before attempting to change the mode. Since this is a special case it seems reasonable to set u+rw,g+rw,o
-
由 John Ferlan 提交于
Rather than have a dummy waitpid loop and return of the failure status from recvfd, adjust the logic to save the recvfd error & fd and then in priority order: - if waitpid failed, use that errno value - waitpid succeeded, but if the child exited abnormally, report failure (use EACCES to report as return failure, since either EACCES or EPERM is what caused us to fall into the fork+setuid path) - waitpid succeeded, but if the child reported non-zero status, report failure (use the errno value that the child encoded into exit status) - waitpid succeeded, but if recvfd failed, report recvfd_errno - waitpid and recvfd succeeded, use the fd NOTE: Original logic to retry the open and force owner mode was "documented" as only being attempted if we had already tried opening with the fork+setuid, but checked flags vs. VIR_FILE_OPEN_NOFORK which is counter to how we would get to that point. So that code was removed.
-
由 Luyao Huang 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1191355 When we attempt to migrate a vm with a migrateuri that has no scheme: # virsh migrate test4 --live qemu+ssh://lhuang/system --migrateuri 127.0.0.1 target libvirtd will crash because uri->scheme is NULL in qemuMigrationPrepareDirect on this line: if (STRNEQ(uri->scheme, "tcp") && Add a value check before this line. Also fix a bug like this in doNativeMigrate, that could only happen when destination libvirtd returned an incorrect URI. Signed-off-by: NLuyao Huang <lhuang@redhat.com> Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
由 Zhang Bo 提交于
The function virDomainVcpuPinDel() used vcpupin_list to stand for def->cputune.vcpupin, which made the codes more readable. However, in this function, it will realloc vcpupin_list later. As the definition of realloc(), it may free vcpupin_list and then points it to a new-realloced address, but def->cputune.vcpupin doesn't point to the new address(it's freed however). Thus, 1) When we refer to the def->cputune.vcpupin afterwards, which was freed by realloc(), an INVALID READ occurs, and libvirtd may crash. 2) As no one will use vcpupin_list any more, and no one frees it(it's just alloced by realloc()), memory leak occurs. Part of the valgrind logs are shown as below: ==1837== Thread 15: ==1837== Invalid read of size 8 ==1837== at 0x5367337: virDomainDefFormatInternal (domain_conf.c:18392) which is : virBufferAsprintf(buf, "<vcpupin vcpu='%u' ", def->cputune.vcpupin[i]->vcpuid); ==1837== by 0x536966C: virDomainObjFormat (domain_conf.c:18970) ==1837== by 0x5369743: virDomainSaveStatus (domain_conf.c:19166) ==1837== by 0x117B26DC: qemuDomainPinVcpuFlags (qemu_driver.c:4586) ==1837== by 0x53EA313: virDomainPinVcpuFlags (libvirt.c:9803) ==1837== by 0x14CB7D: remoteDispatchDomainPinVcpuFlags (remote_dispatch.h:6762) ==1837== by 0x14CC81: remoteDispatchDomainPinVcpuFlagsHelper (remote_dispatch.h:6740) ==1837== by 0x5464C30: virNetServerProgramDispatchCall (virnetserverprogram.c:437) ==1837== by 0x546507A: virNetServerProgramDispatch (virnetserverprogram.c:307) ==1837== by 0x171B83: virNetServerProcessMsg (virnetserver.c:172) ==1837== by 0x171E6E: virNetServerHandleJob (virnetserver.c:193) ==1837== by 0x5318E78: virThreadPoolWorker (virthreadpool.c:145) ==1837== Address 0x12ea2870 is 0 bytes inside a block of size 16 free'd ==1837== at 0x4C291AC: realloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==1837== by 0x52A3D14: virReallocN (viralloc.c:245) ==1837== by 0x52A3DFB: virShrinkN (viralloc.c:372) ==1837== by 0x52A3F57: virDeleteElementsN (viralloc.c:503) ==1837== by 0x533939E: virDomainVcpuPinDel (domain_conf.c:15405) //doReset为true时才会进到。 ==1837== by 0x117B2642: qemuDomainPinVcpuFlags (qemu_driver.c:4573) ==1837== by 0x53EA313: virDomainPinVcpuFlags (libvirt.c:9803) ==1837== by 0x14CB7D: remoteDispatchDomainPinVcpuFlags (remote_dispatch.h:6762) ==1837== by 0x14CC81: remoteDispatchDomainPinVcpuFlagsHelper (remote_dispatch.h:6740) ==1837== by 0x5464C30: virNetServerProgramDispatchCall (virnetserverprogram.c:437) ==1837== by 0x546507A: virNetServerProgramDispatch (virnetserverprogram.c:307) ==1837== by 0x171B83: virNetServerProcessMsg (virnetserver.c:172) Steps to reproduce the problem: 1) use virDomainPinVcpuFlags() to pin a guest's vcpu to all the pcpus of the host. This patch uses def->cputune.vcpupin instead of vcpupin_list to do the realloc() job, to avoid invalid read or memory leaking. Signed-off-by: NZhang Bo <oscar.zhangbo@huawei.com> Signed-off-by: Yue Wenyuan <yuewenyuan@huawei.com@huawei.com>
-
由 Erik Skultety 提交于
Parser checks for per-domain seclabel duplicates, so it would be nice if it checked for per-device seclabel duplicates the same way Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1165485
-
- 10 2月, 2015 14 次提交
-
-
由 Luyao Huang 提交于
Signed-off-by: NLuyao Huang <lhuang@redhat.com> Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Luyao Huang 提交于
Export the required helpers and add backend code to hotplug RNG devices. Signed-off-by: NLuyao Huang <lhuang@redhat.com> Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Peter Krempa 提交于
Add support for using the attach/detach device APIs on the inactive configuration to add RNG devices.
-
由 Luyao Huang 提交于
The helpers will be useful when implementing hotplug and coldplug of random number generator devices. Signed-off-by: NLuyao Huang <lhuang@redhat.com> Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Luyao Huang 提交于
Signed-off-by: NLuyao Huang <lhuang@redhat.com>
-
由 Peter Krempa 提交于
As the RNG device is using an -object as backend refactor the code to use the JSON to commandline generator so that we can reuse the code later in hotplug.
-
由 Peter Krempa 提交于
-
由 Peter Krempa 提交于
Move the alias name right after the object type for rng-egd backend so that we can later use the JSON to commandline generator to create the command line.
-
由 Luyao Huang 提交于
Libvirt didn't prefix the random number generator backend object alias with any string thus the device alias and object alias were identical. To avoid possible problems, rename the alias for the backend object and tweak tests to comply with the change. Signed-off-by: NLuyao Huang <lhuang@redhat.com> Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Luyao Huang 提交于
Rename qemuBuildRNGDeviceArgs to qemuBuildRNGDevStr and change the return type so that it can be reused in the device hotplug code later. Signed-off-by: NLuyao Huang <lhuang@redhat.com> Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Luyao Huang 提交于
This function is used to assign an alias for a RNG device. It will be later reused when hotplugging RNGs. Signed-off-by: NLuyao Huang <lhuang@redhat.com> Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Peter Krempa 提交于
When adding devices to the definition it's useful to check whether the devices don't reside on a conflicting address. This patch adds a helper that iterates all device info and compares the addresses with the given info.
-
由 Martin Kletzander 提交于
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1190956Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
- 09 2月, 2015 2 次提交
-
-
由 Erik Skultety 提交于
-
由 Cédric Bosdonnat 提交于
commit a58e1cb4 didn't fix the bug if the security_default_confined is not set to 1. We now clean up even if there is no seclabel defined or the default one.
-
- 06 2月, 2015 6 次提交
-
-
由 Laine Stump 提交于
When defining and creating networks, we have been checking to make sure there is only a single "default" portgroup, but haven't verified that no two portgroups have the same name. We *do* check for multiple definitions when updating the portgroups in an existing network though. This patch adds a check to networkValidate(), which is called when a network is defined or created, to disallow duplicate names. It would actually make sense to do this in the network XML parser (since it's not really "something that might make sense but isn't supported by this driver", but is instead "something that should never be allowed"), but doing that carries the danger of causing errors when rereading the config of existing networks when libvirtd is restarted after an upgrade, and that would result in networks disappearing from libvirt's list. (I'm thinking I should change the error to "XML_ERROR" instead of "UNSUPPORTED", even though that's not the type of error that networkValidate is intended for) This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1115858
-
由 Ján Tomko 提交于
It is only usable for NETWORK and BRIDGE type interfaces. Error out when trying to start a domain where the custom tap device path is specified for interfaces of other types, or when the daemon is not privileged. Note that this cannot be checked at definition time, because the comparison is against actual type. https://bugzilla.redhat.com/show_bug.cgi?id=1147195
-
由 Ján Tomko 提交于
It is only supported for virtio adapters. Silently drop it if it was specified for other models, as is done for other virtio attributes. Also mention this in the documentation. https://bugzilla.redhat.com/show_bug.cgi?id=1147195
-
由 Ján Tomko 提交于
Return 0 instead of ERR_NO_SUPPORT in each driver where we don't support managed save or -1 if the domain does not exist. This avoids spamming daemon logs when 'virsh dominfo' is run. https://bugzilla.redhat.com/show_bug.cgi?id=1095637
-
由 Daniel P. Berrange 提交于
It is often helpful to know which version of libvirt and QEMU was present when a guest was first launched. Ensure this info is written into the QEMU log file for each guest.
-
Otherwise domainCreateWithFlags via remote returns -1 as domid. Signed-off-by: NMarek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
-
- 05 2月, 2015 1 次提交
-
-
由 John Ferlan 提交于
Commit id '652a2ec6' introduced two new node device capability flags and the ability to use those flags as a way to search for a specific subset of a 'scsi_host' device - namely a 'fc_host' and/or 'vports'. The code modified the virNodeDeviceCapMatch whichs allows for searching using the 'virsh nodedev-list [cap]' via virConnectListAllNodeDevices. However, the original patches did not account for other searches for the same capability key from virNodeDeviceNumOfCaps and virNodeDeviceListCaps using nodeDeviceNumOfCaps and nodeDeviceListCaps. Since 'fc_host' and 'vports' are self defined bits of a 'scsi_host' device mere string comparison against the basic/root type is not sufficient. This patch adds the check for the 'fc_host' and 'vports' bits within a 'scsi_host' device and allows the following python code to find the capabilities for the device: import libvirt conn = libvirt.openReadOnly('qemu:///system') devs = conn.listAllDevices() for dev in devs: if 'fc_host' in dev.listCaps() or 'vports' in dev.listCaps(): print dev.name(),dev.numOfCaps(),dev.listCaps()
-