- 27 4月, 2017 4 次提交
-
-
由 Nikolay Shirokovskiy 提交于
Becase it can be called during migration out (namely on cancelling blockjobs). Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Peter Krempa 提交于
qemuDomainGetNumaParameters would return the automatic nodeset even for the persistent config if the domain was running. This is incorrect since the automatic nodeset will be re-queried upon starting the vm. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1445325
-
由 Jiri Denemark 提交于
While peer-to-peer migration enters the Confirm phase even if the Perform phase fails, the client which initiated a non-p2p migration will never call virDomainMigrateConfirm* API if the Perform phase failed. Thus we need to explicitly reset migration before reporting a failure from the Perform phase API. https://bugzilla.redhat.com/show_bug.cgi?id=1425003Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Migration with old QEMU which does not support query-migrate-parameters would fail because the QMP command is called unconditionally since the introduction of TLS migration. Previously it was only called if the user explicitly requested a feature which uses QEMU migration parameters. And even then the situation was not ideal, instead of reporting an unsupported feature we'd just complain about missing QMP command. Trivially no migration parameters are supported when query-migrate-parameters QMP command is missing. There's no need to report an error if it is missing, the callers will report better error if needed. https://bugzilla.redhat.com/show_bug.cgi?id=1441934Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 25 4月, 2017 1 次提交
-
-
由 ZhiPeng Lu 提交于
it should be a comparison of modes between new and old devices. So the argument of the second virDomainNetGetActualDirectMode should be newdev. Signed-off-by: NZhiPeng Lu <lu.zhipeng@zte.com.cn>
-
- 24 4月, 2017 1 次提交
-
-
由 Yuri Chornoivan 提交于
-
- 21 4月, 2017 2 次提交
-
-
由 Martin Kletzander 提交于
This patch makes use of the virNetDevSetCoalesce() function to make appropriate settings effective for devices that support them. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1414627Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
We are currently parsing only rx/frames/max because that's the only value that makes sense for us. The tun device just added support for this one and the others are only supported by hardware devices which we don't need to worry about as the only way we'd pass those to the domain is using <hostdev/> or <interface type='hostdev'/>. And in those cases the guest can modify the settings itself. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 20 4月, 2017 4 次提交
-
-
由 Peter Krempa 提交于
In the vcpu hotplug code if exit from the monitor failed we would still attempt to save the status XML. When the daemon is terminated the monitor socket is closed. In such case, the written status XML would not contain the monitor path and thus be invalid. Avoid this issue by only saving status XML on success of the monitor command. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1439452
-
由 Peter Krempa 提交于
The function is used only in the hotplug module.
-
由 Pavel Hrdina 提交于
The history of USB controller for ppc64 guest is complex and goes back to libvirt 1.3.1 where the fun started. Prior Libvirt 1.3.1 if no model for USB controller was specified we've simply passed "-usb" on QEMU command line. Since Libvirt 1.3.1 there is a patch (8156493d) that fixes this issue by using "-device pci-ohci,..." but it breaks migration with older Libvirts which was agreed that's acceptable. However this patch didn't reflect this change in the domain XML and the model was still missing. Since Libvirt 2.2.0 there is a patch (f55eaccb) that fixes the issue with not setting the USB model into domain XML which we need to know about to not break the migration and since the default model was *pci-ohci* it was used as default in this patch as well. This patch tries to take all the previous changes into account and also change the default for newly defined domains that don't specify any model for USB controller. The VIR_DOMAIN_DEF_PARSE_ABI_UPDATE is set only if new domain is defined or new device is added into a domain which means that in all other cases we will use the old *pci-ohci* model instead of the better and not broken *nec-usb-xhci* model. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1373184Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
So far there is probably no change that is allowed to be done by the VIR_DOMAIN_DEF_PARSE_ABI_UPDATE flag that would break guest ABI but this may change in the future. This introduces new VIR_DOMAIN_DEF_PARSE_ABI_UPDATE_MIGRATION which should be used only for ABI updates that are "safe" for persistent migration. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
- 19 4月, 2017 8 次提交
-
-
由 Jiri Denemark 提交于
With QEMU older than 2.9.0 libvirt uses CPUID instruction to determine what CPU features are supported on the host. This was later used when checking compatibility of guest CPUs. Since QEMU 2.9.0 we ask QEMU for the host CPU data. But the two methods we use usually provide disjoint sets of CPU features because QEMU/KVM does not support all features provided by the host CPU and on the other hand it can enable some feature even if the host CPU does not support them. So if there is a domain which requires a CPU features disabled by QEMU/KVM, libvirt will refuse to start it with QEMU > 2.9.0 as its guest CPU is incompatible with the host CPU data we got from QEMU. But such domain would happily start on older QEMU (of course, the features would be missing the guest CPU). To fix this regression, we need to combine both CPU feature sets when checking guest CPU compatibility. https://bugzilla.redhat.com/show_bug.cgi?id=1439933Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
We already know from QEMU which CPU features will block migration. Let's use this information to make a migratable copy of the host CPU model and use it for updating guest CPU specification. This will allow us to drop feature filtering from virCPUUpdate where it was just a hack. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Soon we will need to store multiple host CPU definitions in virQEMUCapsHostCPUData and qemuCaps users will want to request the one they need. This patch introduces virQEMUCapsHostCPUType enum which will be used for specifying the requested CPU definition. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
We need to store several CPU related data structure for both KVM and TCG. So instead of keeping two different copies of everything let's make a virQEMUCapsHostCPUData struct and use it twice. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
To keep freeing of host CPU data in one place. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
This introduces virQEMUCapsHostCPUDataCopy which will later be refactored a bit and called twice from virQEMUCapsNewCopy. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
A simple helper as a complement to virQEMUCapsGetHostModel. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Daniel P. Berrange 提交于
CLang's optimizer is more aggressive at inlining functions than gcc and so will often inline functions that our tests want to mock-override. This causes the test to fail in bizarre ways. We don't want to disable inlining completely, but we must at least prevent inlining of mocked functions. Fortunately there is a 'noinline' attribute that lets us control this per function. A syntax check rule is added that parses tests/*mock.c to extract the list of functions that are mocked (restricted to names starting with 'vir' prefix). It then checks that src/*.h header file to ensure it has a 'ATTRIBUTE_NOINLINE' annotation. This should prevent use from bit-rotting in future. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 18 4月, 2017 4 次提交
-
-
由 Pavel Hrdina 提交于
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1441964Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Introduce new wrapper functions without *Machine* in the function name that take the whole virDomainDef structure as argument and call the existing functions with *Machine* in the function name. Change the arguments of existing functions to *machine* and *arch* because they don't need the whole virDomainDef structure and they could be used in places where we don't have virDomainDef. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Peter Krempa 提交于
Since the disks are copied by qemu, there's no need to enforce cache=none. Thankfully the code that added qemuMigrateDisk did not break existing configs, since if you don't select any disk to migrate explicitly the code behaves sanely. The logic for determining whether a disk should be migrated is open-coded since using qemuMigrateDisk twice would be semantically incorrect.
-
- 13 4月, 2017 5 次提交
-
-
由 Ján Tomko 提交于
Introduce a separate buffer for options and use a helper variable for def->iommu.
-
由 Ján Tomko 提交于
Do not probe for devices that QEMU does not know when probing for device options.
-
由 Peter Krempa 提交于
If you specify disks to migrate it would be possible to select an empty drive for migration. Reject such config.
-
由 Peter Krempa 提交于
Use the proper check whether a disk is empty.
-
由 Peter Krempa 提交于
The code that validates whether an internal snapshot is possible would reject an empty but not-readonly drive. Since floppies can have this property, add a check for emptiness.
-
- 12 4月, 2017 3 次提交
-
-
由 Peter Krempa 提交于
==20406== 8 bytes in 1 blocks are definitely lost in loss record 24 of 1,059 ==20406== at 0x4C2CF55: calloc (vg_replace_malloc.c:711) ==20406== by 0x54BF530: virAllocN (viralloc.c:191) ==20406== by 0x54D37C4: virConfGetValueStringList (virconf.c:1001) ==20406== by 0x144E4E8E: virQEMUDriverConfigLoadFile (qemu_conf.c:835) ==20406== by 0x1452A744: qemuStateInitialize (qemu_driver.c:664) ==20406== by 0x55DB585: virStateInitialize (libvirt.c:770) ==20406== by 0x124570: daemonRunStateInit (libvirtd.c:881) ==20406== by 0x5532990: virThreadHelper (virthread.c:206) ==20406== by 0x8C82493: start_thread (in /lib64/libpthread-2.24.so) ==20406== by 0x8F7FA1E: clone (in /lib64/libc-2.24.so)
-
由 Peter Krempa 提交于
==20406== 4 bytes in 1 blocks are definitely lost in loss record 6 of 1,059 ==20406== at 0x4C2AF3F: malloc (vg_replace_malloc.c:299) ==20406== by 0x8F17D39: strdup (in /lib64/libc-2.24.so) ==20406== by 0x552C0E0: virStrdup (virstring.c:784) ==20406== by 0x54D3622: virConfGetValueString (virconf.c:945) ==20406== by 0x144E4692: virQEMUDriverConfigLoadFile (qemu_conf.c:687) ==20406== by 0x1452A744: qemuStateInitialize (qemu_driver.c:664) ==20406== by 0x55DB585: virStateInitialize (libvirt.c:770) ==20406== by 0x124570: daemonRunStateInit (libvirtd.c:881) ==20406== by 0x5532990: virThreadHelper (virthread.c:206) ==20406== by 0x8C82493: start_thread (in /lib64/libpthread-2.24.so) ==20406== by 0x8F7FA1E: clone (in /lib64/libc-2.24.so)
-
由 Erik Skultety 提交于
Commit a4a39d90 added a check that checks for VFIO support with mediated devices. The problem is that the hostdev preparing functions behave like a fallthrough if device of that specific type doesn't exist. However, the check for VFIO support was independent of the existence of a mdev device which caused the guest to fail to start with any device to be directly assigned if VFIO was disabled/unavailable in the kernel. The proposed change first ensures that it makes sense to check for VFIO support in the first place, and only then performs the VFIO support check itself. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1441291Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
- 11 4月, 2017 1 次提交
-
-
由 Pavel Hrdina 提交于
This removes the hacky extern global variable and modifies the test code to properly create QEMU capabilities cache for QEMU binaries used in our tests. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
- 10 4月, 2017 4 次提交
-
-
由 Marc Hartmayer 提交于
This attribute is not needed here, since @mon is in use. Signed-off-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com> Reviewed-by: NBjoern Walk <bwalk@linux.vnet.ibm.com>
-
由 Marc Hartmayer 提交于
Implement qemuMonitorRegister() as there is already a qemuMonitorUnregister() function. This way it may be easier to understand the code paths. Signed-off-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com> Reviewed-by: NBjoern Walk <bwalk@linux.vnet.ibm.com>
-
由 Marc Hartmayer 提交于
This way qemuDomainLogContextRef() and qemuDomainLogContextFree() is no longer needed. The naming qemuDomainLogContextFree() was also somewhat misleading. Additionally, it's easier to turn qemuDomainLogContext in a self-locking object. Signed-off-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com> Reviewed-by: NBjoern Walk <bwalk@linux.vnet.ibm.com>
-
由 Marc Hartmayer 提交于
There were multiple race conditions that could lead to segmentation faults. The first precondition for this is qemuProcessLaunch must fail sometime shortly after starting the new QEMU process. The second precondition for the segmentation faults is that the new QEMU process dies - or to be more precise the QEMU monitor has to be closed irregularly. If both happens during qemuProcessStart (starting a domain) there are race windows between the thread with the event loop (T1) and the thread that is starting the domain (T2). First segmentation fault scenario: If qemuProcessLaunch fails during qemuProcessStart the code branches to the 'stop' path where 'qemuMonitorSetDomainLog(priv->mon, NULL, NULL, NULL)' will set the log function of the monitor to NULL (done in T2). In the meantime the event loop of T1 will wake up with an EOF event for the QEMU monitor because the QEMU process has died. The crash occurs if T1 has checked 'mon->logFunc != NULL' in qemuMonitorIO just before the logFunc was set to NULL by T2. If this situation occurs T1 will try to call mon->logFunc which leads to the segmentation fault. Solution: Require the monitor lock for setting the log function. Backtrace: 0 0x0000000000000000 in ?? () 1 0x000003ffe9e45316 in qemuMonitorIO (watch=<optimized out>, fd=<optimized out>, events=<optimized out>, opaque=0x3ffe08aa860) at ../../src/qemu/qemu_monitor.c:727 2 0x000003fffda2e1a4 in virEventPollDispatchHandles (nfds=<optimized out>, fds=0x2aa000fd980) at ../../src/util/vireventpoll.c:508 3 0x000003fffda2e398 in virEventPollRunOnce () at ../../src/util/vireventpoll.c:657 4 0x000003fffda2ca10 in virEventRunDefaultImpl () at ../../src/util/virevent.c:314 5 0x000003fffdba9366 in virNetDaemonRun (dmn=0x2aa000cc550) at ../../src/rpc/virnetdaemon.c:818 6 0x000002aa00024668 in main (argc=<optimized out>, argv=<optimized out>) at ../../daemon/libvirtd.c:1541 Second segmentation fault scenario: If qemuProcessLaunch fails it will unref the log context and with invoking qemuMonitorSetDomainLog(priv->mon, NULL, NULL, NULL) qemuDomainLogContextFree() will be invoked. qemuDomainLogContextFree() invokes virNetClientClose() to close the client and cleans everything up (including unref of _virLogManager.client) when virNetClientClose() returns. When T1 is now trying to report 'qemu unexpectedly closed the monitor' libvirtd will crash because the client has already been freed. Solution: As the critical section in qemuMonitorIO is protected with the monitor lock we can use the same solution as proposed for the first segmentation fault. Backtrace: 0 virClassIsDerivedFrom (klass=0x3100979797979797, parent=0x2aa000d92f0) at ../../src/util/virobject.c:169 1 0x000003fffda659e6 in virObjectIsClass (anyobj=<optimized out>, klass=<optimized out>) at ../../src/util/virobject.c:365 2 0x000003fffda65a24 in virObjectLock (anyobj=0x3ffe08c1db0) at ../../src/util/virobject.c:317 3 0x000003fffdba4688 in virNetClientIOEventLoop (client=client@entry=0x3ffe08c1db0, thiscall=thiscall@entry=0x2aa000fbfa0) at ../../src/rpc/virnetclient.c:1668 4 0x000003fffdba4b4c in virNetClientIO (client=client@entry=0x3ffe08c1db0, thiscall=0x2aa000fbfa0) at ../../src/rpc/virnetclient.c:1944 5 0x000003fffdba4d42 in virNetClientSendInternal (client=client@entry=0x3ffe08c1db0, msg=msg@entry=0x2aa000cc710, expectReply=expectReply@entry=true, nonBlock=nonBlock@entry=false) at ../../src/rpc/virnetclient.c:2116 6 0x000003fffdba6268 in virNetClientSendWithReply (client=0x3ffe08c1db0, msg=0x2aa000cc710) at ../../src/rpc/virnetclient.c:2144 7 0x000003fffdba6e8e in virNetClientProgramCall (prog=0x3ffe08c1120, client=<optimized out>, serial=<optimized out>, proc=<optimized out>, noutfds=<optimized out>, outfds=0x0, ninfds=0x0, infds=0x0, args_filter=0x3fffdb64440 <xdr_virLogManagerProtocolDomainReadLogFileArgs>, args=0x3ffffffe010, ret_filter=0x3fffdb644c0 <xdr_virLogManagerProtocolDomainReadLogFileRet>, ret=0x3ffffffe008) at ../../src/rpc/virnetclientprogram.c:329 8 0x000003fffdb64042 in virLogManagerDomainReadLogFile (mgr=<optimized out>, path=<optimized out>, inode=<optimized out>, offset=<optimized out>, maxlen=<optimized out>, flags=0) at ../../src/logging/log_manager.c:272 9 0x000003ffe9e0315c in qemuDomainLogContextRead (ctxt=0x3ffe08c2980, msg=0x3ffffffe1c0) at ../../src/qemu/qemu_domain.c:4422 10 0x000003ffe9e280a8 in qemuProcessReadLog (logCtxt=<optimized out>, msg=msg@entry=0x3ffffffe288) at ../../src/qemu/qemu_process.c:1800 11 0x000003ffe9e28206 in qemuProcessReportLogError (logCtxt=<optimized out>, msgprefix=0x3ffe9ec276a "qemu unexpectedly closed the monitor") at ../../src/qemu/qemu_process.c:1836 12 0x000003ffe9e28306 in qemuProcessMonitorReportLogError (mon=mon@entry=0x3ffe085cf10, msg=<optimized out>, opaque=<optimized out>) at ../../src/qemu/qemu_process.c:1856 13 0x000003ffe9e452b6 in qemuMonitorIO (watch=<optimized out>, fd=<optimized out>, events=<optimized out>, opaque=0x3ffe085cf10) at ../../src/qemu/qemu_monitor.c:726 14 0x000003fffda2e1a4 in virEventPollDispatchHandles (nfds=<optimized out>, fds=0x2aa000fd980) at ../../src/util/vireventpoll.c:508 15 0x000003fffda2e398 in virEventPollRunOnce () at ../../src/util/vireventpoll.c:657 16 0x000003fffda2ca10 in virEventRunDefaultImpl () at ../../src/util/virevent.c:314 17 0x000003fffdba9366 in virNetDaemonRun (dmn=0x2aa000cc550) at ../../src/rpc/virnetdaemon.c:818 18 0x000002aa00024668 in main (argc=<optimized out>, argv=<optimized out>) at ../../daemon/libvirtd.c:1541 Other code parts where the same problem was possible to occur are fixed as well (qemuMigrationFinish, qemuProcessStart, and qemuDomainSaveImageStartVM). Signed-off-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com> Reported-by: NSascha Silbe <silbe@linux.vnet.ibm.com>
-
- 07 4月, 2017 3 次提交
-
-
由 Pavel Hrdina 提交于
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Jiri Denemark 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1439130Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
So far only QEMU_MONITOR_MIGRATION_CAPS_POSTCOPY was reset, but only in a single code path leaving post-copy enabled in quite a few cases. https://bugzilla.redhat.com/show_bug.cgi?id=1425003Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-