- 27 8月, 2016 2 次提交
-
-
由 Kothapally Madhu Pavan 提交于
Unlike postcopy migration there is no --live flag check for postcopy-after-precopy. Signed-off-by: NKothapally Madhu Pavan <kmp@linux.vnet.ibm.com>
-
由 Christophe Fergeau 提交于
The iothread example for virtio-scsi should be <driver iothread='4'/> rather than <driver iothread='4'> for the XML to be valid.
-
- 26 8月, 2016 14 次提交
-
-
由 Peter Krempa 提交于
../../src/conf/domain_conf.c:4425:21: error: potential null pointer dereference [-Werror=null-dereference] switch (vcpu->hotpluggable) { ~~~~^~~~~~~~~~~~~~
-
由 Peter Krempa 提交于
Setting vcpu count when cpu topology is specified may result into an invalid configuration. Since the topology can't be modified, reject the setting if it doesn't match the requested topology. This will allow fixing the topology in case it was broken. Partially fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1370066
-
由 Peter Krempa 提交于
Validating the vcpu count is more intricate and doing it in the XML parser will make previously valid configs (with older qemus) vanish. Now that we have a very similar check in the qemu domain validation callback we can do it in a more appropriate place. This basically reverts commit b54de083. Partially resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1370066
-
由 Peter Krempa 提交于
Make it clear that vcpu order is valid for online vcpus only and state that it has to be specified for all vcpus or not provided at all. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1370043
-
由 Peter Krempa 提交于
ce43cca0 refactored the helper to prepare it for sparse topologies but forgot to fix the iterator used to fill the structures. This would result into a weirdly sparse populated array and possible out of bounds access and crash once sparse vcpu topologies were allowed. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1369988
-
由 Peter Krempa 提交于
virVcpuInfo contains the vcpu number that the data refers to. Report what's returned by the daemon rather than the sequence number as with sparse vcpu topologies they won't match.
-
由 Mikhail Feoktistov 提交于
We should query bus type for containers too, like for VM. In openstack we add volume disk like SCSI, so we can't hardcode SATA bus.
-
由 Nikolay Shirokovskiy 提交于
-
由 Olga Krishtal 提交于
While dettaching/attaching device in OpenStack, nova calls vzDomainDettachDevice twice, because the update of the internal configuration of the ct comes a bit latter than the update event. As the result, we suffer from the second call to dettach the same device. Signed-off-by: NOlga Krishtal <okrishtal@virtuozzo.com>
-
由 Pavel Glushchak 提交于
libvirt-python passes parameter bandwidth = 0 by default. This means that bandwidth is unlimited. VZ driver doesn't support bandwidth rate limiting, but we still need to handle it and fail if bandwidth > 0. Signed-off-by: NPavel Glushchak <pglushchak@virtuozzo.com>
-
由 Pavel Glushchak 提交于
* Added VIR_MIGRATE_LIVE, VIR_MIGRATE_UNDEFINE_SOURCE and VIR_MIGRATE_PERSIST_DEST to supported migration flags Signed-off-by: NPavel Glushchak <pglushchak@virtuozzo.com>
-
由 Laine Stump 提交于
When support for auto-creating tap devices was added to <interface type='ethernet'> in commit 9c17d6, the code assumed that virNetDevTapCreate() would honor the VIR_NETDEV_TAP__CREATE_IFUP flag that is supported by virNetDevTapCreateInBridgePort(). That isn't the case - the latter function performs several operations, and one of them is setting the tap device online. But virNetDevTapCreate() *only* creates the tap device, and relies on the caller to do everything else, so qemuInterfaceEthernetConnect() needs to call virNetDevSetOnline() after the device is successfully created.
-
由 Laine Stump 提交于
The linkstate setting of an <interface> is only meant to change the online status reported to the guest system by the emulated network device driver in qemu, but when support for auto-creating tap devices for <interface type='ethernet'> was added in commit 9717d6, a chunk of code was also added to qemuDomainChangeNetLinkState() that sets the online status of the tap device (i.e. the *host* side of the interface) for type='ethernet'. This was never done for tap devices used in type='bridge' or type='network' interfaces, nor was it done in the past for tap devices created by external scripts for type='ethernet', so we shouldn't be doing it now. This patch removes the bit of code in qemuDomainChangeNetLinkState() that modifies online status of the tap device.
-
由 Vasiliy Tolstov 提交于
The call to virNetDevIPInfoAddToDev() that sets up tap device IP addresses and routes was somehow incorrectly placed in qemuInterfaceStopDevice() instead of qemuInterfaceStartDevice() in commit fe8567f6. This fixes that error by moving the call to virNetDevIPInfoAddToDev() to qemuInterfaceStartDevice(). Signed-off-by: NVasiliy Tolstov <v.tolstov@selfip.ru>
-
- 25 8月, 2016 24 次提交
-
-
由 Peter Krempa 提交于
This patch removes the old vcpu unplug code completely and replaces it with the new code using device_del. The old hotplug code basically never worked with any recent qemu and thus is useless. As the new code is using device_del all the implications of using it are present. Contrary to the device deletion code, the vcpu deletion code fails if the unplug request is not executed in time.
-
由 Peter Krempa 提交于
Add a overlay function that takes the alias directly rather than extracting it from a device info.
-
由 Peter Krempa 提交于
To allow unplugging the vcpus, hotplugging of vcpus on platforms which require to plug multiple logical vcpus at once or plugging them in an arbitrary order it's necessary to use the new device_add interface for vcpu hotplug. This patch adds support for the device_add interface using the old setvcpus API by implementing an algorithm to select the appropriate entities to plug in.
-
由 Peter Krempa 提交于
Add support for using the new approach to hotplug vcpus using device_add during startup of qemu to allow sparse vcpu topologies. There are a few limitations imposed by qemu on the supported configuration: - vcpu0 needs to be always present and not hotpluggable - non-hotpluggable cpus need to be ordered at the beginning - order of the vcpus needs to be unique for every single hotpluggable entity Qemu also doesn't really allow to query the information necessary to start a VM with the vcpus directly on the commandline. Fortunately they can be hotplugged during startup. The new hotplug code uses the following approach: - non-hotpluggable vcpus are counted and put to the -smp option - qemu is started - qemu is queried for the necessary information - the configuration is checked - the hotpluggable vcpus are hotplugged - vcpus are started This patch adds a lot of checking code and enables the support to specify the individual vcpu element with qemu.
-
由 Peter Krempa 提交于
The vcpu order information is extracted only for hotpluggable entities, while vcpu definitions belonging to the same hotpluggable entity need to all share the order information. We also can't overwrite it right away in the vcpu info detection code as the order is necessary to add the hotpluggable vcpus enabled on boot in the correct order. The helper will store the order information in places where we are certain that it's necessary.
-
由 Peter Krempa 提交于
For use on the monitor we need to format certain parts of the vcpu private definition into a JSON object. Add a helper.
-
由 Peter Krempa 提交于
Introduce a new migration cookie flag that will be used for any configurations that are not compatible with libvirt that would not support the specific vcpu hotplug approach. This will make sure that old libvirt does not fail to reproduce the configuration correctly.
-
由 Peter Krempa 提交于
Individual vCPU hotplug requires us to track the state of any vCPU. To allow this add the following XML: <domain> ... <vcpu current='2'>3</vcpu> <vcpus> <vcpu id='0' enabled='yes' hotpluggable='no' order='1'/> <vcpu id='1' enabled='yes' hotpluggable='yes' order='2'/> <vcpu id='1' enabled='no' hotpluggable='yes'/> </vcpus> ... The 'enabled' attribute allows to control the state of the vcpu. 'hotpluggable' controls whether given vcpu can be hotplugged and 'order' allows to specify the order to add the vcpus.
-
由 Peter Krempa 提交于
-
由 Peter Krempa 提交于
Similarly to devices the guest may allow unplug of the VCPU if libvirt is down. To avoid problems, refresh the vcpu state on reconnect. Don't mess with the vcpu state otherwise.
-
由 Peter Krempa 提交于
Now that the monitor code gathers all the data we can extract it to relevant places either in the definition or the private data of a vcpu. As only thread id is broken for TCG guests we may extract the rest of the data and just skip assigning of the thread id. In case where qemu would allow cpu hotplug in TCG mode this will make it work eventually.
-
由 Peter Krempa 提交于
The reported data is unusual so add it to the test suite.
-
由 Peter Krempa 提交于
Test the algorithm that extracts the order in which the vcpu entries were plugged in on a sample of data created by plugging in vcpus arbitrarily.
-
由 Peter Krempa 提交于
Power 8 platform's basic hotpluggable unit is a core rather than a thread for x86_64 family. This introduces most of the complexity of the matching code and thus needs to be tested. The test data contain data captured from in-order cpu hotplug and unplug operations.
-
由 Peter Krempa 提交于
During review it was reported that adding at least 11 vcpus creates a collision of prefixes in the monitor matching algorithm. Add a test case to verify that the problem won't happen.
-
由 Peter Krempa 提交于
As the combination algorithm is rather complex and ugly it's necessary to make sure it works properly. Add test suite infrastructure for testing it along with a basic test based on x86_64 platform.
-
由 Peter Krempa 提交于
For hotplug purposes it's necessary to retrieve data using query-hotpluggable-cpus while the old query-cpus API report thread IDs and order of hotplug. This patch adds code that merges the data using a rather non-trivial algorithm and fills the data to the qemuMonitorCPUInfo structure for adding to appropriate place in the domain definition.
-
由 Peter Krempa 提交于
Add support for retrieving information regarding hotpluggable cpu units supported by qemu. Data returned by the command carries information needed to figure out the granularity of hotplug, the necessary cpu type name and the topology information. Note that qemu doesn't specify any particular order of the entries thus it's necessary sort them by socket_id, core_id and thread_id to the order libvirt expects.
-
由 Peter Krempa 提交于
To allow matching up the data returned by query-cpus to entries in the query-hotpluggable-cpus reply for CPU hotplug it's necessary to extract the QOM path as it's the only link between the two.
-
由 Peter Krempa 提交于
QEMU reports whether 'query-hotpluggable-cpus' is supported for a given machine type. Extract and cache the information using the capability cache. When copying the capabilities for a new start of qemu, mask out the presence of QEMU_CAPS_QUERY_HOTPLUGGABLE_CPUS if the machine type doesn't support hotpluggable cpus.
-
由 Peter Krempa 提交于
As of qemu commit: commit a32ef3bfc12c8d0588f43f74dcc5280885bbdb30 Author: Thomas Huth <thuth@redhat.com> Date: Wed Jul 22 15:59:50 2015 +0200 vl: Add another sanity check to smp_parse() function v2.4.0-952-ga32ef3b configuration where the maximum CPU count doesn't match the topology is rejected. Prior to that only configurations where the topology would contain more cpus than the maximum count would be rejected. Use QEMU_CAPS_QUERY_HOTPLUGGABLE_CPUS as a relevant recent enough witness to avoid breaking old configs.
-
由 Peter Krempa 提交于
-
由 Peter Krempa 提交于
Prepare to extract more data by returning an array of structs rather than just an array of thread ids. Additionally report fatal errors separately from qemu not being able to produce data.
-
由 Peter Krempa 提交于
The function will gradually add more returned data. Return a struct for every vCPU containing the data.
-