On 1/27/23 8:40 AM, Christian Nautze wrote:
Hi!
Is it possible to get a review on this patch I send before Christmas? :)
Thank you!
Christian
_
Currently it's only possible to set this parameter during domain
creation via QEMU comma
When stopping swtpm we can restore the label either on just the
swtpm's domain specific logfile (/var/log/swtpm/libvirt/qemu/...),
or on the logfile and the state too (/var/lib/libvirt/swtpm/...).
The deciding factor is whether the guest is stopped because of
outgoing migration OR the state is on
When cleaning up host in qemuProcessStop(), our external helper
processes (e.g. swtpm) want to know whether the domain is being
migrated out or not (so that they restore seclabels on a device
state that's on a shared storage).
This fact is reflected in the @outgoingMigration variable which
is set
*** BLURB HERE ***
Michal Prívozník (3):
qemuProcessStop: Fix detection of outgoing migration for external
devices
qemuExtTPMStop: Restore TPM state label more often
qemuProcessLaunch: Tighten rules for external devices wrt incoming
migration
src/qemu/qemu_process.c | 11 +-
When starting a guest, helper processes are started first. But
they need a bit of special handling. Just consider a regular cold
boot and an incoming migration. For instance, in case of swtpm
with its state on a shared volume, we want to set label on the
state for the cold boot case, but don't want
Hi!
Is it possible to get a review on this patch I send before Christmas? :)
Thank you!
Christian
_
Currently it's only possible to set this parameter during domain
creation via QEMU commandline passthrough feature.
With the new del
Theoretically, when remoteDomainMigrateFinish3* is called without a
pointer for storing migration cookie and its length (i.e., either
cookieout == NULL or cookieoutlen == NULL), we would leak the freshly
created virDomain object referenced by rv.
Signed-off-by: Jiri Denemark
---
src/remote/remot
Since we now have a standalone script instead of inlined shell commands
in a YAML, we can adopt the common syntax for if-then-else clauses
which involve the '[' test command alias rather than keep using 'test'
explicitly.
Signed-off-by: Erik Skultety
---
ci/integration.sh | 2 +-
1 file changed,
Running outside of GitLab will likely not have the variable set and
hence the execution would fail.
Signed-off-by: Erik Skultety
---
ci/integration.sh | 9 +
1 file changed, 9 insertions(+)
diff --git a/ci/integration.sh b/ci/integration.sh
index 7bf3623809..e1f461a441 100644
--- a/ci/i
We no longer support Fedora 35 or older. While at it, we can also
tailor the rest of the check to CentOS Stream 8 only since all other
supported Red Hat like platforms have moved onto modular daemons setup
already.
Signed-off-by: Erik Skultety
---
ci/integration.sh | 3 +--
1 file changed, 1 ins
Because of the nature of writing inline shell commands to YAML, most of
the commentaries where inlined with the command not to hinder YAML
readability any further. Since we moved the logic to a standalone
script, we can now do whatever formatting & readability adjustments we
want.
Signed-off-by: E
In case /tmp is mounted as an in-memory file system, we're fairly storage
limited. This might pose a problem in VM scenarios if we build multiple
projects in there or download some data needed for testing. Therefore,
move the scratch to /home. Also, take the opportunity and rename
scratch to 'vroot
Since the section now only consists of a single command, we can happily
move the command to the main integration template job body.
Signed-off-by: Erik Skultety
---
ci/integration-template.yml | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/ci/integration-template.yml b/
This will allow us to re-use the script in other scenarios like local
executions where up until now one had to copy-paste the recipe
line-by-line.
Signed-off-by: Erik Skultety
---
ci/integration-template.yml | 36 +---
ci/integration.sh | 32
Using shell scripts rather than inlining shell commands to YAML feels more
natural, more readable, and will keep all different variations of execution
consistent. Essentially the only disadvantage is that we won't see each command
listed one-by-one in gitlab's log output (unless we set -x that is),
Apparently we've only had it because the -[ao] options weren't portable
at the time, but according to
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html
both are defined in POSIX.1-2017 revision which is old enough for all
our supported platforms to have adopted it already. There
16 matches
Mail list logo