- 12 10月, 2016 11 次提交
-
-
由 Pavel Hrdina 提交于
Runtime validation that depend on qemu capabilities should be moved into qemuProcessStartValidateXML. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
All definition validation that doesn't depend on qemu capabilities and was allowed previously as valid definition should be placed into qemuDomainDefValidate. The check whether video type is supported or not was based on an enum that translates type into model. Use switch to ensure that if new video type is added, it will be properly handled. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
We generally uses QEMU_CAPS_DEVICE_$NAME to probe for existence of some device and QEMU_CAPS_$NAME_$PROP to probe for existence of some property of that device. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
If QEMU in question supports QMP, this capability is set if QEMU_CAPS_DEVICE_QXL was set based on existence of "-device qxl". If libvirt needs to parse *help*, because there is no QMP support, it checks for existence of "-vga qxl", but it also parses output of "-device ?" and sets QEMU_CAPS_DEVICE_QXL too. Now that libvirt supports only QEMU that has "-device" implemented it's safe to drop this capability and stop using it. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
This patch simplifies QEMU capabilities for QXL video device. QEMU exposes this device as *qxl-vga* and *qxl* and they are both the same device with the same set of parameters, the only difference is that *qxl-vga* includes VGA compatibility. Based on QEMU code they are tied together so it's safe to check only for presence of only one of them. This patch also removes an invalid test case "video-qxl-sec-nodevice" where there is only *qxl-vga* device and *qxl* device is not present. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Qemu supports *xen* video device only with XEN and this code was part of xenner code. We dropped support for xenner in commit de9be0ab. Before this patch if you used 'xen' video type you ended up with domain without any video device at all. Now we don't allow to start such domain. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Martin Kletzander 提交于
It was never safe anyway and as such shouldn't have been enabled in the first place. Future patches will allow hot-(un)pluging of some ivshmem devices as a workaround. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
This way we get reference counting and we can get rid of locking function. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Corey S. McQuay 提交于
Currently Libvirt allows attempts to migrate read only disks. Qemu cannot handle this as read only disks cannot be written to on the destination system. The end result is a cryptic error message and a failed migration. This patch causes migration to fail earlier and provides a meaningful error message stating that migrating read only disks is not supported. Signed-off-by: NCorey S. McQuay <csmcquay@linux.vnet.ibm.com> Reviewed-by: NJason J. Herne <jjherne@linux.vnet.ibm.com> Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
-
- 11 10月, 2016 1 次提交
-
-
由 Peter Krempa 提交于
Rather than multiplying sockets, cores, and threads use the new helper for getting the vcpu count resulting from the topology.
-
- 07 10月, 2016 1 次提交
-
-
由 Daniel P. Berrange 提交于
The intel-iommu device has existed since QEMU 2.2.0, but it was only possible to create it with -device since QEMU 2.7.0, thanks to: commit 621d983a1f9051f4cfc3f402569b46b77d8449fc Author: Marcel Apfelbaum <marcel@redhat.com> Date: Mon Jun 27 18:38:34 2016 +0300 hw/iommu: enable iommu with -device Use the standard '-device intel-iommu' to create the IOMMU device. The legacy '-machine,iommu=on' can still be used. The libvirt capability check & command line formatting code is thus broken for all QEMU versions 2.2.0 -> 2.6.0 inclusive. This fixes it to use iommu=on instead. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 06 10月, 2016 4 次提交
-
-
由 Peter Krempa 提交于
Since introduction of chardev hotplug the code was wrong for the UDP case and basically created a TCP socket instead. Use proper objects and type for UDP. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1377602
-
由 Peter Krempa 提交于
-
由 John Ferlan 提交于
We're about to add more options, let's avoid having multiple if-then-else which each try to set up the qemuMonitorJSONMakeCommand call with all the parameters it knows about. Instead, use the fact that when a NULL is found in the argument list that processing of the remaining arguments stops and just have call. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
We're about to add 6 new options and it appears (from testing) one cannot utilize both the shorthand (alias) and (much) longer names for the arguments. So modify the command builder to use the longer name and of course alter the test output .args to have the similarly innocuous long name. Also utilize a macro to build that name makes it so much more visually appealing and saves a few characters or potential cut-n-paste issues. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 05 10月, 2016 7 次提交
-
-
由 John Ferlan 提交于
This will fetch "this device" from the recently returned 'dev' and perform common error checking for the paths that call it.
-
由 John Ferlan 提交于
This will grab the 'dev' from devices and do the common validation checks.
-
由 John Ferlan 提交于
Reduce some cut-n-paste code by creating common helper. Make use of the recently added virJSONValueObjectStealArray to grab the devices list as part of the common code (we we can Free the reply) and return devices for each of the callers to continue to parse. NB: This also adds error checking to qemuMonitorJSONDiskNameLookup Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Peter Krempa 提交于
Implement support for VIR_DOMAIN_VCPU_HOTPLUGGABLE so that users can choose to make vcpus added by the API removable.
-
由 Peter Krempa 提交于
If attaching to a qemu process fails after opening the monitor socket libvirt does not clean up the monitor. As the monitor also holds a reference to the domain object the qemu attach API basically leaks it. QEMU also does not interact on a second monitor connection and thus a further attempt to attach to it would lock up. Prevent libvirt from leaking the monitor by explicitly closing it. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1378401
-
由 Peter Krempa 提交于
Attaching to a existing qemu process allows to get us into a situation when qemu is new enough to have JSON monitor and new vCPU hotplug but the json monitor is not used. The vCPU detection code would require it though. This broke attaching to qemu processes. Make the condition less strict and just skip the vCPU hotplug detection if JSON monitor is not available. Resolves one of the symptoms in: https://bugzilla.redhat.com/show_bug.cgi?id=1378401
-
由 Michal Privoznik 提交于
This breaks vCPU hotplug, because when starting a domain, we create a copy of domain definition (which becomes live XML) and during the post parse callbacks we might adjust some tunings so that vCPU hotplug is possible. This reverts commit 581b7756.
-
- 30 9月, 2016 5 次提交
-
-
由 Peter Krempa 提交于
Certain operations may make the vcpu order information invalid. Since the order is primarily used to ensure migration compatibility and has basically no other user benefits, clear the order prior to certain operations and document that it may be cleared. All the operations that would clear the order can still be properly executed by defining a new domain configuration rather than using the helper APIs. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1370357
-
由 Peter Krempa 提交于
virDomainDefSetVcpus was not designed to handle coldplug of vcpus now that we can set state of vcpus individually. Introduce qemuDomainSetVcpusConfig that properly handles state changes of vcpus when coldplugging so that invalid configurations are not created. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1375939
-
由 Peter Krempa 提交于
The current code that validates duplicate vcpu order would not work properly if the order would exceed def->maxvcpus. Limit the order to the interval described.
-
由 Peter Krempa 提交于
Allocate a one larger bitmap rather than shifting the indexes back to zero.
-
由 Peter Krempa 提交于
The bitmap indexes for the order duplicate check are shifted to 0 since vcpu order 0 is not allowed. The error message doesn't need such treating though. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1370360
-
- 29 9月, 2016 1 次提交
-
-
由 Martin Kletzander 提交于
If this reminds you of a commit message from around a year ago, it's 41c2aa72 and yes, we're dealing with "the same thing" again. Or f309db1f and it's similar. There is a logic in place that if there is no real need for memory-backend-file, qemuBuildMemoryBackendStr() returns 0. However that wasn't the case with hugepage backing. The reason for that was that we abused the 'pagesize' variable for storing that information, but we should rather have a separate one that specifies whether we really need the new object for hugepage backing. And that variable should be set only if this particular NUMA cell needs special treatment WRT hugepages. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1372153Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 28 9月, 2016 2 次提交
-
-
由 Joao Martins 提交于
So far only guestfwd and virtio were supported. Add an additional for Xen as libxl channels create a Xen console visible to the guest. Signed-off-by: NJoao Martins <joao.m.martins@oracle.com> Signed-off-by: NJim Fehlig <jfehlig@suse.com>
-
由 Jiri Denemark 提交于
The qemucapsprobe helper calls virQEMUCapsNewForBinaryInternal with caps == NULL, causing the following crash: Program received signal SIGSEGV, Segmentation fault. #0 0x00007ffff788775f in virQEMUCapsInitHostCPUModel (qemuCaps=qemuCaps@entry=0x649680, host=host@entry=0x10) at src/qemu/qemu_capabilities.c:2969 #1 0x00007ffff7889dbf in virQEMUCapsNewForBinaryInternal (caps=caps@entry=0x0, binary=<optimized out>, libDir=libDir@entry=0x4033f6 "/tmp", cacheDir=cacheDir@entry=0x0, runUid=runUid@entry=4294967295, runGid=runGid@entry=4294967295, qmpOnly=true) at src/qemu/qemu_capabilities.c:4039 #2 0x0000000000401702 in main (argc=2, argv=0x7fffffffd968) at tests/qemucapsprobe.c:73 Caused by v2.2.0-182-g68c70118. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 27 9月, 2016 2 次提交
-
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1368417 So far, when it comes to 'virsh update-device --config' of disks we are limiting ourselves for just the disk source update and just for CDROMs and floppies. This makes no sense. Especially if you look around and see that we already allow full update to graphics and net devices. So let's just take whatever XML user wants to have there and replace our internal definition with it. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Daniel P. Berrange 提交于
enum types are unsigned and the qemuGetCompressionProgram function can return -1 on error. It is therefore inappropriate to return an enum type. This fixes a build error where the internal 'ret' variable was used in a comparison with -1 ../../src/qemu/qemu_driver.c: In function 'qemuGetCompressionProgram': ../../src/qemu/qemu_driver.c:3280:5: error: comparison of unsigned expression < 0 is always false [-Werror=type-limits] ../../src/qemu/qemu_driver.c:3289:5: error: comparison of unsigned expression < 0 is always false [-Werror=type-limits] cc1: all warnings being treated as errors Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 26 9月, 2016 6 次提交
-
-
由 Michal Privoznik 提交于
When creating a copy of virDomainDef we save ourselves the trouble of writing deep-copy functions and just format and parse back domain/device XML. However, the XML we are parsing was already fully formatted - there is no reason to run post parse callbacks (which fill in blanks - there are none!). Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Just like we did two commits ago, don't try to fetch capabilities for non-existing binary. Re-use the ones we have for running domain. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Just like we did two commits ago, don't try to fetch capabilities for non-existing binary. Re-use the ones we have for running domain. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
We can't rely on def->emulator path. It may be provided by user as we give them opportunity to provide their own XML for migration. Therefore the path may point to just whatever binary (or even to a non-existent file). Moreover, this path is meant for destination, but the capabilities lookup is done on source. What we can do is to assume same capabilities for post parse callbacks as the running domain has. They will be used just to add some default models/controllers/devices/... anyway. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Just like virDomainDefPostParseCallback has gained new parseOpaque argument, we need to follow the logic with virDomainDeviceDefPostParse. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-