- 27 3月, 2017 6 次提交
-
-
由 Peter Krempa 提交于
-
由 Peter Krempa 提交于
Bind it to qemu's BLOCK_WRITE_THRESHOLD event. Look up the disk by nodename and construct the string to return.
-
由 Peter Krempa 提交于
The code is currently simple, but if we later add node names, it will be necessary to generate the names based on the node name. Add a helper so that there's a central point to fix once we add self-generated node names.
-
由 Peter Krempa 提交于
Looks up a disk and its corresponding backing chain element by node name.
-
由 Peter Krempa 提交于
The event is fired when a given block backend node (identified by the node name) experiences a write beyond the bound set via block-set-write-threshold QMP command. This wires up the monitor code to extract the data and allow us receiving the events and the capability.
-
由 Peter Krempa 提交于
Our code calls it when starting or re-starting the domain or when hotplugging the disk so there's nothing to be detected.
-
- 26 3月, 2017 1 次提交
-
-
由 Roman Bogorodskiy 提交于
qemuMigrationResetTLS() does not initialize 'ret' by default, so when it jumps to 'cleanup' on error, the 'ret' variable will be uninitialized, which clang complains about. Set it to '-1' by default.
-
- 25 3月, 2017 9 次提交
-
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1300769 If the migration flags indicate this migration will be using TLS, then while we have connection in the Begin phase check and setup the TLS environment that will be used by virMigrationRun during the Perform phase for the source to configure TLS. Processing adds an "-object tls-creds-x509,endpoint=client,..." and possibly an "-object secret,..." to handle the passphrase response. Then it sets the 'tls-creds' and possibly 'tls-hostname' migration parameters. The qemuMigrateCancel will clean up and reset the environment as it was originally found. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
If the migration flags indicate this migration will be using TLS, then set up the destination during the prepare phase once the target domain has been started to add the TLS objects to perform the migration. This will create at least an "-object tls-creds-x509,endpoint=server,..." for TLS credentials and potentially an "-object secret,..." to handle the passphrase response to access the TLS credentials. The alias/id used for the TLS objects will contain "libvirt_migrate". Once the objects are created, the code will set the "tls-creds" and "tls-hostname" migration parameters to signify usage of TLS. During the Finish phase we'll be sure to attempt to clear the migration parameters and delete those objects (whether or not they were created). We'll also perform the same reset during recovery if we've reached FINISH3. If the migration isn't using TLS, then be sure to check if the migration parameters exist and clear them if so.
-
由 John Ferlan 提交于
Add an asyncJob argument for add/delete TLS Objects. A future patch will add/delete TLS objects from a migration which may have a job to join. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Add the fields to support setting tls-creds and tls-hostname during a migration (either source or target). Modify the query migration function to check for the presence and set the field for future consumers to determine which of 3 conditions is being met (NULL, present and set to "", or present and sent to something). These correspond to qemu commit id '4af245dc3' which added support to default the value to "" and allow setting (or resetting) to "" in order to disable. This reset option allows libvirt to properly use the tls-creds and tls-hostname parameters. Modify code paths that either allocate or use stack space in order to call qemuMigrationParamsClear or qemuMigrationParamsFree for cleanup. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Update the descriptions to match the migrate option. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Add a new TLS X.509 certificate type - "migrate". This will handle the creation of a TLS certificate capability (and possibly repository) to be used for migrations. Similar to chardev's, credentials will be handled via a libvirt secrets; however, unlike chardev's enablement and usage will be via a CLI flag instead of a conf flag and a domain XML attribute. The migrations using the *x509_verify flag require the client-cert.pem and client-key.pem files to be present in the TLS directory - so let's also be sure to note that in the qemu.conf file. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Create GET_CONFIG_TLS_CERT to set up the TLS for 'chardev' TLS setting. Soon to be reused. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 24 3月, 2017 2 次提交
-
-
由 Peter Krempa 提交于
If the variable store (<nvram>) file is raw qemu can't do a snapshot of it and thus the snapshot fails. QEMU rejects such snapshot by a message which would not be properly interpreted as an error by libvirt. Additionally allowing to use a qcow2 variable store backing file would solve this issue but then it would become eligible to become target of the memory dump. Offline internal snapshot would be incomplete too with either storage format since libvirt does not handle the pflash file in this case. Forbid such snapshot so that we can avoid problems.
-
由 Ján Tomko 提交于
This reverts commit b7118623. Migration was implemented by QEMU commit: commit 8cdcf3c1e58d04b6811956d7608efeb66c42d719 Author: Peter Xu <peterx@redhat.com> Date: Fri Jan 6 12:06:13 2017 +0800 intel_iommu: allow migration https://bugzilla.redhat.com/show_bug.cgi?id=1433994
-
- 23 3月, 2017 5 次提交
-
-
-
由 Andrea Bolognani 提交于
-
由 John Ferlan 提交于
The 'mon' argument validity is checked in the QEMU_CHECK_MONITOR for the following functions, so they don't need the NONNULL on their prototype: qemuMonitorUpdateVideoMemorySize qemuMonitorUpdateVideoVram64Size qemuMonitorGetAllBlockStatsInfo qemuMonitorBlockStatsUpdateCapacity Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
The prototype requires not passing a NULL in the parameter and the callers all would fail far before this code would fail if 'vm' was NULL, so just remove the check. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
The qemuDomainSnapshotPrepare should always set a > 0 format value anyway, so remove the check. Found by Coverity.
-
- 22 3月, 2017 1 次提交
-
-
由 John Ferlan 提交于
Commit id '85af0b80' added a 'timeout' as the 4th parameter to qemuMonitorOpen, but neglected to update the ATTRIBUTE_NONNULL(4) to be (5) for the cb parameter.
-
- 21 3月, 2017 1 次提交
-
-
由 Chen Hanxiao 提交于
We reported error in caller virQEMUCapsCacheLookupByArch. So the same error messages in qemuConnectGetDomainCapabilities is useless. Signed-off-by: NChen Hanxiao <chenhanxiao@gmail.com>
-
- 20 3月, 2017 1 次提交
-
-
由 Jiri Denemark 提交于
Calling virCPUUpdateLive on a domain with no guest CPU configuration does not make sense. Especially when doing so would crash libvirtd. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 17 3月, 2017 14 次提交
-
-
由 Jiri Denemark 提交于
When starting a domain with custom guest CPU specification QEMU may add or remove some CPU features. There are several reasons for this, e.g., QEMU/KVM does not support some requested features or the definition of the requested CPU model in libvirt's cpu_map.xml differs from the one QEMU is using. We can't really avoid this because CPU models are allowed to change with machine types and libvirt doesn't know (and probably doesn't even want to know) about such changes. Thus when we want to make sure guest ABI doesn't change when a domain gets migrated to another host, we need to update our live CPU definition according to the CPU QEMU created. Once updated, we will change CPU checking to VIR_CPU_CHECK_FULL to make sure the virtual CPU created after migration exactly matches the one on the source. https://bugzilla.redhat.com/show_bug.cgi?id=822148 https://bugzilla.redhat.com/show_bug.cgi?id=824989Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
qemuMonitorGetGuestCPU can now optionally create CPU data from filtered-features in addition to feature-words. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
The checks are now in a dedicated qemuProcessVerifyCPUFeatures function. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
The checks are now in a dedicated qemuProcessVerifyKVMFeatures function. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
The checks are now in a dedicated qemuProcessVerifyHypervFeatures function. In addition to moving the code this patch also fixes a few bugs: the original code was leaking cpuFeature and the return value of virCPUDataCheckFeature was not checked properly. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Peter Krempa 提交于
The disk tuning group parameter is ignored by qemu if no other throttling options are set. Reject such configuration, since the name would not be honored after setting parameters via the live tuning API. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1433180
-
由 Peter Krempa 提交于
When checking capabilities for qemu we need to check whether subsets of the disk throttling settings are supported. Extract the checks into a separate functions as they will be reused in next patch.
-
由 Peter Krempa 提交于
qemuBuildDriveStr grew into 'megamoth' proportions. Cut out some parts.
-
由 Peter Krempa 提交于
While the code path that queries the monitor allocates a separate copy of the 'group_name' string the path querying the config would not copy it. The call to virTypedParameterAssign would then steal the pointer (without clearing it) and the RPC layer freed it. Any subsequent call resulted into a crash. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1433183
-
由 Guido Günther 提交于
This unbreaks emulators that don't support this command such as qemu-system-mips*. Reference: http://bugs.debian.org/854125
-
由 Andrea Bolognani 提交于
ioh3420 is emulated Intel hardware, so it always looked quite out of place in aarch64/virt guests. Even for x86/q35 guests, the recently-introduced pcie-root-port is a better choice because, unlike ioh3420, it doesn't require IO space (a fairly constrained resource) to work. If pcie-root-port is available in QEMU, use it; ioh3420 is still used as fallback for when pcie-root-port is not available. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1408808
-