- 07 4月, 2017 17 次提交
-
-
由 Jiri Denemark 提交于
So far only QEMU_MONITOR_MIGRATION_CAPS_POSTCOPY was reset, but only in a single code path leaving post-copy enabled in quite a few cases. https://bugzilla.redhat.com/show_bug.cgi?id=1425003Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
It's only called from qemuMigrationReset now so it doesn't need to be exported and {tls,sec}Alias are always NULL. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
This new API is supposed to reset all migration parameters to make sure future migrations won't accidentally use them. This patch makes the first step and moves qemuMigrationResetTLS call inside qemuMigrationReset. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Migration parameters are either reset by the main migration code path or from qemuProcessRecoverMigration* in case libvirtd is restarted during migration. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Finished qemuMigrationRun does not mean the migration itself finished (it might have just switched to post-copy mode). While resetting TLS parameters is probably OK at this point even if migration is still running, we want to consolidate the code which resets various migration parameters. Thus qemuMigrationResetTLS will be called from the Confirm phase (or at the end of the Perform phase in case of v2 protocol), when migration is either canceled or finished. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
qemuProcessRecoverMigrationOut doesn't explicitly call qemuMigrationResetTLS relying on two things: - qemuMigrationCancel resets TLS parameters - our migration code resets TLS before entering QEMU_MIGRATION_PHASE_PERFORM3_DONE phase But this is not obvious and the assumptions will be broken soon. Let's explicitly reset TLS parameters on all paths which do not kill the domain. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Let's use a bool variable to create a single shared path returning 0. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
There is no async job running when a freshly started libvirtd is trying to recover from an interrupted incoming migration. While at it, let's call qemuMigrationResetTLS every time we don't kill the domain. This is not strictly necessary since TLS is not supported when v2 migration protocol is used, but doing so makes more sense. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
This reverts commit 68507d77 which was pushed accidentally.
-
由 Jiri Denemark 提交于
This reverts commit dfc711dc which was pushed accidentally.
-
由 Jiri Denemark 提交于
This reverts commit 959e72d3 which was pushed accidentally.
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
This will allow us to drop feature filtering from virCPUUpdate where it was just a hack. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
We will need to store two more host CPU models and nested structs look better than separate items with long complicated names. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
The caller can ask for a migratable CPU model by passing true for the new parameter. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 06 4月, 2017 2 次提交
-
-
由 Jiri Denemark 提交于
qemuProcessVerifyHypervFeatures is supposed to check whether all requested hyperv features were actually honored by QEMU/KVM. This is done by checking the corresponding CPUID bits reported by the virtual CPU. In other words, it doesn't work for string properties, such as VIR_DOMAIN_HYPERV_VENDOR_ID (there is no CPUID bit we could check). We could theoretically check all 96 bits corresponding to the vendor string, but luckily we don't have to check the feature at all. If QEMU is too old to support hyperv features, the domain won't even start. Otherwise, it is always supported. Without this patch, libvirt refuses to start a domain which contains <features> <hyperv> <vendor_id state='on' value='...'/> </hyperv> </features> reporting internal error: "unknown CPU feature __kvm_hv_vendor_id. This regression was introduced by commit v3.1.0-186-ge9dbe701, which (by fixing the virCPUDataCheckFeature condition in qemuProcessVerifyHypervFeatures) revealed an old bug in the feature verification code. It's been there ever since the verification was implemented by commit v1.3.3-rc1-5-g95bbe4bf, which effectively did not check VIR_DOMAIN_HYPERV_VENDOR_ID at all. https://bugzilla.redhat.com/show_bug.cgi?id=1439424Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Andrea Bolognani 提交于
This header file has been created so that we can expose internal functions to the test suite without making them public: those in qemu_capabilities.h bearing the comment /* Only for use by test suite */ are obvious candidates for being moved over.
-
- 05 4月, 2017 4 次提交
-
-
由 Jiri Denemark 提交于
Jumping to "endjob" label from a code after this label is not a very good idea. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Peter Krempa 提交于
QEMU_CHECK_MONITOR_* already logs the object and vm name
-
由 John Ferlan 提交于
On any failure, call virJSONValueFree for the *Props. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Initialize stack variable to {0} Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 04 4月, 2017 6 次提交
-
-
由 Peter Krempa 提交于
Make sure that non-hotpluggable vcpus stay clustered at the beginning after modifying persistent definition. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1437010
-
由 Peter Krempa 提交于
Validate that users don't try to disable vcpu 0.
-
由 Peter Krempa 提交于
Vcpu order is required to stay sequential. Clear the order on cpu coldplug to avoid issues with removing vcpus out of sequence.
-
由 Peter Krempa 提交于
'next' is declared as 'ssize_t' so use '%zd'
-
由 Peter Krempa 提交于
Buggy condition meant that vcpu0 would not be iterated in the checks. Since it's not hotpluggable anyways we would not be able to break the configuration of a live VM. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1437013
-
由 Erik Skultety 提交于
Like all devices, add the 'id' option for mdevs as well. Patch also adjusts the test accordingly. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1438431Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
- 03 4月, 2017 6 次提交
-
-
由 Andrea Bolognani 提交于
Depending on the architecture, requirements for ACPI and UEFI can be different; more specifically, while on x86 UEFI requires ACPI, on aarch64 it's the other way around. Enforce these requirements when validating the domain, and make the error message more accurate by mentioning that they're not necessarily applicable to all architectures. Several aarch64 test cases had to be tweaked because they would have failed the validation step otherwise.
-
由 Andrea Bolognani 提交于
So far, libvirt has assumed that only x86 supports ACPI, but that's inaccurate since aarch64 supports it too. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1429509
-
由 Andrea Bolognani 提交于
The capabilities used in test cases should match those used during normal operation for the tests to make any sense. This results in the generated command line for a few test cases (most notably non-x86 test cases that were wrongly assuming they could use -no-acpi) changing.
-
由 Andrea Bolognani 提交于
Instead of having a single function that probes the architecture from the monitor and then sets a bunch of basic capabilities based on it, have a separate function for each part: virQEMUCapsInitQMPArch() only sets the architecture, and virQEMUCapsInitQMPBasicArch() only sets the capabilities. This split will be useful later on, when we will want to set basic capabilities from the test suite without having to go through the pain of mocking the monitor.
-
由 Michal Privoznik 提交于
Currently, if we want to zero out disk source (e,g, due to startupPolicy when starting up a domain) we use virDomainDiskSetSource(disk, NULL). This works well for file based storage (storage type file, dir, or block). But it doesn't work at all for other types like volume and network. So imagine that you have a domain that has a CDROM configured which source is a volume from an inactive pool. Because it is startupPolicy='optional', the CDROM is empty when the domain starts. However, the source element is not cleared out in the status XML and thus when the daemon restarts and tries to reconnect to the domain it refreshes the disks (which fails - the storage pool is still not running) and thus the domain is killed. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
So far our code is full of the following pattern: dom = virGetDomain(conn, name, uuid) if (dom) dom->id = 42; There is no reasong why it couldn't be just: dom = virGetDomain(conn, name, uuid, id); After all, client domain representation consists of tuple (name, uuid, id). Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 30 3月, 2017 4 次提交
-
-
由 Michal Privoznik 提交于
In 9e246583 a check that denies internal snapshots when pflash based loader is configured for the domain. However, if there's none and an user tries to do an internal snapshot they will witness daemon crash as in that case vm->def->os.loader is NULL and we dereference it unconditionally. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Jiri Denemark 提交于
CPU features which change their value from disabled to enabled between two calls to query-cpu-model-expansion (the first with no extra properties set and the second with 'migratable' property set to false) can be marked as enabled and non-migratable in qemuMonitorCPUModelInfo. Since the code consuming qemuMonitorCPUModelInfo currently ignores the migratable flag, this change is effectively changing the CPU model advertised in domain capabilities to contain all features (even those which block migration). And this matches what we do for QEMU older than 2.9.0, when we detect all CPUID bits ourselves without asking QEMU. As a result of this change <cpu mode='host-model'> <feature name='invtsc' policy='require'/> </cpu> will work with all QEMU versions. Such CPU definition would be forbidden with QEMU >= 2.9.0 without this patch. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
QEMU is able to tell us whether a CPU feature would block migration or not. This patch adds support for storing such features in qemuMonitorCPUModelInfo. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 29 3月, 2017 1 次提交
-
-
由 Peter Krempa 提交于
When idx is 0 virStorageFileChainLookup returns the base (bottom) of the backing chain rather than the top. This is expected by the callers of qemuDomainGetStorageSourceByDevstr. Add a special case for idx == 0
-