- 15 4月, 2015 3 次提交
-
-
由 Peter Krempa 提交于
-
由 Peter Krempa 提交于
-
由 Peter Krempa 提交于
Fix line spacing between functions, ensure that function return type is on a separate line and reflow arguments for VIR_DEBUG statements.
-
- 14 4月, 2015 16 次提交
-
-
由 John Ferlan 提交于
Forthcoming syntax check rule will disallow usage of 'int index', so change it for snapshot
-
由 John Ferlan 提交于
Changing the prototype to not have "int *index" since we'll soon be disallowing index as a name. Curiously the original commit (a4504ac1) for the function used 'int idx' in the function - so they didn't match. Now they do.
-
由 Martin Kletzander 提交于
It is there even with -nodefaults and -no-user-config, so count with that so we can start sparc domains. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Huanle Han 提交于
1. 'last_good_net' indicates the index of last successfully configured net. so def->nets[last_good_net] should also be clean up if error occurs. 2. if error occurs in 'virNetDevMacVLanVPortProfileRegisterCallback' (second 'goto err_exit' in loop), we should also do 'virNetDevVPortProfileDisassociate' cleanup for the 'virNetDevVPortProfileAssociate'(first code block in loop). So we should consider the net is successfully configured after first code block in loop finishes. Signed-off-by: NHuanle Han <hanxueluo@gmail.com>
-
由 Shanzhi Yu 提交于
After set memory parameters for running domain, save the change to live xml is needed otherwise it will disappear after restart libvirtd. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1211548Signed-off-by: NShanzhi Yu <shyu@redhat.com> Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
由 John Ferlan 提交于
Apparently for Xen-devel 'index' is a global and causes a build failure, so just use the shortened 'idx' instead to avoid the conflict. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Peter Krempa 提交于
Change few variable names and refactor the code flow. As an additional bonus the function now fails if the event state is not as expected.
-
由 Peter Krempa 提交于
QEMU does not abandon the mirror. The job carries on in the synchronised phase and it might be either pivoted again or cancelled. The commit hints that the described behavior was happening in a downstream version. If the command returns false there are two possible options: 1) qemu did not reach the point where it would ask the block job to pivot 2) pivotting failed in the actual qemu coroutine If either of those would happen we return failure and reset the condition that waits for the block job to complete. This makes the API fail but in case where qemu would actually abandon the mirror the fact is notified via the event and handled asynchronously. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1202704
-
由 Peter Krempa 提交于
Since it now handles only block pull code paths we can refactor it and remove tons of cruft.
-
由 Peter Krempa 提交于
Sacrifice a few lines of code in favor of the code being more readable.
-
由 Peter Krempa 提交于
qemuDomainBlockJobImpl become an unmaintainable mess over the years of adding new stuff to it. This patch starts splitting up individual functions from it until it can be killed entirely. In bulk this will add lines of code rather than delete them but it will be traded for maintainability.
-
由 Peter Krempa 提交于
My intention is to split qemuMonitorJSONBlockJob() into simpler separate functions for every block job type. Since the error handling code is the same for all block jobs, this patch extracts the code into a separate function that will later be reused in more places. With the new helper qemuMonitorJSONErrorIsClass we can save a few function calls as we can extract the error object once.
-
由 Peter Krempa 提交于
Split out the function that checks the actual error class string into a separate helper as it will be useful later and refactor qemuMonitorJSONHasError to return bool type and remove few useless checks. Basically virJSONValueObjectHasKey are useless here since the next call to virJSONValueObjectGet is checking the return value again (which can't fail at that point). By removing the first check we save a function call.
-
由 Peter Krempa 提交于
Previously we checked that the vcpu we are trying to set is in range of the number of threads presented by qemu. The problem is that if the VM is offline the count is 0. Since the condition subtracted 1 from the count the number would overflow and the check would never trigger. Change the condition for more sensible ones with specific error messages. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1208434
-
由 Peter Krempa 提交于
Operating systems use the identifier to name the disks. As the name suggests the ID should be unique. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1208009
-
由 John Ferlan 提交于
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 13 4月, 2015 4 次提交
-
-
由 Erik Skultety 提交于
This patch adds checks for empty bitmaps right after the calls of virBitmapParse. These only include spots where set API's are called and where domain's XML is parsed. Also, it partially reverts commit 983f5a which added a check for invalid nodeset "0,^0" into virBitmapParse function. This change broke the logic, as an empty bitmap should not cause an error. https://bugzilla.redhat.com/show_bug.cgi?id=1210545
-
由 Ján Tomko 提交于
On arm, we probe for virtio-*-pci devices, but use their virtio-*-device variants. Set the capabilities based on the -device variants as well, to make them work with qemus with the PCI devices compiled out.
-
由 Michal Privoznik 提交于
When pre-creating storage for domains, we need to find corresponding disk in the XML on the destination (domain XML may differ there, e.g. disk is accessible under different path). For better debugging, I'm printing all info I received on a disk. But there was a typo when printing the disk capacity: "%lluu" instead of "%llu". Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Xing Lin 提交于
The problem with the previous implementation is, even when qemuMigrationUpdateJobStatus() detects a migration job has completed, it will do a sleep for 50 ms (which is unnecessary and only adds up to the VM pause time). Signed-off-by: NXing Lin <xinglin@cs.utah.edu> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 11 4月, 2015 1 次提交
-
-
由 John Ferlan 提交于
Future IOThread setting patches would copy the code anyway, so create and generalize the adding of pindef for the vcpu and the pinning of the thread into their own APIs.
-
- 10 4月, 2015 4 次提交
-
-
由 Dmitry Guryanov 提交于
We support VNC for containers to have the same interface with VMs. At this moment it just renders linux text console. Of course we don't pass any physical devices and don't emulate virtual devices. Our VNC server renders text from terminal master and sends input events from VNC client to terminal. So add special video type VIR_DOMAIN_VIDEO_TYPE_PARALLELS for these pseudo-devices. Signed-off-by: NDmitry Guryanov <dguryanov@parallels.com>
-
由 John Ferlan 提交于
Future IOThread setting patches would copy the code anyway, so create and generalize a delete cgroup and pindef for the vcpu into its own API. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Future IOThread setting patches would copy the code anyway, so create and generalize the add the vcpu to a cgroup into its own API. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Replace the virCgroupNew{Vcpu|Emulator|IOThread} calls with the common virCgroupNewThread API Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 09 4月, 2015 6 次提交
-
-
由 Peter Krempa 提交于
Old compilers whine that 'sync' is being shadowed in the function introduced in 1eccac1d.
-
由 Peter Krempa 提交于
Support for drive-reopen was never present in the upstream code so we don't need to pause the VM when doing the block pivot. Kill all the code related to this semi-upstream artifact.
-
由 Peter Krempa 提交于
There are two leftover unused variables. Remove them and clean up the fallout of the change.
-
由 Peter Krempa 提交于
Refactor the function to use the new helpers.
-
由 Peter Krempa 提交于
We need to check that qemu supports block jobs in multiple places. Add a helper to do the check.
-
由 Peter Krempa 提交于
In some cases where the function does not need to access the private data this helper may be used to retrieve the monitor object.
-
- 08 4月, 2015 6 次提交
-
-
由 Luyao Huang 提交于
131,088 bytes in 16 blocks are definitely lost in loss record 2,174 of 2,176 at 0x4C29BFD: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) by 0x4C2BACB: realloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) by 0x52A026F: virReallocN (viralloc.c:245) by 0x52BFCB5: saferead_lim (virfile.c:1268) by 0x52C00EF: virFileReadLimFD (virfile.c:1328) by 0x52C019A: virFileReadAll (virfile.c:1351) by 0x52A5D4F: virCgroupGetValueStr (vircgroup.c:763) by 0x1DDA0DA3: qemuRestoreCgroupState (qemu_cgroup.c:805) by 0x1DDA0DA3: qemuConnectCgroup (qemu_cgroup.c:857) by 0x1DDB7BA1: qemuProcessReconnect (qemu_process.c:3694) by 0x52FD171: virThreadHelper (virthread.c:206) by 0x82B8DF4: start_thread (pthread_create.c:308) by 0x85C31AC: clone (clone.S:113) Signed-off-by: NLuyao Huang <lhuang@redhat.com>
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1198645 Once upon a time, there was a little domain. And the domain was pinned onto a NUMA node and hasn't fully allocated its memory: <memory unit='KiB'>2355200</memory> <currentMemory unit='KiB'>1048576</currentMemory> <numatune> <memory mode='strict' nodeset='0'/> </numatune> Oh little me, said the domain, what will I do with so little memory. If I only had a few megabytes more. But the old admin noticed the whimpering, barely audible to untrained human ear. And good admin he was, he gave the domain yet more memory. But the old NUMA topology witch forbade to allocate more memory on the node zero. So he decided to allocate it on a different node: virsh # numatune little_domain --nodeset 0-1 virsh # setmem little_domain 2355200 The little domain was happy. For a while. Until bad, sharp teeth shaped creature came. Every process in the system was afraid of him. The OOM Killer they called him. Oh no, he's after the little domain. There's no escape. Do you kids know why? Because when the little domain was born, her father, Libvirt, called numa_set_membind(). So even if the admin allowed her to allocate memory from other nodes in the cgroups, the membind() forbid it. So what's the lesson? Libvirt should rely on cgroups, whenever possible and use numa_set_membind() as the last ditch effort. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michael Chapman 提交于
Currently we check qemuCaps before starting the block job. But qemuCaps isn't available on a stopped domain, which means we get a misleading error message in this case: # virsh domstate example shut off # virsh blockjob example vda error: unsupported configuration: block jobs not supported with this QEMU binary Move the qemuCaps check into the block job so that we are guaranteed the domain is running. Signed-off-by: NMichael Chapman <mike@very.puzzling.org>
-
由 Michael Chapman 提交于
qemuMigrationCookieAddNBD is usually called from within an async MIGRATION_OUT or MIGRATION_IN job, so it needs to start a nested job. (The one exception is during the Begin phase when change protection isn't enabled, but qemuDomainObjEnterMonitorAsync will behave the same as qemuDomainObjEnterMonitor in this case.) This bug was encountered with a libvirt client that repeatedly queries the disk mirroring block job info during a migration. If one of these queries occurs just as the Perform migration cookie is baked, libvirt crashes. Relevant logs are as follows: 6701: warning : qemuDomainObjEnterMonitorInternal:1544 : This thread seems to be the async job owner; entering monitor without asking for a nested job is dangerous [1] 6701: info : qemuMonitorSend:972 : QEMU_MONITOR_SEND_MSG: mon=0x7fefdc004700 msg={"execute":"query-block","id":"libvirt-629"} [2] 6699: info : qemuMonitorIOWrite:503 : QEMU_MONITOR_IO_WRITE: mon=0x7fefdc004700 buf={"execute":"query-block","id":"libvirt-629"} [3] 6704: info : qemuMonitorSend:972 : QEMU_MONITOR_SEND_MSG: mon=0x7fefdc004700 msg={"execute":"query-block-jobs","id":"libvirt-630"} [4] 6699: info : qemuMonitorJSONIOProcessLine:203 : QEMU_MONITOR_RECV_REPLY: mon=0x7fefdc004700 reply={"return": [...], "id": "libvirt-629"} 6699: error : qemuMonitorJSONIOProcessLine:211 : internal error: Unexpected JSON reply '{"return": [...], "id": "libvirt-629"}' At [1] qemuMonitorBlockStatsUpdateCapacity sends its request, then waits on mon->notify. At [2] the request is written out to the monitor socket. At [3] qemuMonitorBlockJobInfo sends its request, and also waits on mon->notify. The reply from the first request is received at [4]. However, qemuMonitorJSONIOProcessLine is not expecting this reply since the second request hadn't completed sending. The reply is dropped and an error is returned. qemuMonitorIO signals mon->notify twice during its error handling, waking up both of the threads waiting on it. One of them clears mon->msg as it exits qemuMonitorSend; the other crashes: qemuMonitorSend (mon=0x7fefdc004700, msg=<value optimized out>) at qemu/qemu_monitor.c:975 975 while (!mon->msg->finished) { (gdb) print mon->msg $1 = (qemuMonitorMessagePtr) 0x0 Signed-off-by: NMichael Chapman <mike@very.puzzling.org>
-
由 Michael Chapman 提交于
If a VM migration is aborted, a disk mirror may be failed by QEMU before libvirt has a chance to cancel it. The disk->mirrorState remains at _ABORT in this case, and this breaks subsequent mirrorings of that disk. We should instead check the mirrorState directly and transition to _NONE if it is already aborted. Do the check *after* aborting the block job in QEMU to avoid a race. Signed-off-by: NMichael Chapman <mike@very.puzzling.org>
-
由 Michael Chapman 提交于
If virCloseCallbacksSet fails, qemuMigrationBegin must return NULL to indicate an error occurred. Signed-off-by: NMichael Chapman <mike@very.puzzling.org>
-