- 14 10月, 2013 1 次提交
-
-
由 Peter Krempa 提交于
The regular save image code has the support to compress images using a specified algorithm. This was not implemented for managed save although it shares most of the backend code.
-
- 11 10月, 2013 5 次提交
-
-
由 Michal Privoznik 提交于
After my patches, some functions gained one more argument (@listenAddress) which wasn't included in debug printing of arguments they were called with. Functions in question are: qemuMigrationPrepareDirect and qemuMigrationPerform. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
I've noticed a SIGSEGV-ing libvirtd on the destination when the qemu died too quickly = in Prepare phase. What is happening here is: 1) [Thread 3493] We are in qemuMigrationPrepareAny() and calling qemuProcessStart() which subsequently calls qemuProcessWaitForMonitor() and qemuConnectMonitor(). So far so good. The qemuMonitorOpen() succeeds, however switching monitor to QMP mode fails as qemu died meanwhile. That is qemuMonitorSetCapabilities() returns -1. 2013-10-08 15:54:10.629+0000: 3493: debug : qemuMonitorSetCapabilities:1356 : mon=0x14a53da0 2013-10-08 15:54:10.630+0000: 3493: debug : qemuMonitorJSONCommandWithFd:262 : Send command '{"execute":"qmp_capabilities","id":"libvirt-1"}' for write with FD -1 2013-10-08 15:54:10.630+0000: 3493: debug : virEventPollUpdateHandle:147 : EVENT_POLL_UPDATE_HANDLE: watch=17 events=13 ... 2013-10-08 15:54:10.631+0000: 3493: debug : qemuMonitorSend:956 : QEMU_MONITOR_SEND_MSG: mon=0x14a53da0 msg={"execute":"qmp_capabilities","id":"libvirt-1"} fd=-1 2013-10-08 15:54:10.631+0000: 3262: debug : virEventPollRunOnce:641 : Poll got 1 event(s) 2) [Thread 3262] The event loop is trying to do the talking to monitor. However, qemu is dead already, remember? 2013-10-08 15:54:13.436+0000: 3262: error : qemuMonitorIORead:551 : Unable to read from monitor: Connection reset by peer 2013-10-08 15:54:13.516+0000: 3262: debug : virFileClose:90 : Closed fd 25 ... 2013-10-08 15:54:13.533+0000: 3493: debug : qemuMonitorSend:968 : Send command resulted in error internal error: early end of file from monitor: possible problem: 3) [Thread 3493] qemuProcessStart() failed. No big deal. Go to the 'endjob' label and subsequently to the 'cleanup'. Since the domain is not persistent and ret is -1, the qemuDomainRemoveInactive() is called. This has an (unpleasant) effect of virObjectUnref()-in the @vm object. Unpleasant because the event loop which is about to trigger EOF callback still holds a pointer to the @vm (not the reference). See the valgrind output below. 4) [Thread 3262] So the event loop starts triggering EOF: 2013-10-08 15:54:13.542+0000: 3262: debug : qemuMonitorIO:729 : Triggering EOF callback 2013-10-08 15:54:13.543+0000: 3262: debug : qemuProcessHandleMonitorEOF:294 : Received EOF on 0x14549110 'migt10' And the monitor is cleaned up. This results in calling qemuProcessHandleMonitorEOF with the @vm pointer passed. The pointer is kept in qemuMonitor struct. ==3262== Thread 1: ==3262== Invalid read of size 4 ==3262== at 0x77ECCAA: pthread_mutex_lock (in /lib64/libpthread-2.15.so) ==3262== by 0x52FAA06: virMutexLock (virthreadpthread.c:85) ==3262== by 0x52E3891: virObjectLock (virobject.c:320) ==3262== by 0x11626743: qemuProcessHandleMonitorEOF (qemu_process.c:296) ==3262== by 0x11642593: qemuMonitorIO (qemu_monitor.c:730) ==3262== by 0x52BD526: virEventPollDispatchHandles (vireventpoll.c:501) ==3262== by 0x52BDD49: virEventPollRunOnce (vireventpoll.c:648) ==3262== by 0x52BBC68: virEventRunDefaultImpl (virevent.c:274) ==3262== by 0x542D3D9: virNetServerRun (virnetserver.c:1112) ==3262== by 0x11F368: main (libvirtd.c:1513) ==3262== Address 0x14549128 is 24 bytes inside a block of size 136 free'd ==3262== at 0x4C2AF5C: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==3262== by 0x529B1FF: virFree (viralloc.c:580) ==3262== by 0x52E3703: virObjectUnref (virobject.c:270) ==3262== by 0x531557E: virDomainObjListRemove (domain_conf.c:2355) ==3262== by 0x1160E899: qemuDomainRemoveInactive (qemu_domain.c:2061) ==3262== by 0x1163A0C6: qemuMigrationPrepareAny (qemu_migration.c:2450) ==3262== by 0x1163A923: qemuMigrationPrepareDirect (qemu_migration.c:2626) ==3262== by 0x11682D71: qemuDomainMigratePrepare3Params (qemu_driver.c:10309) ==3262== by 0x53B0976: virDomainMigratePrepare3Params (libvirt.c:7266) ==3262== by 0x1502D3: remoteDispatchDomainMigratePrepare3Params (remote.c:4797) ==3262== by 0x12DECA: remoteDispatchDomainMigratePrepare3ParamsHelper (remote_dispatch.h:5741) ==3262== by 0x54322EB: virNetServerProgramDispatchCall (virnetserverprogram.c:435) The mon->vm is set in qemuMonitorOpenInternal() which is the correct place to increase @vm ref counter. The correct place to decrease the ref counter is then qemuMonitorDispose(). Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
This configuration knob is there to override default listen address for -incoming for all qemu domains. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=994364 Whenever we check for ABI stability, we have new xml (e.g. provided by user, or obtained from snapshot, whatever) which we compare to old xml and see if ABI won't break. However, if the new xml was produced via virDomainGetXMLDesc(..., VIR_DOMAIN_XML_MIGRATABLE) it lacks some devices, e.g. 'pci-root' controller. Hence, the ABI stability check fails even though it is stable. Moreover, we can't simply fix virDomainDefCheckABIStability because removing the correct devices is task for the driver. For instance, qemu driver wants to remove the usb controller too, while LXC driver doesn't. That's why we need special qemu wrapper over virDomainDefCheckABIStability which removes the correct devices from domain XML, produces MIGRATABLE xml and calls the check ABI stability function. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 10 10月, 2013 6 次提交
-
-
由 Michal Privoznik 提交于
At the beginning of the function qemuPrepareHostdevPCICheckSupport() is called. After that @pcidevs is initialized. However, if the very first command fails, we go to 'cleanup' label where virObjectUnref(pcidevs) is called. Obviously, it is called before @pcidevs was able to get initialized. Compiler warns about it: CC qemu/libvirt_driver_qemu_impl_la-qemu_hostdev.lo qemu/qemu_hostdev.c: In function 'qemuPrepareHostdevPCIDevices': qemu/qemu_hostdev.c:824:19: error: 'pcidevs' may be used uninitialized in this function [-Werror=maybe-uninitialized] virObjectUnref(pcidevs); ^ cc1: all warnings being treated as errors
-
由 Peter Krempa 提交于
Prefer using VFIO (if available) to the legacy KVM device passthrough. With this patch a PCI passthrough device without the driver configured will be started with VFIO if it's available on the host. If not legacy KVM passthrough is checked and error is reported if it's not available.
-
由 Peter Krempa 提交于
Add code to check availability of PCI passhthrough using VFIO and the legacy KVM passthrough and use it when starting VMs and hotplugging devices to live machine.
-
由 Peter Krempa 提交于
-
由 Peter Krempa 提交于
-
由 Peter Krempa 提交于
Avoid mixed brace style in an if statement and fix formatting of error messages.
-
- 08 10月, 2013 1 次提交
-
-
由 Peter Krempa 提交于
To simplify future patches dealing with this code, simplify and refactor some conditions to switch statements.
-
- 07 10月, 2013 1 次提交
-
-
由 Daniel P. Berrange 提交于
The virConnectPtr is passed around loads of nwfilter code in order to provide it as a parameter to the callback registered by the virt drivers. None of the virt drivers use this param though, so it serves no purpose. Avoiding the need to pass a virConnectPtr means that the nwfilterStateReload method no longer needs to open a bogus QEMU driver connection. This addresses a race condition that can lead to a crash on startup. The nwfilter driver starts before the QEMU driver and registers some callbacks with DBus to detect firewalld reload. If the firewalld reload happens while the QEMU driver is still starting up though, the nwfilterStateReload method will open a connection to the partially initialized QEMU driver and cause a crash. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 04 10月, 2013 3 次提交
-
-
由 Peter Krempa 提交于
When starting the VM the guest balloon driver is not loaded at that time. We need to ask numad for placement of the complete VM.
-
由 Cole Robinson 提交于
-
由 Cole Robinson 提交于
Makes things more readable IMO
-
- 03 10月, 2013 3 次提交
-
-
由 Laine Stump 提交于
This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1012824 https://bugzilla.redhat.com/show_bug.cgi?id=1012834 Note that a similar problem was reported in: https://bugzilla.redhat.com/show_bug.cgi?id=827519 but the fix only worked for <interface type='hostdev'>, *not* for <interface type='network'> where the network itself was a pool of hostdevs. The symptom in both cases was this error message: internal error: Unable to determine device index for network device In both cases the cause was lack of proper handling for netdevs (<interface>) of type='hostdev' when scanning the netdev list looking for alias names in qemuAssignDeviceNetAlias() - those that aren't type='hostdev' have an alias of the form "net%d", while those that are hostdev use "hostdev%d". This special handling was completely lacking prior to the fix for Bug 827519 which was: When searching for the highest alias index, libvirt looks at the alias for each netdev and if it is type='hostdev' it ignores the entry. If the type is not hostdev, then it expects the "net%d" form; if it doesn't find that, it fails and logs the above error message. That fix works except in the case of <interface type='network'> where the network uses hostdev (i.e. the network is a pool of VFs to be assigned to the guests via PCI passthrough). In this case, the check for type='hostdev' would fail because it was done as: def->net[i]->type == VIR_DOMAIN_NET_TYPE_HOSTDEV (which compares what was written in the config) when it actually should have been: virDomainNetGetActualType(def->net[i]) == VIR_DOMAIN_NET_TYPE_HOSTDEV (which compares the type of netdev that was actually allocated from the network at runtime). Of course the latter wouldn't be of any use if the netdevs of type='network' hadn't already acquired their actual network connection yet, but manual examination of the code showed that this is never the case. While looking through qemu_command.c, two other places were found to directly compare the net[i]->type field rather than getting actualType: * qemuAssignDeviceAliases() - in this case, the incorrect comparison would cause us to create a "net%d" alias for a netdev with type='network' but actualType='hostdev'. This alias would be subsequently overwritten by the proper "hostdev%d" form, so everything would operate properly, but a string would be leaked. This patch also fixes this problem. * qemuAssignDevicePCISlots() - would defer assigning a PCI address to a netdev if it was type='hostdev', but not for type='network + actualType='hostdev'. In this case, the actual device usually hasn't been acquired yet anyway, and even in the case that it has, there is no practical difference between assigning a PCI address while traversing the netdev list or while traversing the hostdev list. Because changing it would be an effective NOP (but potentially cause some unexpected regression), this usage was left unchanged.
-
由 Michal Privoznik 提交于
After successful @cmd construction the memory where @keys points to is part of @cmd. Avoid double freeing it.
-
由 Michal Privoznik 提交于
When querying for kvm, we try to find 'enabled' field. Hence the error message should report we haven't found 'enabled' and not 'running' (which is not even in the reply). Probably a typo or copy-paste error.
-
- 02 10月, 2013 1 次提交
-
-
由 Michal Privoznik 提交于
The qemuDomainChangeNet() is called when 'virsh update-device' is invoked on a NIC. Currently, we fail to update the QoS even though we have routines for that. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 01 10月, 2013 2 次提交
-
-
由 Cole Robinson 提交于
We can dereference graphics[0] even if guest has no graphics device configured. I screwed this up in a216e648 https://bugzilla.redhat.com/show_bug.cgi?id=1014088
-
由 Michal Privoznik 提交于
This basically covers the talking-to-monitor part of virQEMUCapsInitQMP. The patch itself has no real value, but it creates an entity to be tested in the next patches. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 30 9月, 2013 1 次提交
-
-
由 Peter Krempa 提交于
The change in ef29de14 that introduced better error logging from qemu introduced a warning from coverity about unused return value from lseek. Silence this warning and fix typo in the corresponding error message. Reported by: John Ferlan
-
- 27 9月, 2013 2 次提交
-
-
由 Jiri Denemark 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1011330 (case A) While activeScsiHostdevs and webSocketPorts were allocated in qemuStateInitialize, they were not freed in qemuStateCleanup. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1011330 (case D) qemuProcessStart created two references to virQEMUDriverConfigPtr before calling fork(): cfg = virQEMUDriverGetConfig(driver); ... hookData.cfg = virObjectRef(cfg); However, the child only unreferenced hookData.cfg and the parent only removed the cfg reference. That said, we don't need to increment the reference counter when assigning cfg to hookData. Both the child and the parent will correctly remove the reference on cfg (the child will do that through hookData). Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 26 9月, 2013 1 次提交
-
-
由 Chen Hanxiao 提交于
The return value of virDomainControllerFind >=0 means that the specific controller was found. But some functions invoke it and treat 0 as not found. This patch fix these incorrect invocation. Signed-off-by: NChen Hanxiao <chenhanxiao@cn.fujitsu.com>
-
- 25 9月, 2013 13 次提交
-
-
由 Daniel P. Berrange 提交于
If qemuParseCommandLine finds an arg it does not understand it adds it to the QEMU passthrough custom arg list. If the qemuParseCommandLine method hits an error for any reason though, it just does 'VIR_FREE(cmd)' on the custom arg list. This means all actual args / env vars are leaked. Introduce a qemuDomainCmdlineDefFree method to be used for cleanup. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
If the call to virDomainControllerInsert fails in qemuParseCommandLine, the controller struct is leaked. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
The 'qemuStringToArgvEnv' method splits up a string of command line env/args to an 'arglist' array. It then copies env vars to a 'progenv' array and args to a 'progargv' array. When copyin the env vars, it NULL-ifies the element in 'arglist' that is copied. Upon OOM the 'virStringListFree' is called on progenv and arglist. Unfortunately, because the elements in 'arglist' related to env vars have been set to NULL, the call to virStringListFree(arglist) doesn't free anything, even though some non-NULL args vars still exist later in the array. To fix this leak, stop NULL-ifying the 'arglist' elements, and change the cleanup code to only free elements in the 'arglist' array, not 'progenv'. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
In a number of places in qemuParseCommandLineDisk, an error is reported, but no 'goto error' jump is used. This causes failure to report OOM conditions to the caller. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
If OOM occurs in qemuParseCommandLineDisk some intermediate variables will be leaked when parsing Sheepdog or RBD disks. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
The qemuBuildCommandLine code for parsing sound cards will leak an intermediate variable if an OOM occurs. Move the free'ing of the variable earlier to avoid the leak. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
In qemuParseNBDString, if the virURIParse fails, the error is not reported to the caller. Instead execution falls through to the non-URI codepath causing memory leaks later on. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
If qemuAddRBDHost fails due to parsing problems or OOM, then qemuParseRBDString cleanup is skipped causing a memory leak. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
qemuDomainPCIAddressGetNextSlot has a loop for finding compatible PCI buses. In the loop body it creates a PCI address string, but never frees this. This causes a leak if the loop executes more than one iteration, or if a call in the loop body fails. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Laine Stump 提交于
This resolves one of the issues listed in: https://bugzilla.redhat.com/show_bug.cgi?id=1003983 00:1E.0 is the location of this controller on at least some actual Q35 hardware, so we try to replicate the placement. The bridge should work just as well in any other location though, so if 00:1E.0 isn't available, just allow it to be auto-assigned anywhere appropriate.
-
由 Laine Stump 提交于
This will make it simpler to add checks for other types of controllers. This is a prerequisite for patches to resolve: https://bugzilla.redhat.com/show_bug.cgi?id=1003983
-
由 Laine Stump 提交于
This resolves one of the issues in: https://bugzilla.redhat.com/show_bug.cgi?id=1003983 This device is identical to qemu's "intel-hda" device (known as "ich6" in libvirt), but has a different PCI device ID (which matches the ID of the hda audio built into the ich9 chipset, of course). It's not supported in earlier versions of qemu, so it requires a capability bit.
-
由 Laine Stump 提交于
I'm not sure why this code was written to compare the strings that it had just retrieved from an enum->string conversion, rather than just look at the original enum values, but this yields the same results, and is much more efficient (especially as you add more devices). This is a prerequisite for patches to resolve: https://bugzilla.redhat.com/show_bug.cgi?id=1003983
-