- 10 2月, 2017 3 次提交
-
-
由 Jim Fehlig 提交于
When a user does not explicitly set a <driver> in the disk config, libvirt defers selection of a default to libxl. This approach works fine when starting a domain with such configuration or attaching a disk to a running domain. But when detaching such a disk, libxl will fail with "unrecognized disk backend type: 0". libxl makes no attempt to recalculate a default backend (driver) on detach and simply fails when uninitialized. This patch updates the libvirt disk config with the backend selected by libxl when starting a domain or attaching a disk to a running domain. Another benefit of this approach is that the live XML is also updated with the backend driver selected by libxl.
-
由 Jim Fehlig 提交于
When starting a domian, a libxl_domain_config object is created from virDomainDef. Any virDomainDiskDef devices with a format of VIR_STORAGE_FILE_NONE are mapped to LIBXL_DISK_FORMAT_RAW in the corresponding libxl_disk_device, but the virDomainDiskDef format is never updated to reflect the change. A better place to set a default format for disk devices is the device post-parse callback, ensuring the virDomainDiskDef object reflects the default format.
-
由 Boris Fiuczynski 提交于
Document the ovs_timeout introduced to libvirtd.conf in previous patches. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 09 2月, 2017 18 次提交
-
-
由 Boris Fiuczynski 提交于
Since a successful completion of the calls to openvswitch is expected a longer timeout should be able to be chosen to account for loaded systems. Therefore this patch provides the ability to specify the timeout value for openvswitch calls in the libvirtd configuration file. Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com> Reviewed-by: NBjoern Walk <bwalk@linux.vnet.ibm.com>
-
由 Boris Fiuczynski 提交于
This patchs allows to set the timeout value used for all openvswitch calls. The default timeout value remains as before at 5 seconds. Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com> Reviewed-by: NBjoern Walk <bwalk@linux.vnet.ibm.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Boris Fiuczynski 提交于
Provide the ability to specify a default timeout value for successful completion of openvswitch calls in the libvirtd configuration file. Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com> Reviewed-by: NBjoern Walk <bwalk@linux.vnet.ibm.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Jaroslav Safka 提交于
Document the extensions made to domain <memoryBacking/> element made in previous commits. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Jaroslav Safka 提交于
This patch add support for file memory backing on numa topology. The specified access mode in memoryBacking can be overriden by specifying token memAccess in numa cell.
-
由 Jaroslav Safka 提交于
This part introduces new xml elements for file based memorybacking support and their parsing. (It allows vhost-user to be used without hugepages.) New xml elements: <memoryBacking> <source type="file|anonymous"/> <access mode="shared|private"/> <allocation mode="immediate|ondemand"/> </memoryBacking>
-
由 Jaroslav Safka 提交于
Add new parameter memory_backing_dir where files will be stored when memoryBacking source is selected as file. Value is stored inside char* memoryBackingDir
-
由 Jaroslav Safka 提交于
Rename to avoid duplicate code. Because virDomainMemoryAccess will be used in memorybacking for setting default behaviour. NOTE: The enum cannot be moved to qemu/domain_conf because of headers dependency
-
由 Maxim Nestratov 提交于
Strings associated with virDomainHyperv values in domain_conf.c are used to construct HyperV CPU features names to be compared with names defined in cpu_x86_data.h and the names for HyperV "spinlocks" feature don't match. This leads to a misleading warning: "host doesn't support hyperv 'spinlocks' feature" even when it's supported. Let's fix it and rename along with it VIR_CPU_x86_KVM_HV_SPINLOCK to VIR_CPU_x86_KVM_HV_SPINLOCKS. Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
virCPUDefStealModel is called with keepVendor == true which means the cpu structure will keep its original vendor/vendor_id values. Thus it makes no sense to copy them to the translated definition as they won't be used there anyway. Except that the translated->vendor pointer might get lost in x86Decode. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Maxim Nestratov 提交于
PARALLELS_STATISTICS_DROP_COUNT isn't used anymore Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>
-
由 Maxim Nestratov 提交于
When we happen to lose a domain but still get a performance event for it, we should also free the event handle. Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>
-
由 Maxim Nestratov 提交于
Every successful call of PrlEvent_GetParamByName allocates a handle, which has to be freed. Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>
-
由 Michal Privoznik 提交于
Just like we need wrappers over other virSecurityManager APIs, we need one for virSecurityManagerSetImageLabel and virSecurityManagerRestoreImageLabel. Otherwise we might end up relabelling device in wrong namespace. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Jim Fehlig 提交于
The typical pattern when calling libxl functions that populate a structure is libxl_foo foo; libxl_foo_init(&foo); libxl_get_foo(ctx, &foo); ... libxl_foo_dispose(&foo); Fix several instances of libxl_physinfo missing the init and dispose calls. Signed-off-by: NJim Fehlig <jfehlig@suse.com>
-
由 Jim Fehlig 提交于
libxlGetAutoballoonConf is supposed to honor user-specified autoballoon setting in libxl.conf. As written, the user-specified setting could be overwritten by the subsequent logic to check dom0_mem parameter. If user-specified setting is present and correct, accept it. Only fallback to checking Xen dom0_mem command line parameter if user-specfied setting is not present. Signed-off-by: NJim Fehlig <jfehlig@suse.com>
-
- 08 2月, 2017 14 次提交
-
-
由 Joao Martins 提交于
If no graphics element is in XML xenFormatXLSpice will access graphics without checking it has one in the first place, leading to a segmentation fault. Signed-off-by: NJoao Martins <joao.m.martins@oracle.com>
-
由 Michal Privoznik 提交于
Firstly, instead of checking for next->path the virStorageSourceIsEmpty() function should be used which also takes disk type into account. Secondly, not every disk source passed has the correct type set (due to our laziness). Therefore, instead of checking for virStorageSourceIsBlockLocal() and also S_ISBLK() the former can be refined to just virStorageSourceIsLocalStorage(). Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Again, one missed bit. This time without this commit there is no /dev entry in the namespace of the qemu process when doing disk snapshots or block-copy. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
These functions do not need to see the whole virDomainDiskDef. Moreover, they are going to be called from places where we don't have access to the full disk definition. Sticking with virStorageSource is more than enough. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Since its introduction in 81df2150 this variable was never used. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
There is no need for this. None of the namespace helpers uses it. Historically it was used when calling secdriver APIs, but we don't to that anymore. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
This struct is unused after 095f042e. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Again, one missed bit. This time without this commit there is no /dev entry in the namespace of the qemu process when attaching vhost SCSI device. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Since we have qemuSecurity wrappers over virSecurityManagerSetHostdevLabel and virSecurityManagerRestoreHostdevLabel we ought to use them instead of calling secdriver APIs directly. Without those wrappers the labelling won't be done in the correct namespace and thus won't apply to the nodes seen by qemu itself. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Laine Stump 提交于
libvirt was able to set the host_mtu option when an MTU was explicitly given in the interface config (with <mtu size='n'/>), set the MTU of a libvirt network in the network config (with the same named subelement), and would automatically set the MTU of any tap device to the MTU of the network. This patch ties that all together (for networks based on tap devices and either Linux host bridges or OVS bridges) by learning the MTU of the network (i.e. the bridge) during qemuInterfaceBridgeConnect(), and returning that value so that it can then be passed to qemuBuildNicDevStr(); qemuBuildNicDevStr() then sets host_mtu in the interface's commandline options. The result is that a higher MTU for all guests connecting to a particular network will be plumbed top to bottom by simply changing the MTU of the network (in libvirt's config for libvirt-managed networks, or directly on the bridge device for simple host bridges or OVS bridges managed outside of libvirt). One question I have about this - it occurred to me that in the case of migrating a guest from a host with an older libvirt to one with a newer libvirt, the guest may have *not* had the host_mtu option on the older machine, but *will* have it on the newer machine. I'm curious if this could lead to incompatibilities between source and destination (I guess it all depends on whether or not the setting of host_mtu has a practical effect on a guest that is already running - Maxime?) Likewise, we could run into problems when migrating from a newer libvirt to older libvirt - The guest would have been told of the higher MTU on the newer libvirt, then migrated to a host that didn't understand <mtu size='blah'/>. (If this really is a problem, it would be a problem with or without the current patch).
-
由 Laine Stump 提交于
This resolves: https://bugzilla.redhat.com/1224348
-
由 Laine Stump 提交于
Example: <network> ... <mtu size='9000'/> ... If mtu is unset, it's assumed that we want the default for whatever is the underlying transport (usually this is 1500). This setting isn't yet wired in, so it will have no effect. This partially resolves: https://bugzilla.redhat.com/1224348
-
由 Laine Stump 提交于
virNetDevTapCreateInBridgePort() has always set the new tap device to the current MTU of the bridge it's being attached to. There is one case where we will want to set the new tap device to a different (usually larger) MTU - if that's done with the very first device added to the bridge, the bridge's MTU will be set to the device's MTU. This patch allows for that possibility by adding "int mtu" to the arg list for virNetDevTapCreateInBridgePort(), but all callers are sending -1, so it doesn't yet have any effect. Since the requested MTU isn't necessarily what is used in the end (for example, if there is no MTU requested, the tap device will be set to the current MTU of the bridge), and the hypervisor may want to know the actual MTU used, we also return the actual MTU to the caller (if actualMTU is non-NULL).
-
由 Andrea Bolognani 提交于
In order for memory locking to work, the hard limit on memory locking (and usage) has to be set appropriately by the user. The documentation mentions the requirement already: with this patch, it's going to be enforced by runtime checks as well, by forbidding a non-compliant guest from being defined as well as edited and started. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1316774
-
- 07 2月, 2017 5 次提交
-
-
由 Roman Bogorodskiy 提交于
-
由 Roman Bogorodskiy 提交于
Like it usually happens, I fixed one thing and broke another: in 803966c7 address allocation was fixed for SATA disks, but broke that for virtio disks, because it dropped disk address assignment completely. It's not needed for SATA disks anymore, but still needed for the virtio ones. Bring that back and add a couple of tests to make sure it won't happen again.
-
由 Michal Privoznik 提交于
When working with symlinks it is fairly easy to get into a loop. Don't. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Similarly to one of the previous commits, we need to deal properly with symlinks in hotplug case too. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
When working with symlinks it is fairly easy to get into a loop. Don't. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-