Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

It doesn't make sense to have the admin socket active if the main
socket is not running, so bind their lifecycle together.

This ensures that if primary socket is stopped, the corresponding
admin socket is also stopped.

In the reverse, starting the admin socket will also automatically
start the primary socket.
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

When we allow multiple instances of the driver for the same user
account, using a separate root directory, we need to ensure mutual
exclusion. Use a pidfile to guarantee this.

In privileged libvirtd this ends up locking

   /var/run/libvirt/bhyve/driver.pid

In unprivileged libvirtd this ends up locking

  /run/user/$UID/libvirt/bhyve/run/driver.pid

NB, the latter can vary depending on $XDG_RUNTIME_DIR
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

When we allow multiple instances of the driver for the same user
account, using a separate root directory, we need to ensure mutual
exclusion. Use a pidfile to guarantee this.

In privileged libvirtd this ends up locking

   /var/run/libvirt/vz/driver.pid

In unprivileged libvirtd this ends up locking

  /run/user/$UID/libvirt/vz/run/driver.pid

NB, the latter can vary depending on $XDG_RUNTIME_DIR
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

When we allow multiple instances of the driver for the same user
account, using a separate root directory, we need to ensure mutual
exclusion. Use a pidfile to guarantee this.

In privileged libvirtd this ends up locking

   /var/run/libvirt/lxc/driver.pid

In unprivileged libvirtd this ends up locking

  /run/user/$UID/libvirt/lxc/run/driver.pid

NB, the latter can vary depending on $XDG_RUNTIME_DIR
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

When we allow multiple instances of the driver for the same user
account, using a separate root directory, we need to ensure mutual
exclusion. Use a pidfile to guarantee this.

In privileged libvirtd this ends up locking

   /var/run/libvirt/libxl/driver.pid

In unprivileged libvirtd this ends up locking

  /run/user/$UID/libvirt/libxl/run/driver.pid

NB, the latter can vary depending on $XDG_RUNTIME_DIR
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

No supported build targets for libvirt still ship xend, so there is no
need for the libxl driver to check for it anymore.
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

When we allow multiple instances of the driver for the same user
account, using a separate root directory, we need to ensure mutual
exclusion. Use a pidfile to guarantee this.

In privileged libvirtd this ends up locking

   /var/run/libvirt/nwfilter/driver.pid

In unprivileged libvirtd this ends up locking

  /run/user/$UID/libvirt/nwfilter/run/driver.pid

NB, the latter can vary depending on $XDG_RUNTIME_DIR
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

When we allow multiple instances of the driver for the same user
account, using a separate root directory, we need to ensure mutual
exclusion. Use a pidfile to guarantee this.

In privileged libvirtd this ends up locking

   /var/run/libvirt/interface/driver.pid

In unprivileged libvirtd this ends up locking

  /run/user/$UID/libvirt/interface/run/driver.pid

NB, the latter can vary depending on $XDG_RUNTIME_DIR
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

When we allow multiple instances of the driver for the same user
account, using a separate root directory, we need to ensure mutual
exclusion. Use a pidfile to guarantee this.

In privileged libvirtd this ends up locking

   /var/run/libvirt/nodedev/driver.pid

In unprivileged libvirtd this ends up locking

  /run/user/$UID/libvirt/nodedev/run/driver.pid

NB, the latter can vary depending on $XDG_RUNTIME_DIR
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

When we allow multiple instances of the driver for the same user
account, using a separate root directory, we need to ensure mutual
exclusion. Use a pidfile to guarantee this.

In privileged libvirtd this ends up locking

   /var/run/libvirt/storage/driver.pid

In unprivileged libvirtd this ends up locking

  /run/user/$UID/libvirt/storage/run/driver.pid

NB, the latter can vary depending on $XDG_RUNTIME_DIR
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

When we allow multiple instances of the driver for the same user
account, using a separate root directory, we need to ensure mutual
exclusion. Use a pidfile to guarantee this.

In privileged libvirtd this ends up locking

   /var/run/libvirt/network/driver.pid

In unprivileged libvirtd this ends up locking

  /run/user/$UID/libvirt/network/run/driver.pid

NB, the latter can vary depending on $XDG_RUNTIME_DIR
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

When we allow multiple instances of the driver for the same user
account, using a separate root directory, we need to ensure mutual
exclusion. Use a pidfile to guarantee this.

In privileged libvirtd this ends up locking

   /var/run/libvirt/secrets/driver.pid

In unprivileged libvirtd this ends up locking

  /run/user/$UID/libvirt/secrets/run/driver.pid

NB, the latter can vary depending on $XDG_RUNTIME_DIR
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

When we allow multiple instances of the driver for the same user
account, using a separate root directory, we need to ensure mutual
exclusion. Use a pidfile to guarantee this.

In privileged libvirtd this ends up locking

   /var/run/libvirt/qemu/driver.pid

In unprivileged libvirtd this ends up locking

  /run/user/$UID/libvirt/qemu/run/driver.pid

NB, the latter can vary depending on $XDG_RUNTIME_DIR
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

