- 17 5月, 2013 4 次提交
-
-
由 Osier Yang 提交于
unpriv_sgio setting is tight with the shared device helpers, let's put them together in qemu_conf.c
-
由 Osier Yang 提交于
SCSI host device will also support "sgio", and perhaps we could use "sgio" in other places too in future, renaming the enum to reuse.
-
由 Osier Yang 提交于
This adds the shared device entry when starting domain (more exactly, when preparing host devices), and remove the entry when destroying domain (when reattaching host devices).
-
由 Osier Yang 提交于
This changes the helpers qemu{Add,Remove}SharedDisk into qemu{Add,Remove}SharedDevice, as most of the code in the helpers can be reused for scsi host device. To track the shared scsi host device, first it finds out the device path (e.g. /dev/s[dr]*) which is mapped to the sg device, and use device ID of the found device path (/dev/s[dr]*) as the hash key. This is because of the device ID is not unique between between /dev/s[dr]* and /dev/sg*, e.g. % sg_map /dev/sg0 /dev/sda /dev/sg1 /dev/sr0 % ls -l /dev/sda brw-rw----. 1 root disk 8, 0 May 2 19:26 /dev/sda %ls -l /dev/sg0 crw-rw----. 1 root disk 21, 0 May 2 19:26 /dev/sg0
-
- 16 5月, 2013 2 次提交
-
-
由 Osier Yang 提交于
"Shared disk" is not only the thing we should care about after "scsi hostdev" is introduced. A same scsi device can be used as "disk" for one domain, and as "scsi hostdev" for another domain at the same time. That's why this patch renames qemu_driver->sharedDisks. Related functions and structs are also renamed.
-
由 Viktor Mihajlovski 提交于
Commit 7f15ebc7 introduced a bug happening when guests without a <graphics> element are migrated. The initialization of listenAddress happens unconditionally from the cookie even if the cookie->graphics pointer was NULL. Moved the initialization to where it is safe. Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
-
- 15 5月, 2013 6 次提交
-
-
由 Osier Yang 提交于
QEMU introduced "discard" option for drive since commit a9384aff53, <...> @var{discard} is one of "ignore" (or "off") or "unmap" (or "on") and controls whether @dfn{discard} (also known as @dfn{trim} or @dfn{unmap}) requests are ignored or passed to the filesystem. Some machine types may not support discard requests. </...> This patch exposes the support in libvirt. QEMU supported "discard" for "-drive" since v1.5.0-rc0: % git tag --contains a9384aff53 contains v1.5.0-rc0 v1.5.0-rc1 So this only detects the capability bit using virQEMUCapsProbeQMPCommandLine.
-
由 John Ferlan 提交于
-
由 John Ferlan 提交于
During building of the qemu command line determine whether to add/use the '-no-reboot' option only if each of the 'on' events want to to destroy the domain; otherwise, use the '-no-shutdown' option. Prior to this change both could be on the command line, which while allowed could be construed as a conflict.
-
由 Martin Kletzander 提交于
Adding a VNC WebSocket support for QEMU driver. This functionality is in upstream qemu from commit described as v1.3.0-982-g7536ee4, so the capability is being recognized based on QEMU version for now.
-
由 Osier Yang 提交于
QEMU introduced command line "-mem-merge=on|off" (defaults to on) to enable/disable the memory merge (KSM) at guest startup. This exposes it by new XML: <memoryBacking> <nosharepages/> </memoryBacking> The XML tag is same with what we used internally for old RHEL.
-
由 Eric Blake 提交于
* src/qemu/qemu_capabilities.h: New capability bit. * src/qemu/qemu_capabilities.c (virQEMUCapsProbeQMPCommandLine): New function, based on qemuMonitorGetCommandLineOptionParameters, which was introduced by commit bd56d0d8; use it to set new capability bit. (virQEMUCapsInitQMP): Use new function.
-
- 14 5月, 2013 6 次提交
-
-
由 Daniel P. Berrange 提交于
The QEMU command line syntax for RBD disks is file=rbd:pool/image:opt1=val1:opt2=val2... There is no way to escape the ':' if it appears in the pool or image name. Thus it must be explicitly forbidden if it occurs in the libvirt XML. People are known to be abusing the lack of escaping in current libvirt to pass arbitrary args to QEMU. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Eric Blake 提交于
Commit bd56d0d8 could lead to freeing an uninitialized pointer: qemu/qemu_monitor_json.c: In function 'qemuMonitorJSONGetCommandLineOptionParameters': qemu/qemu_monitor_json.c:4284: warning: 'cmd' may be used uninitialized in this function * src/qemu/qemu_monitor_json.c (qemuMonitorJSONGetCommandLineOptionParameters): Initialize variable. Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Eric Blake 提交于
Ever since the conversion to using only QMP for probing features of qemu 1.2 and newer, we have been unable to detect features that are added only by additional command line options. For example, we'd like to know if '-machine mem-merge=on' (added in qemu 1.5) is present. To do this, we will take advantage of qemu 1.5's query-command-line-parameters QMP call [1]. This patch wires up the framework for probing the command results; if the QMP command is missing, or if a particular command line option does not output any parameters (for example, -net uses a polymorphic parser, which showed up as no parameters as of qemu 1.5), we silently treat that command as having no results. [1] https://lists.gnu.org/archive/html/qemu-devel/2013-04/msg05180.html * src/qemu/qemu_monitor.h (qemuMonitorGetOptions) (qemuMonitorSetOptions) (qemuMonitorGetCommandLineOptionParameters): New functions. * src/qemu/qemu_monitor_json.h (qemuMonitorJSONGetCommandLineOptionParameters): Likewise. * src/qemu/qemu_monitor.c (_qemuMonitor): Add cache field. (qemuMonitorDispose): Clean it. (qemuMonitorGetCommandLineOptionParameters): Implement new function. * src/qemu/qemu_monitor_json.c (qemuMonitorJSONGetCommandLineOptionParameters): Likewise. (testQemuMonitorJSONGetCommandLineParameters): Test it. Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Eric Blake 提交于
No need to open code a string list cleanup, if we are nice to the caller by guaranteeing a NULL-terminated result. * src/qemu/qemu_monitor_json.c (qemuMonitorJSONGetCPUDefinitions) (qemuMonitorJSONGetCommands, qemuMonitorJSONGetEvents) (qemuMonitorJSONGetObjectTypes, qemuMonitorJSONGetObjectProps): Use simpler cleanup. Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Eric Blake 提交于
Follows on the heels of other bool cleanups, such as commit 93002b98. * src/qemu/qemu_monitor.h (qemuMonitorOpen, qemuMonitorOpenFD): Update json parameter type. * src/qemu/qemu_monitor.c (qemuMonitorOpen, qemuMonitorOpenFD): Likewise. (_qemuMonitor): Adjust field type. * src/qemu/qemu_domain.h (_qemuDomainObjPrivate): Likewise. * src/qemu/qemu_domain.c (qemuDomainObjPrivateXMLParse): Adjust client. * src/qemu/qemu_process.c (qemuProcessStart): Likewise. * tests/qemumonitortestutils.c (qemuMonitorTestNew): Likewise. Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Han Cheng 提交于
This adds both attachment and detachment support for scsi host device. Signed-off-by: NHan Cheng <hanc.fnst@cn.fujitsu.com> Signed-off-by: NOsier Yang <jyang@redhat>
-
- 13 5月, 2013 10 次提交
-
-
由 Jim Fehlig 提交于
Found that I was unable to start existing domains after updating to a kernel with no cgroups support # zgrep CGROUP /proc/config.gz # CONFIG_CGROUPS is not set # virsh start test error: Failed to start domain test error: Unable to initialize /machine cgroup: Cannot allocate memory virCgroupPartitionNeedsEscaping() correctly returns errno (ENOENT) when attempting to open /proc/cgroups on such a system, but it was being dropped in virCgroupSetPartitionSuffix(). Change virCgroupSetPartitionSuffix() to propagate errors returned by its callees. Also check for ENOENT in qemuInitCgroup() when determining if cgroups support is available.
-
由 Osier Yang 提交于
It's better to put the usb related codes into qemuDomainAttachHostUsbDevice instead of qemuDomainAttachHostDevice. And in the old qemuDomainAttachHostDevice, just stealing the "usb" from driver->activeUsbHostdevs leaks the memory.
-
由 Han Cheng 提交于
Although virtio-scsi supports SCSI PR (Persistent Reservations), the device on host may do not support it. To avoid losing data, Just like PCI and USB pass through devices, only one live guest is allowed per SCSI host pass through device." Signed-off-by: NHan Cheng <hanc.fnst@cn.fujitsu.com>
-
由 Daniel P. Berrange 提交于
The <filesystem> element can now accept a <driver type='nbd'/> as an alternative to 'loop'. The benefit of NBD is support for non-raw disk image formats. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Extend the <driver> element in filesystem devices to allow a storage format to be set. The new attribute uses 'format' to reflect the storage format. This is different from the <driver> element in disk devices which use 'type' to reflect the storage format. This is because the 'type' attribute on filesystem devices is already used for the driver backend, for which the disk devices use the 'name' attribute. Arggggh. Anyway for disks we have <driver name="qemu" type="raw"/> And for filesystems this change means we now have <driver type="loop" format="raw"/> Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Han Cheng 提交于
This adds the scsi-generic device into the device controller's whitelist, so that it's allowed to used by the qemu process. Signed-off-by: NHan Cheng <hanc.fnst@cn.fujitsu.com> Signed-off-by: NOsier Yang <jyang@redhat.com>
-
由 Osier Yang 提交于
-
由 Osier Yang 提交于
Since it's generic enough to be used by other types in future, I put it in <hostdev> as sub-element, though now it's only used by scsi host device.
-
由 Han Cheng 提交于
Except the scsi host device's controller is "lsilogic", mapping between the libvirt attributes and scsi-generic properties is: libvirt qemu ----------------------------------------- controller bus ($libvirt_controller.0) bus channel target scsi-id unit lun For scsi host device with "lsilogic" controller, the mapping is: ('target (libvirt)' must be 0, as it's not used; 'unit (libvirt) must <= 7). libvirt qemu ---------------------------------------------------------- controller && bus bus ($libvirt_controller.$libvirt_bus) unit scsi-id It's not good to hardcode/hard-check limits of these attributes, and even worse, these limits are not documented, one has to find out by either testing or reading the qemu code, I'm looking forward to qemu expose limits like these one day). For example, exposing "max_target", "max_lun" for megasas: static const struct SCSIBusInfo megasas_scsi_info = { .tcq = true, .max_target = MFI_MAX_LD, .max_lun = 255, .transfer_data = megasas_xfer_complete, .get_sg_list = megasas_get_sg_list, .complete = megasas_command_complete, .cancel = megasas_command_cancel, }; Example of the qemu command line (lsilogic controller): -drive file=/dev/sg2,if=none,id=drive-hostdev-scsi_host7-0-0-0 \ -device scsi-generic,bus=scsi0.0,scsi-id=8,\ drive=drive-hostdev-scsi_host7-0-0-0,id=hostdev-scsi_host7-0-0-0 Example of the qemu command line (virtio-scsi controller): -drive file=/dev/sg2,if=none,id=drive-hostdev-scsi_host7-0-0-0 \ -device scsi-generic,bus=scsi0.0,channel=0,scsi-id=128,lun=128,\ drive=drive-hostdev-scsi_host7-0-0-0,id=hostdev-scsi_host7-0-0-0 Signed-off-by: NHan Cheng <hanc.fnst@cn.fujitsu.com> Signed-off-by: NOsier Yang <jyang@redhat.com>
-
由 Han Cheng 提交于
Adding two cap flags for scsi-generic: QEMU_CAPS_SCSI_GENERIC QEMU_CAPS_SCSI_GENERIC_BOOTINDEX Signed-off-by: NHan Cheng <hanc.fnst@cn.fujitsu.com> Signed-off-by: NOsier Yang <jyang@redhat.com>
-
- 11 5月, 2013 2 次提交
-
-
由 Daniel P. Berrange 提交于
It is possible to build a kernel without swap cgroup controls present. This causes a fatal error when querying memory parameters. Treat missing swap controls as meaning "unlimited". The fatal error remains if the user tries to actually change the limit. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Laine Stump 提交于
This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=851411 https://bugzilla.redhat.com/show_bug.cgi?id=955500 The first problem was that virFileOpenAs was returning fd (-1) in one of the error cases rather than ret (-errno), so the caller thought that the error was EPERM rather than ENOENT. The second problem was that some log messages in the general purpose qemuOpenFile() function would always say "Failed to create" even if the caller hadn't included O_CREAT (i.e. they were trying to open an existing file). This fixes virFileOpenAs to jump down to the error return (which returns ret instead of fd) in the previously mentioned incorrect failure case of virFileOpenAs(), removes all error logging from virFileOpenAs() (since the callers report it), and modifies qemuOpenFile to appropriately use "open" or "create" in its log messages. NB: I seriously considered removing logging from all callers of virFileOpenAs(), but there is at least one case where the caller doesn't want virFileOpenAs() to log any errors, because it's just going to try again (qemuOpenFile()). We can't simply make a silent variation of virFileOpenAs() though, because qemuOpenFile() can't make the decision about whether or not it wants to retry until after virFileOpenAs() has already returned an error code. Likewise, I also considered changing virFileOpenAs() to return -1 with errno set on return, and may still do that, but only as a separate patch, as it obscures the intent of this patch too much.
-
- 09 5月, 2013 1 次提交
-
-
由 Ján Tomko 提交于
The controller element supports non-disk controller types too. https://bugzilla.redhat.com/show_bug.cgi?id=960958
-
- 08 5月, 2013 6 次提交
-
-
由 Daniel P. Berrange 提交于
The LXC, QEMU, and LibXL drivers have all merged their handling of the attach/update/modify device APIs into one large 'xxxxDomainModifyDeviceFlags' which then does a 'switch()' based on the actual API being invoked. While this saves some lines of code, it is not really all that significant in the context of the driver API impls as a whole. This merger of the handling of different APIs creates pain when wanting to automated analysis of the code and do things which are specific to individual APIs. The slight duplication of code from unmerged the API impls, is preferrable to allow for easier automated analysis. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Currently the parsing of XML is pushed down into the various migration helper APIs. This makes it difficult to insert the correct access control checks, since one helper API services many public APIs. Pull the parsing of XML up to the top level of the QEMU driver APIs
-
由 Daniel P. Berrange 提交于
Several APIs allow for custom XML to be passed in. This is checked for ABI stability, which will ensure the UUID is not being changed. There isn't validation that the name did not change though. This could allow renaming of guests via the backdoor, which in turn could allow for bypassing access control restrictions based on names. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
The individual hypervisor drivers were directly referencing APIs in virnodesuspend.c in their virDriverPtr struct. Separate these methods, so there is always a wrapper in the hypervisor driver. This allows the unused virConnectPtr args to be removed from the virnodesuspend.c file. Again this will ensure that ACL checks will only be performed on invocations that are directly associated with public API usage. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
The individual hypervisor drivers were directly referencing APIs in src/nodeinfo.c in their virDriverPtr struct. Separate these methods, so there is always a wrapper in the hypervisor driver. This allows the unused virConnectPtr args to be removed from the nodeinfo.c file. Again this will ensure that ACL checks will only be performed on invocations that are directly associated with public API usage. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Currently the virGetHostname() API has a bogus virConnectPtr parameter. This is because virtualization drivers directly reference this API in their virDriverPtr tables, tieing its API design to the public virConnectGetHostname API design. This also causes problems for access control checks since these must only be done for invocations from the public API, not internal invocation. Remove the bogus virConnectPtr parameter, and make each hypervisor driver provide a dedicated function for the driver API impl. This will allow access control checks to be easily inserted later. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 07 5月, 2013 3 次提交
-
-
由 Ján Tomko 提交于
Use virBufferAddLit or virBufferAddChar instead.
-
由 Laine Stump 提交于
VFIO device assignment requires a cgroup ACL to be setup for access to the /dev/vfio/nn "group" device for any devices that will be assigned to a guest. In the case of a host device that is allocated from a pool, it was being allocated during qemuBuildCommandLine(), which is called by qemuProcessStart() *after* the all-encompassing qemuSetupCgroup() was called, meaning that the standard Cgroup ACL setup wasn't creating ACLs for these devices allocated from pools. One possible solution was to manually add a single ACL down inside qemuBuildCommandLine() when networkAllocateActualDevice() is called, but that has two problems: 1) the function that adds the cgroup ACL requires a virDomainObjPtr, which isn't available in qemuBuildCommandLine(), and 2) we really shouldn't be doing network device setup inside qemuBuildCommandLine() anyway. Instead, I've created a new function called qemuNetworkPrepareDevices() which is called just before qemuPrepareHostDevices() during qemuProcessStart() (explanation of ordering in the comments), i.e. well before the call to qemuSetupCgroup(). To minimize code churn in a patch that will be backported to 1.0.5-maint, qemuNetworkPrepareDevices only does networkAllocateActualDevice() and the bare amount of setup required for type='hostdev network devices, but it eventually should do *all* device setup for guest network devices. Note that some of the code that was previously needed in qemuBuildCommandLine() is no longer required when networkAllocateActualDevice() is called earlier: * qemuAssignDeviceHostdevAlias() is already done further down in qemuProcessStart(). * qemuPrepareHostdevPCIDevices() is called by qemuPrepareHostDevices() which is called after qemuNetworkPrepareDevices() in qemuProcessStart(). As hinted above, this new function should be moved into a separate qemu_network.c (or similarly named) file along with qemuPhysIfaceConnect(), qemuNetworkIfaceConnect(), and qemuOpenVhostNet(), and expanded to call those functions as well, then the nnets loop in qemuBuildCommandLine() should be reduced to only build the commandline string (which itself can be in a separate qemuInterfaceBuilldCommandLine() function as suggested by Michal). However, this will require storing away an array of tapfd and vhostfd that are needed for the commandline, so I would rather do that in a separate patch and leave this patch at the minimum to fix the bug.
-
由 Boris Fiuczynski 提交于
On architectures not supporting the Intel specific programmable interval timer, like e.g. S390, starting a domain with a clock definition containing a pit timer results in the error "Option no-kvm-pit-reinjection not supported for this target". By moving the capability enablement for -no-kvm-pit-reinjection from the InitQMPBasic section into the x86_64 and i686 only enablement section all other architectures are no longer automatically enabled. In addition architecture related capabilities enablements have refactored into a new architecture bound capabilities initialization function. Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com> Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
-