- 10 1月, 2013 1 次提交
-
-
由 Guannan Ren 提交于
QEMU_CAPS_DEVICE_USB_SERIAL /* -device usb-serial */
-
- 08 1月, 2013 2 次提交
-
-
由 J.B. Joret 提交于
This is the QEMU backend code for the SCLP console support. It includes SCLP capability detection, QEMU command line generation and a test case. Signed-off-by: NJ.B. Joret <jb@linux.vnet.ibm.com> Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
-
由 Daniel P. Berrange 提交于
Since we daemonized QEMU for capabilities probing there is a long time if QEMU fails to launch. This is because we're not passing in any virDomainObjPtr instance and thus the monitor code can not check to see if the PID is still alive. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 04 1月, 2013 1 次提交
-
-
由 Michal Privoznik 提交于
Since 4c993d8a we failed to set this important capability, which allows starting a domain with QXL video card. We set DEVICE_QXL capability bit instead, which is not necessary wrong. Anyway, if qemu supports the new '-device qxl' it supports older '-vga qxl' as well. The latter is used for the primary (the first) qxl video card, the former for other video cards.
-
- 03 1月, 2013 1 次提交
-
-
由 Michal Privoznik 提交于
Despite our great effort we still parsed qemu log output. We wouldn't notice unless upcoming qemu 1.4 changed the format of the logs slightly. Anyway, now we should gather all interesting knobs like pty paths from monitor. Moreover, since for historical reasons the first console can be just an alias to the first serial port, we need to check this and copy the pty path if that's the case to the first console.
-
- 22 12月, 2012 1 次提交
-
-
由 Viktor Mihajlovski 提交于
Since we switched to QMP probing, the object types are spelled out explicitly, i.e. virtio-net-pci. This has effectively disabled the capability detection of s390 virtio devices. The trivial fix is to add the s390 virtio types explicitly to qemuCapsObjectProps. Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
-
- 21 12月, 2012 7 次提交
-
-
由 Daniel P. Berrange 提交于
-
由 Daniel P. Berrange 提交于
-
由 Daniel P. Berrange 提交于
-
由 Daniel P. Berrange 提交于
-
由 Daniel P. Berrange 提交于
-
由 Daniel P. Berrange 提交于
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Li Zhang 提交于
ACPI is only supported on x86 platform, PPC can't support it. So QEMU_CAPS_NO_ACPI shouldn't be set. This patch is to remove QEMU_CAPS_NO_ACPI capability for non-x86 platform. Signed-off-by: NLi Zhang <zhlcindy@linux.vnet.ibm.com>
-
- 19 12月, 2012 4 次提交
-
-
由 Daniel P. Berrange 提交于
Historically there was an inconsistency in handling of the itanium arch. The xen driver & CPU model code treated it as 'ia64' but the QEMU capabilities code used 'itanium'. On the grounds that no one has ever seriously used itanium with QEMU, while RHEL shipped itanium with Xen, we should favour 'ia64' as the canonical format
-
由 Daniel P. Berrange 提交于
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Convert the host capabilities and domain config structs to use the virArch datatype. Update the parsers and all drivers to take account of datatype change Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 17 12月, 2012 1 次提交
-
-
由 Guannan Ren 提交于
QEMU_CAPS_DEVICE_QXL -device qxl QEMU_CAPS_DEVICE_VGA -device VGA QEMU_CAPS_DEVICE_CIRRUS_VGA -device cirrus-vga QEMU_CAPS_DEVICE_VMWARE_SVGA -device vmware-svga QEMU_CAPS_DEVICE_VIDEO_PRIMARY /* safe to use -device XXX for primary video device */ Fix a typo in qemuCapsObjectTypes, the string 'qxl' here should be -device qxl rather than -vga [...|qxl|..]
-
- 13 12月, 2012 1 次提交
-
-
由 Daniel P. Berrange 提交于
The qemuCapsInitQMP method never frees the QEMU 'package' version string.
-
- 12 12月, 2012 1 次提交
-
-
由 Ján Tomko 提交于
Currently there is no way to detect it via QMP and requesting "-sandbox off" works correctly even if it was compiled out, so this will work unless someone both requests the sandbox in qemu.conf and builds QEMU without the support for it.
-
- 08 12月, 2012 1 次提交
-
-
由 Cole Robinson 提交于
Things are supposed to look like: <machine canonical='pc-0.12'>pc</machine> But are currently swapped. This can cause many VMs to revert to having machine type='pc' which will affect save/restore across qemu upgrades.
-
- 05 12月, 2012 1 次提交
-
-
由 Eric Blake 提交于
Without this patch, attempts to create a disk snapshot when qemu is too old results in a cryptic message: virsh # snapshot-create 23 --disk-only error: operation failed: Failed to take snapshot: unknown command: 'snapshot_blkdev' Now it reports: virsh # snapshot-create 23 --disk-only error: unsupported configuration: live disk snapshot not supported with this QEMU binary All versions of qemu that support live disk snapshot also support QMP (basically upstream qemu 1.1 and later, and backports to RHEL 6.2). * src/qemu/qemu_capabilities.h (QEMU_CAPS_DISK_SNAPSHOT): New capability. * src/qemu/qemu_capabilities.c (qemuCaps): Track it. (qemuCapsProbeQMPCommands): Set it. * src/qemu/qemu_driver.c (qemuDomainSnapshotCreateDiskActive): Use it. * src/qemu/qemu_monitor.c (qemuMonitorDiskSnapshot): Simplify. * src/qemu/qemu_monitor_json.c (qemuMonitorJSONDiskSnapshot): Likewise. * src/qemu/qemu_monitor_text.h (qemuMonitorTextDiskSnapshot): Delete. * src/qemu/qemu_monitor_text.c (qemuMonitorTextDiskSnapshot): Likewise.
-
- 01 12月, 2012 1 次提交
-
-
由 Viktor Mihajlovski 提交于
The default machine type must be stored in the first element of the caps->machineTypes array. This was done for help output parsing but not for QMP probing. Added a helper function qemuSetDefaultMachine to apply the same fix up for both probing methods. Further, it was necessary to set caps->nmachineTypes after QMP probing. Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
-
- 29 11月, 2012 1 次提交
-
-
由 Guido Günther 提交于
As of 1a50ba2c we fail to connect to the monitor instead of getting an exit status != 0 from qemu itself. This breaks capabilities probing for the non QMP case.
-
- 28 11月, 2012 2 次提交
-
-
由 Viktor Mihajlovski 提交于
With QMP capability probing, the version was not set. virsh version returns: ... Cannot extract running QEMU hypervisor version This is fixed by computing caps->version from QMP major, minor, micro values. Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
-
由 Viktor Mihajlovski 提交于
QMP Capability probing will fail if QEMU cannot bind to the QMP monitor socket in the qemu_driver->libDir directory. That's because the child process is stripped of all capabilities and this directory is chown'ed to the configured QEMU user/group (normally qemu:qemu) by the QEMU driver. To prevent this from happening, the driver startup will now pass the QEMU uid and gid down to the capability probing code. All capability probing invocations of QEMU will be run with the configured QEMU uid instead of libvirtd's. Furter, the pid file handling is moved to libvirt, as QEMU cannot write to the qemu_driver->runDir (root:root). This also means that the libvirt daemonizing must be used. Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
-
- 15 11月, 2012 1 次提交
-
-
由 Ján Tomko 提交于
Allow bootindex to be specified for redirected USB devices and host USB devices. Bug: https://bugzilla.redhat.com/show_bug.cgi?id=805414
-
- 10 11月, 2012 1 次提交
-
-
由 Viktor Mihajlovski 提交于
For S390, the default console target type cannot be of type 'serial'. It is necessary to at least interpret the 'arch' attribute value of the os/type element to produce the correct default type. Therefore we need to extend the signature of defaultConsoleTargetType to account for architecture. As a consequence all the drivers supporting this capability function must be updated. Despite the amount of changed files, the only change in behavior is that for S390 the default console target type will be 'virtio'. N.B.: A more future-proof approach could be to to use hypervisor specific capabilities to determine the best possible console type. For instance one could add an opaque private data pointer to the virCaps structure (in case of QEMU to hold capsCache) which could then be passed to the defaultConsoleTargetType callback to determine the console target type. Seems to be however a bit overengineered for the use case... Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
-
- 02 11月, 2012 3 次提交
-
-
由 Daniel P. Berrange 提交于
The libvirt coding standard is to use 'function(...args...)' instead of 'function (...args...)'. A non-trivial number of places did not follow this rule and are fixed in this patch. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Guannan Ren 提交于
BZ:https://bugzilla.redhat.com/show_bug.cgi?id=871273 when using virsh qemu-attach to attach an existing qemu process, if it misses the -M option in qemu command line, libvirtd crashed because the NULL value of def->os.machine in later use. Example: /usr/libexec/qemu-kvm -name foo \ -cdrom /var/lib/libvirt/images/boot.img \ -monitor unix:/tmp/demo,server,nowait \ error: End of file while reading data: Input/output error error: Failed to reconnect to the hypervisor This patch tries to set default machine type if the value of def->os.machine is still NULL after qemu command line parsing.
-
由 Doug Goldstein 提交于
Per the code comment in qemuCapsInitQMPBasic() and commit 43e23c73, we should only use QMP for capabilities probing starting with 1.2 and newer. The old code had dead logic that probed on 1.0 and newer. Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 01 11月, 2012 1 次提交
-
-
由 Daniel P. Berrange 提交于
QEMU uses 'i386' for its 32-bit x86 architecture, but libvirt wants that to be 'i686', so we must fix it up Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 31 10月, 2012 1 次提交
-
-
由 Martin Kletzander 提交于
When there is no 'qemu-kvm' binary and the emulator used for a machine is, for example, 'qemu-system-x86_64' that, by default, runs without kvm enabled, libvirt still supplies '-no-kvm' option to this process, even though it does not recognize such option (making the start of a domain fail in that case). This patch fixes building a command-line for QEMU machines without KVM acceleration and is based on following assumptions: - QEMU_CAPS_KVM flag means that QEMU is running KVM accelerated machines by default (without explicitly requesting that using a command-line option). It is the closest to the truth according to the code with the only exception being the comment next to the flag, so it's fixed in this patch as well. - QEMU_CAPS_ENABLE_KVM flag means that QEMU is, by default, running without KVM acceleration and in case we need KVM acceleration it needs to be explicitly instructed to do so. This is partially true for the past (this option essentially means that QEMU recognizes the '-enable-kvm' option, even though it's almost the same).
-
- 27 10月, 2012 1 次提交
-
-
由 Eric Blake 提交于
Upstream qemu 1.3 is adding two new monitor commands, 'drive-mirror' and 'block-job-complete'[1], which can drive live block copy and storage migration. [Additionally, RHEL 6.3 had backported an earlier version of most of the same functionality, but under the names '__com.redhat_drive-mirror' and '__com.redhat_drive-reopen' and with slightly different JSON arguments, and has been using patches similar to these upstream patches for several months now.] The libvirt API virDomainBlockRebase as already committed for 0.9.12 is flexible enough to expose the basics of block copy, but some additional features in the 'drive-mirror' qemu command, such as setting error policy, setting granularity, or using a persistent bitmap, may later require a new libvirt API virDomainBlockCopy. I will wait to add that API until we know more about what qemu 1.3 will finally provide. This patch caters only to the upstream qemu 1.3 interface, although I have proven that the changes for RHEL 6.3 can be isolated to just qemu_monitor_json.c, and the rest of this series will gracefully handle either interface once the JSON differences are papered over in a downstream patch. For consistency with other block job commands, libvirt must handle the bandwidth argument as MiB/sec from the user, even though qemu exposes the speed argument as bytes/sec; then again, qemu rounds up to cluster size internally, so using MiB hides the worst effects of that rounding if you pass small numbers. [1]https://lists.gnu.org/archive/html/qemu-devel/2012-10/msg04123.html * src/qemu/qemu_capabilities.h (QEMU_CAPS_DRIVE_MIRROR) (QEMU_CAPS_DRIVE_REOPEN): New bits. * src/qemu/qemu_capabilities.c (qemuCaps): Name them. * src/qemu/qemu_monitor_json.c (qemuMonitorJSONCheckCommands): Set them. (qemuMonitorJSONDriveMirror, qemuMonitorDrivePivot): New functions. * src/qemu/qemu_monitor_json.h (qemuMonitorJSONDriveMirror) (qemuMonitorDrivePivot): Declare them. * src/qemu/qemu_monitor.c (qemuMonitorDriveMirror) (qemuMonitorDrivePivot): New passthroughs. * src/qemu/qemu_monitor.h (qemuMonitorDriveMirror) (qemuMonitorDrivePivot): Declare them.
-
- 23 10月, 2012 1 次提交
-
-
由 Cole Robinson 提交于
Since the option doesn't exist. Fixes booting with cpu mode='host-model' and qemu 1.2.0
-
- 22 10月, 2012 2 次提交
-
-
由 Doug Goldstein 提交于
Currently it's assumed that qemu always supports VNC, however it is definitely possible to compile qemu without VNC support so we should at the very least check for it and handle that correctly.
-
由 Michal Privoznik 提交于
As we switched to setting capabilities based on QMP communication, qemu seamless-migration capability was not set. In the -help output this knob is called seamless-migration=[on|off]. The equivalent in QMP world is SPICE_MIGRATE_COMPLETED event (qemu upstream commit 2fdd16e2).
-
- 20 10月, 2012 1 次提交
-
-
由 Eric Blake 提交于
qemu 1.3 will be adding a 'block-commit' monitor command, per qemu.git commit ed61fc1. It matches nicely to the libvirt API virDomainBlockCommit. * src/qemu/qemu_capabilities.h (QEMU_CAPS_BLOCK_COMMIT): New bit. * src/qemu/qemu_capabilities.c (qemuCapsProbeQMPCommands): Set it. * src/qemu/qemu_monitor.h (qemuMonitorBlockCommit): New prototype. * src/qemu/qemu_monitor_json.h (qemuMonitorJSONBlockCommit): Likewise. * src/qemu/qemu_monitor.c (qemuMonitorBlockCommit): Implement it. * src/qemu/qemu_monitor_json.c (qemuMonitorJSONBlockCommit): Likewise. (qemuMonitorJSONHandleBlockJobImpl) (qemuMonitorJSONGetBlockJobInfoOne): Handle new event type.
-
- 19 10月, 2012 1 次提交
-
-
由 Guido Günther 提交于
If we can't probe the architecture from QMP we parse the architecture from the qemu binaries name. This results in the architecture being i386 instead of i686 which then results in QEMU_CAPS_PCI_MULTIBUS being unset which gives a broken qemu command line. This probably didn't show up earlier since most of the time there's also a /usr/bin/qemu around which results in i686 capabilities.
-
- 18 10月, 2012 1 次提交
-
-
由 Jiri Denemark 提交于
When libvirt cannot find a suitable CPU model for host CPU (easily reproducible by running libvirt in a guest), it would not provide CPU topology in capabilities XML either. Even though CPU topology is known and can be queried by virNodeGetInfo. With this patch, CPU topology will always be provided in capabilities XML regardless on the presence of CPU model.
-