- 22 3月, 2013 4 次提交
-
-
由 Paolo Bonzini 提交于
A better way to do this would be to use a configuration file like [iscsi "target-name"] user = name password = pwd and pass it via -readconfig. This would remove the username and password from the "ps" output. For now, however, keep this solution. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Paolo Bonzini 提交于
Only sheepdog actually required it in the code, and we can use 7000 as the default---the same value that QEMU uses for the simple "sheepdog:VOLUME" syntax. With this change, the schema can be fixed to allow no port. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Paolo Bonzini 提交于
This enables usage of commands like persistent reservations. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Paolo Bonzini 提交于
libiscsi provides a userspace iSCSI initiator. The main advantage over the kernel initiator is that it is very easy to provide different initiator names for VMs on the same host. Thus libiscsi supports usage of persistent reservations in the VM, which otherwise would only be possible with NPIV. libiscsi uses "iscsi" as the scheme, not "iscsi+tcp". We can change this in the tests (while remaining backwards-compatible manner, because QEMU uses TCP as the default transport for both Gluster and NBD). Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
- 21 3月, 2013 4 次提交
-
-
由 Peter Krempa 提交于
When the blockjob fails for some reason an event is emitted but the disk wasn't unmarked as being part of a active block copy operation.
-
由 Michal Privoznik 提交于
The VIR_ERR_NO_SUPPORT error code is reserved for cases where an API is not implemented in a driver. It definitely should not be used when an API execution fails due to unsupported operation.
-
由 Osier Yang 提交于
We should record the new disk src in the shared disk table for updating disk (CD-ROM or Floppy) API. Fortunately, we only allow to update the disk source now, otherwise we might also want to set the unpriv_sgio setting.
-
由 Li Zhang 提交于
Now that VCPU number are removed from qemu_monitor_text.c (commit cc78d7ba), VCPU string checking also should be removed. Report-by: NJohn Ferlan <jferlan@redhat.com> Signed-off-by: NLi Zhang <zhlcindy@linux.vnet.ibm.com>
-
- 20 3月, 2013 3 次提交
-
-
由 Gao feng 提交于
Intend to reduce the redundant code,use virNumaSetupMemoryPolicy to replace virLXCControllerSetupNUMAPolicy and qemuProcessInitNumaMemoryPolicy. This patch also moves the numa related codes to the file virnuma.c and virnuma.h Signed-off-by: NGao feng <gaofeng@cn.fujitsu.com>
-
由 Gao feng 提交于
qemuGetNumadAdvice will be used by LXC driver, rename it to virNumaGetAutoPlacementAdvice and move it to virnuma.c Signed-off-by: NGao feng <gaofeng@cn.fujitsu.com>
-
由 Olivia Yin 提交于
The "dtb" option sets the filename for the device tree. If without this option support, "-dtb file" will be converted into <qemu:commandline> in domain XML file. For example, '-dtb /media/ram/test.dtb' will be converted into <qemu:commandline> <qemu:arg value='-dtb'/> <qemu:arg value='/media/ram/test.dtb'/> </qemu:commandline> This is not very friendly. This patchset add special <dtb> tag like <kernel> and <initrd> which is easier for user to write domain XML file. <os> <type arch='ppc' machine='ppce500v2'>hvm</type> <kernel>/media/ram/uImage</kernel> <initrd>/media/ram/ramdisk</initrd> <dtb>/media/ram/test.dtb</dtb> <cmdline>root=/dev/ram rw console=ttyS0,115200</cmdline> </os> Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 18 3月, 2013 1 次提交
-
-
由 Jiri Denemark 提交于
Commit 82d5fe54 qemu: check backing chains even when cgroup is omitted added backing file checks just before the code that removes optional disks if they are not present. However, the backing chain code fails in case the disk file does not exist, which makes qemuProcessStart fail regardless on configured startupPolicy. Note that startupPolicy implementation is still wrong after this patch since it only check the first file in a possible chain. It should rather check the complete backing chain. But this is an existing limitation that can be solved later. After all, startupPolicy is most useful for CDROM images and they won't make use of backing files in most cases.
-
- 16 3月, 2013 4 次提交
-
-
由 Paolo Bonzini 提交于
QEMU 1.3 and newer support an alternative URI-based syntax to specify the location of an NBD server. Libvirt can keep on using the old syntax in general, but only the URI syntax supports IPv6 addresses. The URI syntax also supports relative paths to Unix sockets. These should never be used but aren't explicitly blocked either by the parser, so support it just in case. The URI syntax is intentionally compatible with Gluster's, and the code can be reused. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Paolo Bonzini 提交于
This reuses the XML format that was introduced for Gluster. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Paolo Bonzini 提交于
These are supported by nbd-server and by the NBD server that QEMU embeds for live image access. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Paolo Bonzini 提交于
Move the code to an external function, and structure it to prepare the addition of new features in the next few patches. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 15 3月, 2013 4 次提交
-
-
由 Paolo Bonzini 提交于
QEMU added -drive in 2007, and NBD in 2008. Both appeared first in release 0.10.0. Thus the code to support network disks without -drive is dead, and in fact it incorrectly escapes commas. Drop it. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Li Zhang 提交于
When getting CPUs' information, it assumes that CPU indexes are not contiguous. But for ppc64 platform, CPU indexes are not contiguous because SMT is needed to be disabled, so CPU information is not right on ppc64 and vpuinfo, vcpupin can't work corretly. This patch is to remove the assumption to be compatible with ppc64. Test: 4 vcpus are assigned to one VM and execute vcpuinfo command. Without patch: There is only one vcpu informaion can be listed. With patch: All vcpus' information can be listed correctly. Signed-off-by: NLi Zhang <zhlcindy@linux.vnet.ibm.com>
-
由 Viktor Mihajlovski 提交于
Newer versions of QEMU support virtio-scsi and virtio-rng devices on the virtio-s390 and ccw buses. Adding capability detection, address assignment and command line generation for that. Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
-
由 Viktor Mihajlovski 提交于
QEMU_CAPS_VIRTIO_SCSI_PCI implies that virtio-scsi is only supported for the PCI bus, which is not the case. Remove the _PCI suffix. Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
-
- 14 3月, 2013 4 次提交
-
-
由 Eric Blake 提交于
Multi-head QXL support is so useful that distros have started to backport it to qemu earlier than 1.2. After discussion with Alon Levy, we determined that the existence of the qxl-vga.surfaces property is a reliable indicator of whether '-device qxl-vga' works, or whether we have to stick to the older '-vga qxl'. I'm leaving in the existing check for QEMU_CAPS_DEVICE_VIDEO_PRIMARY tied to qemu 1.2 and newer (in case qemu is built without qxl support), but for those distros that backport qxl, this additional capability check will allow the correct command line for both RHEL 6.3 (which lacks the feature) and RHEL 6.4 (where qemu still claims to be version 0.12.2.x, but has backported multi-head qxl). * src/qemu/qemu_capabilities.c (virQEMUCapsObjectPropsQxlVga): New property test. (virQEMUCapsExtractDeviceStr): Probe for backport of new capability to qemu earlier than 1.2. * tests/qemuhelpdata/qemu-kvm-1.2.0-device: Update test. * tests/qemuhelpdata/qemu-1.2.0-device: Likewise. * tests/qemuhelpdata/qemu-kvm-0.12.1.2-rhel62-beta-device: Likewise.
-
由 Peter Krempa 提交于
Qemu's implementation of virtio RNG supports rate limiting of the entropy used. This patch exposes the option to tune this functionality. This patch is based on qemu commit 904d6f588063fb5ad2b61998acdf1e73fb4 The rate limiting is exported in the XML as: <devices> ... <rng model='virtio'> <rate bytes='123' period='1234'/> <backend model='random'/> </rng> ...
-
由 J.B. Joret 提交于
We didn't yet expose the virtio device attach and detach functionality for s390 domains as the device hotplug was very limited with the old virtio-s390 bus. With the CCW bus there's full hotplug support for virtio devices in QEMU, so we are adding this to libvirt too. Since the virtio hotplug isn't limited to PCI anymore, we change the function names from xxxPCIyyy to xxxVirtioyyy, where we handle all three virtio bus types. Signed-off-by: NJ.B. Joret <jb@linux.vnet.ibm.com> Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
-
由 Viktor Mihajlovski 提交于
This commit adds the QEMU driver support for CCW addresses. The current QEMU only allows virtio devices to be attached to the CCW bus. We named the new capability indicating that support QEMU_CAPS_VIRTIO_CCW accordingly. The fact that CCW devices can only be assigned to domains with a machine type of s390-ccw-virtio requires a few extra checks for machine type in qemu_command.c on top of querying QEMU_CAPS_VIRTIO_{CCW|S390}. The majority of the new functions deals with CCW address generation and management. Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
-
- 13 3月, 2013 2 次提交
-
-
由 Michal Privoznik 提交于
With our recent patch (1715c83b) we thrive to get the correct number of maximal VCPUs. However, we are using a constant from linux/kvm.h which may be not defined in every distro. Hence, we should guard usage of the constant with ifdef preprocessor directive. This was introduced in kernel: commit 8c3ba334f8588e1d5099f8602cf01897720e0eca Author: Sasha Levin <levinsasha928@gmail.com> Date: Mon Jul 18 17:17:15 2011 +0300 KVM: x86: Raise the hard VCPU count limit The patch raises the hard limit of VCPU count to 254. This will allow developers to easily work on scalability and will allow users to test high VCPU setups easily without patching the kernel. To prevent possible issues with current setups, KVM_CAP_NR_VCPUS now returns the recommended VCPU limit (which is still 64) - this should be a safe value for everybody, while a new KVM_CAP_MAX_VCPUS returns the hard limit which is now 254. $ git desc 8c3ba334f v3.1-rc7-48-g8c3ba33
-
由 Peter Krempa 提交于
The virCaps structure gathered a ton of irrelevant data over time that. The original reason is that it was propagated to the XML parser functions. This patch aims to create a new data structure virDomainXMLConf that will contain immutable data that are used by the XML parser. This will allow two things we need: 1) Get rid of the stuff from virCaps 2) Allow us to add callbacks to check and add driver specific stuff after domain XML is parsed. This first attempt removes pointers to private data allocation functions to this new structure and update all callers and function that require them.
-
- 12 3月, 2013 2 次提交
-
-
由 Jiri Denemark 提交于
At least one caller may call qemuSharedDiskEntryFree with NULL as the first argument. Let's make the function similar to other *Free functions and do nothing in such case.
-
由 Peter Krempa 提交于
The detection of the maximum number of cpus used incorrect ioctl argument value. This flaw caused that on kvm hosts this returns always "160" as the maximum. This is just a recommended maximum value. The real value is higher than that. This patch tweaks the detection function to behave as described by the kernel docs: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/virtual/kvm/api.txt?id=refs/tags/v3.9-rc2#n199
-
- 08 3月, 2013 2 次提交
-
-
由 Michal Privoznik 提交于
When there are two concurrent threads, we may dereference a NULL pointer, even though it has been checked before: 1. Thread1: starts executing qemuDomainBlockStatsFlags() with nparams != 0. It finds given disk and successfully pass check for disk->info.alias not being NULL. 2. Thread2: starts executing qemuDomainDetachDeviceFlags() on the very same disk as Thread1 is working on. 3. Thread1: gets to qemuDomainObjBeginJob() where it sets a job on a domain. 4. Thread2: also tries to set a job. However, we are not guaranteed which thread wins. So assume it's Thread2 who can continue. 5. Thread2: does the actual detach and frees disk->info.alias 6. Thread2: quits the job 7. Thread1: now successfully acquires the job, and accesses a NULL pointer.
-
由 Daniel P. Berrange 提交于
The current QEMU code for skipping log messages only skips over 'debug' message, switch to virLogProbablyLogMessage to make sure it skips over all of them
-
- 06 3月, 2013 1 次提交
-
-
由 Guannan Ren 提交于
virsh subcommand memtune forgot updating domain live xml after setting cgroup value.
-
- 05 3月, 2013 1 次提交
-
-
由 Satoru Moriya 提交于
19c6ad9a (qemu: Refactor qemuDomainSetMemoryParameters) introduced a new macro, VIR_GET_LIMIT_PARAMETER(PARAM, VALUE). But if statement in the macro is not correct and so set_XXXX flags are set to false in the wrong. As a result, libvirt ignores all memtune parameters. This patch fixes the conditional expression to work correctly. Signed-off-by: NSatoru Moriya <satoru.moriya@hds.com>
-
- 04 3月, 2013 2 次提交
-
-
由 Peter Krempa 提交于
At the start of the guest after the image is unlinked the state wasn't touched up to match the state on disk.
-
由 Christophe Fergeau 提交于
Commit f506a4c1 changed virSetUIDGID() to be a noop when uid/gid are -1, while it used to be a noop when they are <= 0. The changes in this commit broke creating new VMs in GNOME Boxes as qemuDomainCheckDiskPresence gets called during domain creation/startup, which in turn calls virFileAccessibleAs which fails after calling virSetUIDGID(0, 0) (Boxes uses session libvirtd). virSetUIDGID is called with (0, 0) as these are the default user/group values in virQEMUDriverConfig for session libvirtd. This commit changes virQEMUDriverConfigNew to use -1 as the unpriviledged uid/gid. I've also looked at the various places where cfg->user is used, and they all seem to handle -1 correctly.
-
- 01 3月, 2013 5 次提交
-
-
由 Daniel P. Berrange 提交于
This reverts the hack done in commit 568a6cda Author: Jiri Denemark <jdenemar@redhat.com> Date: Fri Feb 15 15:11:47 2013 +0100 qemu: Avoid deadlock in autodestroy since we now have a fix which avoids the deadlock scenario entirely
-
由 Daniel P. Berrange 提交于
There is a lock ordering problem in the QEMU close callback APIs. When starting a guest we have a lock on the VM. We then set a autodestroy callback, which acquires a lock on the close callbacks. When running auto-destroy, we obtain a lock on the close callbacks, then run each callbacks - which obtains a lock on the VM. This causes deadlock if anyone tries to start a VM, while autodestroy is taking place. The fix is to do autodestroy in 2 phases. First obtain all the callbacks and remove them from the list under the close callback lock. Then invoke each callback from outside the close callback lock. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
When the auto-destroy callback runs it is supposed to return NULL if the virDomainObjPtr is no longer valid. It was not doing this for transient guests, so we tried to virObjectUnlock a mutex which had been freed. This often led to a crash. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Jiri Denemark 提交于
qemuProcessStart expects to be run with a job already set and every caller except for qemuMigrationPrepareAny use it correctly. This bug can be observed in libvirtd logs during incoming migration as warning : qemuDomainObjEnterMonitorInternal:979 : This thread seems to be the async job owner; entering monitor without asking for a nested job is dangerous
-
由 Serge Hallyn 提交于
As pointed out in https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1034661 The sentence "The function of PCI device addresses must less than 8" does not quite make sense. Update that to read "The function of PCI device addresses must be less than 8" Signed-off-by: NSerge Hallyn <serge.hallyn@ubuntu.com>
-
- 28 2月, 2013 1 次提交
-
-
由 Michal Privoznik 提交于
Currently, qemuDomainShutdownFlags() chooses the agent method of shutdown whenever the agent is configured. However, this assumption is not enough as the guest agent may be unresponsive at the moment. So unless guest agent method has been explicitly requested, we should fall back to the ACPI method.
-