Setting up the 'secinfo' for the TLS private key password also generates
the given alias, so we don't need to generate another one.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The alias of the secret for decrypting the TLS passphrase is useless
besides for TLS setup. Stop passing it around.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We make sure that the disk supports TLS when preparing the environment
so there's no need to duplicate checks.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Callers need to know the alias anyways so it does not make much sense to
generate it inside of this function.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
qemuBuildTLSx509CommandLine has no business guessing which alias should
be used. The alias needs to be passed in.
Note that there's a lingering bad design of this, since the secret
object alias is based on the device name and not on the fact that the
secret is used for decrypting of the TLS private key. If we ever add
authentication for chardevs this will bite us.
Thankfully disk code does not support encrypted private keys for TLS so
it can be happily refactored there.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Move the TLS object alias setup earlier. Also make sure that the alias
is not overwritten on hotplug.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
For some reason the function returned an error if secAlias was not
passed in. It's not an error, in fact it's desired.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Select protocol using a switch with all cases enumerated. This will
simplify checking unsupported protocols and adding new support.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Remove the loop from qemuDomainPrepareDiskSourceTLS and rename it to
qemuDomainPrepareStorageSourceTLS. Currently there is no backing chain
to prepare so fixing one device is equivalent. In the future it will be
reused in a function which will do the looping.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Split out the code into a separate function so that all steps for a
storage protocol are contained and the original function is easily
extendable.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When using blockdev the approach to base aliases will change. Add a
helper function that will aggregate all code which needs to be called
with the disk alias for the -drive to setup internal data.
qemuDomainSecretDiskPrepare wrapper is no longer necessary as the
contents were moved to a function which is designed to use the old
aliases.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Remove the call to the validating function from the function which sets
stuff up.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Convert the function to just prepare data for the disk. Callers need to
do the looping since there's more to do than just copy the data around.
The code path in qemuDomainPrepareDiskSource doesn't need to loop over
the chain yet, since there currently is no chain at this point. This
will be addressed later in the blockdev series where we will setup much
more stuff.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
qemuDomainPrepareDiskSourceChain should set up the disk zero detection
mode only for the top level image. Since it's invoked also for the
middle of the chain we need to check that it's really only the top level
image.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When restarting libvirt would previously lose the alias of the x509
certificate object. Upon unplug we would then not delete the
corresponding objects.
Restore the alias if we know it should be there.
Luckily for disks we don't support encrypted TLS environment, so there's
no need to regenerate the 'secret' alias for decryption.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Libvirt uses the stored alias to detach the TLS x509 object on disk
unplug. As the alias was not stored, the object would not be detached
if unplugging disks after libvirtd restart.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Using 'haveTLS' to do this is pointless if the alias is not set.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Now that we remember the alias we've used to attach the secret objects
we should reuse them rather than trying to infer them from the disk
configuration.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Previously we did not store the aliases but rather re-generated them
when unplug was necessary. This is very cumbersome since the knowledge
when and which alias to use needs to be stored in the hotplug code as
well.
While this patch will not strictly improve this situation since there
still will be two places containing this code it at least will allow to
remove the mess from the disk-unplug code and will prevent introducing
more mess when adding blockdev support.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Rather than trying to figure out which alias was used, store it in the
status XML.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We need to reference the secret objects by name when hot-unplugging
disks. Don't remove the alias so that it does not need to be
recalculated.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
It's desired to keep the alias around to allow referencing of the secret
object used with qemu. Add set of APIs which will destroy all data
except the alias.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Move the logic that determines which secret shall be used into the
caller and make this function work only for plain secrets.
This untangles the control flow by only checking relevant data.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The encryption secret is setup only for LUKS and thus requires the new
approach. Use qemuDomainSecretInfoNew for initializing it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Some code paths can't use the unencrypted secret. Add a helper which
checks and sets up an encrypted secret only and reuse it when setting up
the secret to decrypt the TLS private key in qemuDomainSecretInfoTLSNew.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Rename it to qemuDomainSecretInfoNewPlain and annotate that it also may
set up a 'plain' secret in some cases. This will eventually be
refactored further.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The function checks whether the storage source requires authentication
secret setup. Rename it accordingly.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use qemuDomainSecretStorageSourcePrepare in
qemuDomainSecretHostdevPrepare as it uses a virStorageSource to prepare
the authentication secret object data.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This helper checks that the vm has the master key setup and libvirt
supports the given encryption algorithm.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Alter qemuBuildVsockDevStr to allow passing a prefix for
the vhostfd file descriptor name. Domain startup uses
the numeric value of fd without a prefix, but hotplug
will need to use a prefix because passed file descriptor
names cannot start with a number.
https://bugzilla.redhat.com/show_bug.cgi?id=1291851
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Split out the device string building to allow reuse for hotplug.
https://bugzilla.redhat.com/show_bug.cgi?id=1291851
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
My commit b8b42ca added support for formatting the vsock
command line without actually checking if it's supported.
Add it to the per-device validation function.
https://bugzilla.redhat.com/show_bug.cgi?id=1291851
Reported-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
This has been broken since commit v4.0.0-165-g93412bb827 which added
jobInfo->statsType enum to distinguish various statistics types. During
migration the type will always be QEMU_DOMAIN_JOB_STATS_TYPE_MIGRATION,
however the destination code consuming the statistics data from
migration cookie failed to properly set the type. So even though
everything was filled in, the type remained *_NONE and any attempt to
fetch the statistics data of a completed migration on the destination
host failed.
https://bugzilla.redhat.com/show_bug.cgi?id=1584071
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
In commit 8bebb2b735 I've refactored how the detach of disk with a
managed persistent reservations object is handled. After the commit if
any disk with a managed PR object would be removed libvirt would also
attempt to remove the shared 'pr-manager-helper' object potentially used
by other disks.
Thankfully this should not have practical impact as qemu should reject
deletion of the object if it was still used and the rest of the code is
correct.
Fix this by removing the disk from the definition earlier and checking
if the shared/managed pr-manager-helper object is still needed.
This basically splits the detach code for the managed PR object from the
unmanaged ones. The same separation will follow for the attachment code
as well as it greatly simplifies -blockdev support for this.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
When preparing qemuCaps for test cases the following is
happening:
qemuTestParseCapabilitiesArch() is called, which calls
virQEMUCapsLoadCache() which in turn calls
virQEMUCapsInitHostCPUModel() which sets qemuCaps->kvmCPU and
qemuCaps->tcgCPU.
But then the code tries to update the capabilities:
testCompareXMLToArgv() calls testUpdateQEMUCaps() which calls
virQEMUCapsInitHostCPUModel() again overwriting previously
allocated memory. The solution is to free host cpuData in
testUpdateQEMUCaps().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
We allocate a temporary bitmap but never free it.
Introduced by <commit 1f8a1a9>:
qemu: Do not use qemuMonitorSetMigrationCapability
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Create a new vsock endpoint by opening /dev/vhost-vsock,
set the requested CID via ioctl (or assign a free one if auto='yes'),
pass the file descriptor to QEMU and build the command line.
https://bugzilla.redhat.com/show_bug.cgi?id=1291851
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Add a new 'vsock' element for the vsock device.
The 'model' attribute is optional.
A <source cid> subelement should be used to specify the guest cid,
or <source auto='yes'/> should be used.
https://bugzilla.redhat.com/show_bug.cgi?id=1291851
Signed-off-by: Ján Tomko <jtomko@redhat.com>
When status XML was parsed the post-parse callbacks could not access
qemu caps and potentially upgrade the definition according to the
present caps. Implement the callback to pass it in.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Trying to set any cache for <disk device='lun'/> makes no sense.
Such disk translates into -device scsi-block on the command line
and the device lacks any cache setting because it's merely a
middle man between qemu and real SCSI device.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
The function creates a list of all (or migratable only) CPU features
supported by QEMU. It works by looking at the CPU model info returned by
query-cpu-model-expansion QMP command.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Collin Walling <walling@linux.ibm.com>
When computing a baseline CPU for a specific hypervisor we have to make
sure to include only CPU features supported by the hypervisor. Otherwise
the computed CPU could not be used for starting a new domain.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Collin Walling <walling@linux.ibm.com>
