Now that various new API have been added or are coming soon, it is
worth a landing page that gives an overview of capturing various
pieces of guest state, and which APIs are best suited to which tasks.
Signed-off-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Introduce a bunch of new public APIs related to backup checkpoints.
Checkpoints are modeled heavily after virDomainSnapshotPtr (both
represent a point in time of the guest), although a snapshot exists
with the intent of rolling back to that state, while a checkpoint
exists to make it possible to create an incremental backup at a later
time.  We may have a future hypervisor that can completely manage
checkpoints without libvirt metadata, but the first two planned
hypervisors (qemu and test) both always use libvirt for tracking
metadata relations between checkpoints, so for now, I've deferred
the counterpart of virDomainSnapshotHasMetadata for a separate
API addition at a later date if there is ever a need for it.

Note that until we allow snapshots and checkpoints to exist
simultaneously on the same domain (although the actual prevention of
this will be in a separate patch for the sake of an easier revert down
the road), that it is not possible to branch out to create more than
one checkpoint child to a given parent, although it may become
possible later when we revert to a snapshot that coincides with a
checkpoint.  This also means that for now, the decision of which
checkpoint becomes the parent of a newly created one is the only
checkpoint with no child (so while there are APIs for dealing with a
current snapshot, we do not need those for checkpoints).  We may end
up exposing a notion of a current checkpoint later, but it's easier to
add stuff when proven needed than to blindly support it now and wish
we hadn't exposed it.

The following map shows the API relations to snapshots, with new APIs
on the right:

Operate on a domain object to create/redefine a child:
virDomainSnapshotCreateXML          virDomainCheckpointCreateXML

Operate on a child object for lifetime management:
virDomainSnapshotDelete             virDomainCheckpointDelete
virDomainSnapshotFree               virDomainCheckpointFree
virDomainSnapshotRef                virDomainCheckpointRef

Operate on a child object to learn more about it:
virDomainSnapshotGetXMLDesc         virDomainCheckpointGetXMLDesc
virDomainSnapshotGetConnect         virDomainCheckpointGetConnect
virDomainSnapshotGetDomain          virDomainCheckpointGetDomain
virDomainSnapshotGetName            virDomainCheckpiontGetName
virDomainSnapshotGetParent          virDomainCheckpiontGetParent
virDomainSnapshotHasMetadata        (deferred for later)
virDomainSnapshotIsCurrent          (no counterpart, see note above)

Operate on a domain object to list all children:
virDomainSnapshotNum                (no counterparts, these are the old
virDomainSnapshotListNames           racy interfaces)
virDomainSnapshotListAllSnapshots   virDomainListAllCheckpoints

Operate on a child object to list descendents:
virDomainSnapshotNumChildren        (no counterparts, these are the old
virDomainSnapshotListChildrenNames   racy interfaces)
virDomainSnapshotListAllChildren    virDomainCheckpointListAllChildren

Operate on a domain to locate a particular child:
virDomainSnapshotLookupByName       virDomainCheckpointLookupByName
virDomainSnapshotCurrent            (no counterpart, see note above)
virDomainHasCurrentSnapshot         (no counterpart, old racy interface)

Operate on a snapshot to roll back to earlier state:
virDomainSnapshotRevert             (no counterpart, instead checkpoints
                                     are used in incremental backups via
				     XML to virDomainBackupBegin)
Signed-off-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Prepare for new checkpoint APIs by describing the XML that will
represent a checkpoint.  The checkpoint XML is modeled heavily after
virDomainSnapshotPtr. See the docs for more details.

Add testsuite coverage for some minimal uses of the XML (bare minimum,
the sample from html, and a full dumpxml, and some counter-examples
that should fail schema validation). Although use of the REDEFINE flag
will require the <domain> subelement to be present, it is easier for
most of the tests to provide counterpart output produced with the
NO_DOMAIN flag (particularly since synthesizing a valid <domain>
during testing is not trivial).
Signed-off-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

If we are using -blockdev, then node names are always available
(because we set them).  But when not using it, we have to scrape node
names from QMP, and want to do so as infrequently as possible.  We
were scraping node names after reconnecting a new libvirtd to an
existing guest (see qemuProcessReconnect), and after any block job
that may have changed the set of node names we care about (legacy
block jobs), but forgot to scrape the names when first starting a
guest.  Do so now in order to allow the checkpoint code to always have
access to a node name without having to repeat a node name scrape
itself.

