- 26 8月, 2016 5 次提交
-
-
由 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 提交于
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
-
由 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 19 次提交
-
-
由 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 提交于
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.
-
- 22 8月, 2016 1 次提交
-
-
由 JieWang 提交于
remove the dead code this patch is to remove the dead code Signed-off-by: JieWang <wangjie88@huawei.com> Signed-off-by: NJieWang <wangjie88@huawei.com>
-
- 18 8月, 2016 1 次提交
-
-
由 Ján Tomko 提交于
Check whether the disable-legacy property is present on the following devices: virtio-balloon-pci virtio-blk-pci virtio-scsi-pci virtio-serial-pci virtio-9p-pci virtio-net-pci virtio-rng-pci virtio-gpu-pci virtio-input-host-pci virtio-keyboard-pci virtio-mouse-pci virtio-tablet-pci Assuming that if QEMU knows other virtio devices where this property is applicable, it will have at least one of these devices. Added in QEMU by: commit e266d421490e0ae83044bbebb209b2d3650c0ba6 virtio-pci: add flags to enable/disable legacy/modern
-
- 17 8月, 2016 8 次提交
-
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1182074 Since libvirt still uses a legacy qemu arg format to add a disk, the manner in which the 'password-secret' argument is passed to qemu needs to change to prepend a 'file.' If in the future, usage of the more modern disk format, then the prepended 'file.' can be removed. Fix based on Jim Fehlig <jfehlig@suse.com> posting and subsequent upstream list followups, see: http://www.redhat.com/archives/libvir-list/2016-August/msg00777.html for details. Introduced by commit id 'a1344f70'.
-
由 Chen Hanxiao 提交于
s/libvirt.c/libvirt-domain.c Signed-off-by: NChen Hanxiao <chenhanxiao@gmail.com>
-
由 Pavel Hrdina 提交于
The code that setups listen types may change a listen type from address to socket based on configuration from qemu.conf. This needs to be done before we reserve/allocate ports that won't be used. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1364843Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Ports are valid only for listen types 'address' and 'network', other listen types doesn't use them so we should not try to reserve any ports. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Signed-off-by: Pavel Hrdina <phrdina@redhat.com
-
由 Andrea Bolognani 提交于
The first argument should be const char ** instead of char **, because this is a search function and as such it doesn't, and shouldn't, alter the haystack in any way. This change means we no longer have to cast arrays of immutable strings to arrays of mutable strings; we still have to do the opposite, though, but that's reasonable.
-
- 16 8月, 2016 4 次提交
-
-
由 Peter Krempa 提交于
All other modes of qemuDomainSetVcpusFlags have helpers so finish the work by splitting the regular code into a new function. This patch also touches up the coding (spacing) style.
-
由 Peter Krempa 提交于
The live code does ugly things. Contain it in a separate function.
-
由 Peter Krempa 提交于
Setting of the maximum vcpu count is slightly semantically different thus split it into a self-contained func.
-
由 Peter Krempa 提交于
Mention whether it was the live or persistent definition which caused an error reported and explicitly error out in case when attempting to set maximum vcpu count for a live domain.
-
- 15 8月, 2016 1 次提交
-
-
由 Pavel Hrdina 提交于
Setting heads to 0 in case that *max_outputs* is not supported while building command line doesn't have any real effect. It only removes *heads* attribute from live XML, but after restarting libvirt the default value is restored. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
- 12 8月, 2016 1 次提交
-
-
由 Andrea Bolognani 提交于
Since we now pick the default USB controller model when parsing the guest XML, we can get rid of some duplicated code so that the default model selection happens in one place only. Add some comments as well.
-