- 19 2月, 2015 3 次提交
-
-
由 Michal Privoznik 提交于
Upon BLOCK_JOB_COMPLETED event delivery, we check if the job has completed (in qemuMonitorJSONHandleBlockJobImpl()). For better image, the event looks something like this: "timestamp": {"seconds": 1423582694, "microseconds": 372666}, "event": "BLOCK_JOB_COMPLETED", "data": {"device": "drive-virtio-disk0", "len": 8412790784, "offset": 409993216, "speed": 8796093022207, "type": "mirror", "error": "No space left on device"}} If "len" does not equal "offset" it's considered an error, and we can clearly see "error" field filled in. However, later in the event processing this case was handled no differently to case of job being aborted via separate API. It's time that we start differentiate these two because of the future work. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Currently, upon BLOCK_JOB_* event, disk->mirrorState is not updated each time. The callback code handling the events checks if a blockjob was started via our public APIs prior to setting the mirrorState. However, some block jobs may be started internally (e.g. during storage migration), in which case we don't bother with setting disk->mirror (there's nothing we can set it to anyway), or other fields. But it will come handy if we update the mirrorState in these cases too. The event wasn't delivered just for fun - we've started the job after all. So, in this commit, the mirrorState is set to whatever job status we've obtained. Of course, there are some actions on some statuses that we want to perform. But instead of if {} else if {} else {} ... enumeration, let's move to switch(). Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Peter Krempa 提交于
Commit e105dc98 moved some code but didn't adjust the jump labels so that the job would be terminated.
-
- 17 2月, 2015 5 次提交
-
-
由 Pavel Hrdina 提交于
If 'virNumaGetHostNodeset()' fails then the error path will try to free uninitialized pointer mem_mask. Introduced by commit af2a1f05. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Prerna Saxena 提交于
PowerPC : Forbid NULL CPU model with 'host-model' mode in qemu command line. This ensures that an XML such as following: ... <cpu mode='host-model'> <model fallback='allow'/> </cpu> ... will not generate a '-cpu host,compat=(null)' command line with qemu-system-ppc64. Signed-off-by: NPrerna Saxena <prerna@linux.vnet.ibm.com>
-
由 Prerna Saxena 提交于
PowerPC : Explicitly associate 'qemu-system-ppc64' as the default emulator for all 64-bit PowerPC guests ( both Big & Little Endian ) Signed-off-by: NPrerna Saxena <prerna@linux.vnet.ibm.com>
-
由 Luyao Huang 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1126762 Commit 43b67f introduced a deadlock issue when we use numatune to change numa settings to a vm in session mode. Jump to endjob instead of jump to cleanup. Signed-off-by: NLuyao Huang <lhuang@redhat.com>
-
由 Michal Privoznik 提交于
So, when building the '-numa' command line, the qemuBuildMemoryBackendStr() function does quite a lot of checks to chose the best backend, or to check if one is in fact needed. However, it returned that backend is needed even for this little fella: <numatune> <memory mode="strict" nodeset="0,2"/> </numatune> This can be guaranteed via CGroups entirely, there's no need to use memory-backend-ram to let qemu know where to get memory from. Well, as long as there's no <memnode/> element, which explicitly requires the backend. Long story short, we wouldn't have to care, as qemu works either way. However, the problem is migration (as always). Previously, libvirt would have started qemu with: -numa node,memory=X in this case and restricted memory placement in CGroups. Today, libvirt creates more complicated command line: -object memory-backend-ram,id=ram-node0,size=X -numa node,memdev=ram-node0 Again, one wouldn't find anything wrong with these two approaches. Both work just fine. Unless you try to migrated from the older libvirt into the newer one. These two approaches are, unfortunately, not compatible. My suggestion is, in order to allow users to migrate, lets use the older approach for as long as the newer one is not needed. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 13 2月, 2015 2 次提交
-
-
由 Erik Skultety 提交于
We do have a check for valid per-domain security model, however we still do permit an invalid security model for a domain's device (those which are specified with <source> element). This patch introduces a new function virSecurityManagerCheckAllLabel which compares user specified security model against currently registered security drivers. That being said, it also permits 'none' being specified as a device security model. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1165485Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
由 Ján Tomko 提交于
<interface ...> ... <model type='virtio'/> <driver ...> <host mrg_rxbuf='off'/> </driver> </interface> will result in: -device virtio-net-pci,mrg_rxbuf=off,... https://bugzilla.redhat.com/show_bug.cgi?id=1186886
-
- 12 2月, 2015 3 次提交
-
-
由 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>
-
由 Martin Kletzander 提交于
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1178986Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 11 2月, 2015 2 次提交
-
-
由 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
-
由 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>
-
- 10 2月, 2015 10 次提交
-
-
由 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.
-
由 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>
- 06 2月, 2015 2 次提交
-
-
由 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
-
由 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.
-
- 05 2月, 2015 1 次提交
-
-
由 Luyao Huang 提交于
Add the missing jump to the error label when the uuid in the migration cookie XML does not match the uuid of the migrated domain. Signed-off-by: NLuyao Huang <lhuang@redhat.com> Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
- 03 2月, 2015 1 次提交
-
-
由 Daniel P. Berrange 提交于
Some code paths have special logic depending on the page size reported by sysconf, which in turn affects the test results. We must mock this so tests always have a consistent page size.
-
- 31 1月, 2015 7 次提交
-
-
由 Peter Krempa 提交于
Change done by commit f309db1f wrongly assumes that qemu can start with a combination of NUMA nodes specified with the "memdev" option and the appropriate backends, and the legacy way by specifying only "mem" as a size argument. QEMU rejects such commandline though: $ /usr/bin/qemu-system-x86_64 -S -M pc -m 1024 -smp 2 \ -numa node,nodeid=0,cpus=0,mem=256 \ -object memory-backend-ram,id=ram-node1,size=12345 \ -numa node,nodeid=1,cpus=1,memdev=ram-node1 qemu-system-x86_64: -numa node,nodeid=1,cpus=1,memdev=ram-node1: qemu: memdev option must be specified for either all or no nodes To fix this issue we need to check if any of the nodes requires the new definition with the backend and if so, then all other nodes have to use it too. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1182467
-
由 Peter Krempa 提交于
With the new JSON to argv formatter we are now able to represent the memory backend definitions in the JSON object format that is reusable for monitor use (hotplug) and then convert it into the shell string. This will avoid having two separate instances of the same code that would create the different formats. Previous refactors now allow to make this step without changes to the test suite.
-
由 Peter Krempa 提交于
QEMU's command line visitor as well as the JSON interface take bytes by default for memory object sizes. Convert mebibytes to bytes so that we can later refactor the existing code for hotplug purposes.
-
由 Peter Krempa 提交于
QEMU's qapi visitor code allows yes/on/y for true and no/off/n for false value of boolean properities. Unify the used style so that we can generate it later and fix test cases.
-
由 Peter Krempa 提交于
Move the alias as the second formated argument and tweak the tests so that a future refactor that will change the order doesn't break tests.
-
由 Peter Krempa 提交于
Extract the memory backend device code into a separate function so that it can be later easily refactored and reused. Few small changes for future reusability, namely: - new (currently unused) parameter for user specified page size - size of the memory is specified in kibibytes, divided up in the function - new (currently unused) parameter for user specifed source nodeset - option to enforce capability check
-
由 Peter Krempa 提交于
Unlike -device, qemu uses a JSON object to add backend "objects" via the monitor rather than the string that would be passed on the commandline. To be able to reuse code parts that configure backends for various devices, this patch adds a helper that will allow generating the command line representations from the JSON property object.
-
- 30 1月, 2015 3 次提交
-
-
由 Tony Krowiak 提交于
This patch enables synchronization of the host macvtap device options with the guest device's in response to the NIC_RX_FILTER_CHANGED event. The following device options will be synchronized: * PROMISC * MULTICAST * ALLMULTI Signed-off-by: NTony Krowiak <akrowiak@linux.vnet.ibm.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1158034 If we're expecting to create a file somewhere and that fails for some reason during qemuOpenFileAs, then we unlink the path we're attempting to create leaving no way to determine what the "existing" privileges, protections, or labels are that caused the failure (open, change owner and group, change mode, etc.). Furthermore, if we fall into the path where we'll be opening / creating the file using VIR_FILE_OPEN_FORK, we need to first unlink/delete the file we created in the first path; otherwise, the attempt by the child process to open as some specific user:group may fail because the file was already created using nfsnobody:nfsnobody. Again, if we didn't create the file we don't want to blindly delete what already exists. Thus, a second reason for the original check to set need_unlink to false when we find the file with CREAT set, but already existing. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Commit id '540c339a' to fix issues with reference counting and transient domains moved the qemuDomainObjEndAsyncJob call prior to the attempt to restart the guest CPU's resulting in an error: error: Failed to save domain rhel70 to /tmp/pl/rhel70.save error: internal error: unexpected async job 3 when (ret != 0) - eg, the error path from qemuDomainSaveMemory. This patch will adjust the logic to call the EndAsyncJob only after we've tried to restart the guest CPUs. It also needs to adjust the test for qemuDomainRemoveInactive to add the ret == 0 condition. Additionally, if we get to endjob: because of some error earlier, then we need to save that error in the event the CPU restart logic fails. We don't want to return the error from CPU restart failure, rather we want to return the error from the failed save that caused us to fall into the retry to start the CPU logic. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 29 1月, 2015 1 次提交
-
-
由 Michal Privoznik 提交于
Well, even though users can pass the list of UEFI:NVRAM pairs at the configure time, we may maintain the list of widely available UEFI ourselves too. And as arm64 begin to rises, OVMF was ported there too. With a slight name change - it's called AAVMF, with AAVMF_CODE.fd being the UEFI firmware and AAVMF_VARS.fd being the NVRAM store file. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-