Future patches may need to clean up qemuDomainSetBlockThreshold (if
node names are always available, then it doesn't need to repeat a
scrape) and/or hotplug and media changes (if the addition of new nodes
can result in a null node name, then scraping at that point in time
would be appropriate).  But for now, this patch addresses only the
most common instance of a missing node name.
Signed-off-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Since we are checking the 2nd parameter in the function for NULL,
we need to remove ATTRIBUTE_NONNULL(2) from the prototype.
Signed-off-by: NStefan Berger <stefanb@linux.ibm.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Message-Id: <20190726205633.2041912-5-stefanb@linux.vnet.ibm.com>

Remove the ATTRIBUTE_NONNULL(1) from virCommandSetSendBuffer()
prototype since we are checking for '!cmd' and move the initialization
if 'i' after the test for '!cmd'.
Signed-off-by: NStefan Berger <stefanb@linux.ibm.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Message-Id: <20190726205633.2041912-4-stefanb@linux.vnet.ibm.com>

Fix a potential memory leak by calling virCommandFree() in the cleanup
section.
Signed-off-by: NStefan Berger <stefanb@linux.ibm.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Message-Id: <20190726205633.2041912-3-stefanb@linux.vnet.ibm.com>

Use the existing variables rather then calling virTPMSwtpmXYZ().
Signed-off-by: NStefan Berger <stefanb@linux.ibm.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Message-Id: <20190726205633.2041912-2-stefanb@linux.vnet.ibm.com>

Create an empty log file if the log file was removed, otherwise the
transaction to set the security labels on the file will fail.
Signed-off-by: NStefan Berger <stefanb@linux.ibm.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Message-Id: <20190726210706.24440-3-stefanb@linux.ibm.com>

Set the transactionStarted to false if the commit failed. If this is not
done, then the failure path will report 'no transaction is set' and hide
more useful error reports.
Signed-off-by: NStefan Berger <stefanb@linux.ibm.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Message-Id: <20190726210706.24440-2-stefanb@linux.ibm.com>

Creating an 'exp' output file, but never comparing it against the
actual output, does not actually constitute testing the output. :)

Fixes: 280a2b41Signed-off-by: NEric Blake <eblake@redhat.com>

Starting with QEMU 4.1 qemuMonitorCPUModelInfo structure in virQEMUCaps
stores only canonical feature names which may differ from the name used
by libvirt. We need translate these canonical names into libvirt names
for further consumption.

This fixes a bug in qemuConnectBaselineHypervisorCPU which would remove
all features for which libvirt's spelling differs from the QEMU's
preferred name. For example, the following result of
qemuConnectBaselineHypervisorCPU on my host with QEMU 4.1 is wrong:

    <cpu mode='custom' match='exact'>
      <model fallback='forbid'>Skylake-Client</model>
      <vendor>Intel</vendor>
      <feature policy='require' name='ss'/>
      <feature policy='require' name='vmx'/>
      <feature policy='require' name='hypervisor'/>
      <feature policy='require' name='clflushopt'/>
      <feature policy='require' name='umip'/>
      <feature policy='require' name='arch-capabilities'/>
      <feature policy='require' name='xsaves'/>
      <feature policy='require' name='pdpe1gb'/>
      <feature policy='require' name='invtsc'/>
      <feature policy='disable' name='pclmuldq'/>
      <feature policy='disable' name='lahf_lm'/>
    </cpu>

The 'pclmuldq' and 'lahf_lm' should not be disabled in the baseline CPU
as they are supported by QEMU on this host.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Signed-off-by: NIlias Stamatis <stamatis.iliass@gmail.com>

Signed-off-by: NIlias Stamatis <stamatis.iliass@gmail.com>

Describe the encryption element in the TPM's domain XML.
Signed-off-by: NStefan Berger <stefanb@linux.ibm.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Extend the Secret XML documentation with vtpm usage type.
Signed-off-by: NStefan Berger <stefanb@linux.ibm.com>
Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Since swtpm does not support getting started without password
once it was created with encryption enabled, we don't allow
encryption to be removed. Similarly, we do not allow encryption
to be added once swtpm has run. We also prevent chaning the type
of the TPM backend since the encrypted state is still around and
the next time one was to switch back to the emulator backend
and forgot the encryption the TPM would not work.
Signed-off-by: NStefan Berger <stefanb@linux.ibm.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

This patch now passes the passphrase as a migration key to swtpm.
This now encrypts the state of the TPM while a VM is migrated between
hosts or when suspended into a file. Since the migration key secret
is the same as the state encryption secret, this now requires that
the migration destination host has the same secret value.
Signed-off-by: NStefan Berger <stefanb@linux.ibm.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Allow vTPM state encryption when swtpm_setup and swtpm support
passing a passphrase using a file descriptor.

This patch enables the encryption of the vTPM state only. It does
not encrypt the state during migration, so the destination secret
does not need to have the same password at this point.
Signed-off-by: NStefan Berger <stefanb@linux.ibm.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Add a test case to commandtest.c to test the transfer of data to a
process who received the read-end of pipes' file descriptors. Transfer
large (128 kb) byte streams.