We've been doing a terrible job of performing XML validation in our
various API that parse XML with a corresponding schema (we started
with domains back in commit dd69a14f, v1.2.12, but didn't catch all
domain-related APIs, didn't document the use of the flag, and didn't
cover other XML). New APIs (like checkpoints) should do the validation
unconditionally, but it doesn't hurt to continue retrofitting existing
APIs to at least allow the option.

While there are many APIs that could be improved, this patch focuses
on wiring up a new snapshot XML creation flag through all the
hypervisors that support snapshots, as well as exposing it in 'virsh
snapshot-create'.  For 'virsh snapshot-create-as', we blindly set the
flag without a command-line option, since the XML we create from the
command line should generally always comply (note that validation
might cause failures where it used to succeed, such as if we tighten
the RNG to reject a name of '../\n'); but blindly passing the flag
means we also have to add in fallback code to disable validation if
the server is too old to understand the flag.
Signed-off-by: NEric Blake <eblake@redhat.com>
Acked-by: NPeter Krempa <pkrempa@redhat.com>

Similar to VIR_DOMAIN_DEF_PARSE_VALIDATE_SCHEMA; the next patch will
put it to use with a counterpart public API flag.

No need to change qemudomainsnapshotxml2xmltest to use the flag, since
the testsuite already has a separate virschematest that does the same.
Signed-off-by: NEric Blake <eblake@redhat.com>
Acked-by: NPeter Krempa <pkrempa@redhat.com>

We no longer need to special-case xenUnified, since 1dac5fbb
dropped support for that naming scheme.
Signed-off-by: NEric Blake <eblake@redhat.com>
Acked-by: NPeter Krempa <pkrempa@redhat.com>

Previous commit:

  commit faceedaf
  Author: Jonathon Jongsma <jjongsma@redhat.com>
  Date:   Tue Jun 18 11:13:12 2019 -0500

    src/vz: use #pragma once in headers

accidentally chomped the "#" in a "#define" when re-indenting
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Support for the modern CPU_ALLOC macros was added 10 years ago in

  commit a73cd93b
  Author: Daniel P. Berrange <berrange@redhat.com>
  Date:   Mon Nov 16 16:08:29 2009 +0000

    Alternate CPU affinity impl to cope with NR_CPUS > 1024

This is long enough that we can assume it always exists and drop the
back compat code.
Reviewed-by: NMartin Kletzander <mkletzan@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Signed-off-by: NEric Blake <eblake@redhat.com>

Continuous integration caught that although 'make syntax-check' was
sufficient to let me be aware that I had to change bhyve to use
s/virDomainShutdownEnsureACL/virDomainShutdownFlagsEnsureACL/, it was
not sufficient to note which ACL functions require 2 vs. 3 arguments
for flag validation.

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

The @oldDef variable in libxlAddDom0() is not used really. Drop
it.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Even though we don't accept any flags, it is unfriendly to callers
that use the modern API to have to fall back to the flag-free API.

Note that virDomainBlockStats does not trivially forward to
virDomainBlockStatsFlags, so that one is omitted for now.
Signed-off-by: NEric Blake <eblake@redhat.com>
Acked-by: NPeter Krempa <pkrempa@redhat.com>

Even though we don't accept any flags, it is unfriendly to callers
that use the modern API to have to fall back to the flag-free API.
Signed-off-by: NEric Blake <eblake@redhat.com>
Acked-by: NPeter Krempa <pkrempa@redhat.com>

Even though we don't accept any flags, it is unfriendly to callers
that use the modern API to have to fall back to the flag-free API.
Signed-off-by: NEric Blake <eblake@redhat.com>
Acked-by: NPeter Krempa <pkrempa@redhat.com>

Even though we don't accept any flags, it is unfriendly to callers
that use the modern API to have to fall back to the flag-free API.
Signed-off-by: NEric Blake <eblake@redhat.com>
Acked-by: NPeter Krempa <pkrempa@redhat.com>

There are no users any more.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The files are now completely unused. Remove them.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

It's the only place where it's used.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

It's the only place where it's used.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The 'error' label just returned -1. Inline it.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

We've dropped old xend support over a year ago. At this point we can
also drop support for parsing very old configs.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

That's the only file using the helper function.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Use new coding style to merge the only use of xenFormatSxprSound into
the caller.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

It's no longer used. Remove the dead code.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The docs talked about an active snapshot when they meant an active
domain; they also claimed the flag was a no-op for hypervisors with no
snapshot metadata even though the flag is currently rejected as
unrecognized for hypervisors with no snapshot support at all.  A later
patch may teach more drivers to ignore the flag as a no-op, but that
shouldn't conflict with the wording chosen here (since a new client
talking to an old server still runs into the same issue, even if a
newer server becomes more tolerant).
Reported-by: NPeter Krempa <pkrempa@redhat.com>
Signed-off-by: NEric Blake <eblake@redhat.com>
Acked-by: NPeter Krempa <pkrempa@redhat.com>

The virConnectGetType() method has an unfortunate signature, returning a
static string that must not be freed by the caller. The remote driver,
however, gets this string dynamically over an RPC call, which raised a
design discussion on the mailing list. Eventually the problem was
resolved by having the remote driver cache the returned string
internally and free it when the connection was closed.

The link to the mailing list is thus talking about a problem that does
not actually exist in the final implementation, and at best serves to
confuse the reader into thinking there might be a memory leak.
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>