Extend the commandhelper.c with support for --readfd <fd> command line
parameter and convert the data receive loop to use poll and receive data
on multiple file descriptors (up to 3) and read data into distinct buffers
that we grow while adding more (string) data.
Signed-off-by: NStefan Berger <stefanb@linux.ibm.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Extend virCommandProcessIO to include the send buffers in the poll
loop.
Signed-off-by: NStefan Berger <stefanb@linux.ibm.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Mark a virCommand's inpipe (write-end of pipe) as non-blocking so that it
will never block when we were to try to write too many bytes to it while
it doesn't have the capacity to hold them.
Signed-off-by: NStefan Berger <stefanb@linux.ibm.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Convert the struct pollfd *fds to be allocated rather than residing
on the stack. This prepares it for the next patch where the size of
the array of fds becomes dynamic.
Signed-off-by: NStefan Berger <stefanb@linux.ibm.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Implement virCommandSetSendBuffer() that allows the caller to pass a
file descriptor and buffer to virCommand. virCommand will write the
buffer into the file descriptor. That file descriptor could be the
write end of a pipe or one of the file descriptors of a socketpair.
The other file descriptor should be passed to the launched process to
read the data from.

Only implement the function to allocate memory for send buffers
and to free them later on.
Signed-off-by: NStefan Berger <stefanb@linux.ibm.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Run 'swtpm socket --print-capabilities' and
'swtpm_setup --print-capabilities' to get the JSON object of the
features the programs are supporting and parse them into a bitmap.
Signed-off-by: NStefan Berger <stefanb@linux.ibm.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Check whether previously found executables were updated and if
so look for them again. This helps to use updated features of
swtpm and its tools upon updating them.
Signed-off-by: NStefan Berger <stefanb@linux.ibm.com>
Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Refactor virTPMEmulatorInit to use a loop with parameters. This allows
for easier extension later on.
Signed-off-by: NStefan Berger <stefanb@linux.ibm.com>
Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Move qemuTPMEmulatorInit to virTPMEmulatorInit in virtpm.c and introduce
a few functions to query the executables needed for virCommands.

Add locking to protect the tool paths and return a copy of the tool paths
to callers wanting to access them so that we can run the initialization
function multiples time later on and detect when the executable gets updated.
Signed-off-by: NStefan Berger <stefanb@linux.ibm.com>
Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

The QEMU command line does not change when TPM state is encrypted
compared to when it is plain.
Signed-off-by: NStefan Berger <stefanb@linux.ibm.com>
Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Add a test case for the TPM XML encryption parser and formatter.
Signed-off-by: NStefan Berger <stefanb@linux.ibm.com>
Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Extend the TPM device XML parser and XML generator with emulator
state encryption support.
Signed-off-by: NStefan Berger <stefanb@linux.ibm.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Add an already existing test case tpm-emulator-tpm2 to qemuxml2xmltest.c
Signed-off-by: NStefan Berger <stefanb@linux.ibm.com>
Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Add support for usage type vTPM to secret.
Extend the schema for the Secret to support the vTPM usage type
and add a test case for parsing the Secret with usage type vTPM.
Signed-off-by: NStefan Berger <stefanb@linux.ibm.com>
Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

The README contains a reference to GPL 2.1, which does not exist.
COPYING contains 2.0 so change the README to follow.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Sadly, this idea never got implemented.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Acked-by: NPeter Krempa <pkrempa@redhat.com>

When using the ENUM macros, the compiler guards that the declaration
and implementation are in sync.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Acked-by: NPeter Krempa <pkrempa@redhat.com>

We don't need domain_conf or libvirt-{qemu,lxc} in these generic files.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Acked-by: NPeter Krempa <pkrempa@redhat.com>

qemuBlockJobRewriteConfigDiskSource rewrites the disk source only
according to the 'target'. This means that if someone would change the
inactive config of the VM to refer to a different disk a block job would
rewrite it when finishing a job which modifies the disk source.

Make sure that this does not happen by verifying that the source of the
config disk is the same.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
ACKed-by: NEric Blake <eblake@redhat.com>

Since we copy everything from the original storage source including some
runtime data which are not relevant for the config we should clear them.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
ACKed-by: NEric Blake <eblake@redhat.com>

Both active block commit and block copy modify the disk source of the
active definition and thus also must modify the corresponding inactive
definition source so that the VM starts up later. This is currently
implemented in the legacy block job handler but the logic will be useful
also for the new handlers. Split it out which also simplifies it.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
ACKed-by: NEric Blake <eblake@redhat.com>