Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

This reverts commit 0e0149ce.

That commit was added to comply with systemd rules that were changed in
the meantime, so this patch is pointless.

Machine name escaping follows the same rules as serice name escape,
except that '.' and '-' must not be escaped in machine names, due
to a bug in systemd-machined.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1282846Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

According to the documentation, CreateMachine accepts only 7bit ASCII
characters in the machinename parameter, so let's make sure we can start
machines with unicode names with systemd.  We already have a function
for that, we just forgot to use it.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1062943
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1282846Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

We have macros for both positive and negative string matching.
Therefore there is no need to use !STREQ or !STRNEQ. At the same
time as we are dropping this, new syntax-check rule is
introduced to make sure we won't introduce it again.
Signed-off-by: NIshmanpreet Kaur Khera <khera.ishman@gmail.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The scope name, even according to our docs is
"machine-$DRIVER\x2d$VMNAME.scope" virSystemdMakeScopeName would use the
resource partition name instead of "machine-" if it was specified thus
creating invalid scope paths.

This makes libvirt drop cgroups for a VM that uses custom resource
partition upon reconnecting since the detected scope name would not
match the expected name generated by virSystemdMakeScopeName.

The error is exposed by the following log entry:

debug : virCgroupValidateMachineGroup:302 : Name 'machine-qemu\x2dtestvm.scope' for controller 'cpu' does not match 'testvm', 'testvm.libvirt-qemu' or 'machine-test-qemu\x2dtestvm.scope'

for a "/machine/test" resource and "testvm" vm.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1238570

In many cases where we invoke virSystemdTerminateMachine the
process(es) will have already gone away on their own accord.
In these cases we log an error message that the machine does
not exist. We should catch this particular error and simply
ignore it, so we don't pollute the logs.

Add a virDBusErrorIsUnknownMethod helper so that callers
don't need todo string comparisons themselves to detect
standard error names.

The virDBusMethodCall method has a DBusError as one of its
parameters. If the caller wants to pass a non-NULL value
for this, it immediately makes the calling code require
DBus at build time. This has led to breakage of non-DBus
builds several times. It is desirable that only the virdbus.c
file should need WITH_DBUS conditionals, so we must ideally
remove the DBusError parameter from the method.

We can't simply raise a libvirt error, since the whole point
of this parameter is to give the callers a way to check if
the error is one they want to ignore, without having the logs
polluted with an error message. So, we add a virErrorPtr
parameter which the caller can then either ignore or raise
using the new virReportErrorObject method.

This new method is distinct from virSetError in that it
ensures the logging hooks are run.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

systemd-machined introduced a new method CreateMachineWithNetwork
that obsoletes CreateMachine. It expects to be given a list of
VETH/TAP device indexes for the host side device(s) associated
with a container/machine.

This falls back to the old CreateMachine method when the new
one is not supported.

Replace:
if (virBufferError(&buf)) {
    virBufferFreeAndReset(&buf);
    virReportOOMError();
    ...
}

with:
if (virBufferCheckError(&buf) < 0)
    ...

This should not be a functional change (unless some callers
misused the virBuffer APIs - a different error would be reported
then)

Commit 48976981 fixed the build without dbus by only building
the virSystemdPMSupportTarget with SYSTEMD_DAEMON.

Introduce a virDBusMessageUnref wrapper for dbus_message_unref
to let virsystemd.c build without dbus, while still allowing
virsystemdtest to run without SYSTEM_DAEMON.

In order to do that, virNodeSuspendSupportsTargetPMUtils() and
virSystemdPMSupportTarget() are created even when pm-utils and dbus
are compiled out, respectively, but in that case returning -2 meaning
"unavailable" (this return code was already used for unavailability
before).  Error is reported in virNodeSuspendSupportsTarget() only if
both functions returned -2, otherwise the error (or success) is properly
propagated up the stack.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

This uses the dbus api of systemd to check the power management
capabilities of the node.

The caller may not want all DBus error conditions to be turned
into libvirt errors, so provide a way for the caller to get
back the full DBusError object. They can then check the errors
and only report those that they consider to be fatal.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Any source file which calls the logging APIs now needs
to have a VIR_LOG_INIT("source.name") declaration at
the start of the file. This provides a static variable
of the virLogSource type.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

If systemd is installed, but is not the init system,
systemd-machined fails with an unhelpful error message:
Launch helper exited with unknown return code 1

Currently we only check if the "machine1" service is
available (in ListActivatableNames).
Also check if "systemd1" service is registered with DBus
(ListNames).

This fixes https://bugs.gentoo.org/show_bug.cgi?id=493246#c22

Systemd does not forget about the cases, where client service needs to
wait for daemon service to initialize and start accepting new clients.
Setting a dependency in client is not enough as systemd doesn't know
when the daemon has initialized itself and started accepting new
clients. However, it offers a mechanism to solve this. The daemon needs
to call a special systemd function by which the daemon tells "I'm ready
to accept new clients". This is exactly what we need with
libvirtd-guests (client) and libvirtd (daemon). So now, with this
change, libvirt-guests.service is invoked not any sooner than
libvirtd.service calls the systemd notify function.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

https://bugzilla.redhat.com/show_bug.cgi?id=1031696

When creating a new domain, we let systemd know about it by calling
CreateMachine() function via dbus. Systemd then creates a scope and
places domain into it. However, later when the host is shutting
down, systemd computes the shutdown order to see what processes can
be shut down in parallel. And since we were not setting
dependencies at all, the slices (and thus domains) were most likely
killed before libvirt-guests.service. So user domains that had to
be saved, shut off, whatever were in fact killed.  This problem can
be solved by letting systemd know that scopes we're creating must
not be killed before libvirt-guests.service.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Previous commit

  commit 7ada155c
  Author: Gao feng <gaofeng@cn.fujitsu.com>
  Date:   Wed Sep 11 11:15:02 2013 +0800

    DBus: introduce virDBusIsServiceEnabled

Made the cgroups code fallback to non-systemd based setup
when dbus is not running. It was too big a hammer though,
as it did not check what error code was received when the
dbus connection failed. Thus it silently ignored serious
errors from dbus such as "too many client connections",
which should always be treated as fatal.

We only want to ignore errors if the dbus unix socket does
not exist, or if nothing is listening on it.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The problem is described by [0] but its effect on libvirt is that
starting a container with a full distro running systemd after having
stopped it simply fails.

The container cleanup now calls the machined Terminate function to make
sure that everything is in order for the next run.

 [0]: https://bugs.freedesktop.org/show_bug.cgi?id=68370

https://bugzilla.redhat.com/show_bug.cgi?id=1008619

1,003 bytes in 1 blocks are definitely lost in loss record 599 of 635
==404== by 0x50728A7: virBufferAddChar (virbuffer.c:185)
==404== by 0x50BC466: virSystemdEscapeName (virsystemd.c:67)
==404== by 0x50BC6B2: virSystemdMakeSliceName (virsystemd.c:108)
==404== by 0x50BC870: virSystemdCreateMachine (virsystemd.c:169)
==404== by 0x5078267: virCgroupNewMachine (vircgroup.c:1498)

This patch introduces virDBusIsServiceEnabled, we can use
this method to get if the service is supported.

In one case, if org.freedesktop.machine1 is unavailable on
host, we should skip creating machine through systemd.
Signed-off-by: NGao feng <gaofeng@cn.fujitsu.com>

On hosts that don't have the DBus service running or installed the new
systemd cgroups code failed with hard error instead of falling back to
"manual" cgroup creation.

Use the new helper to check for the system bus and use the fallback code
in case it isn't available.

There are some interesting escaping rules to consider when dealing
with systemd slice/scope names. Thus it is helpful to have APIs
for formatting names
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

If systemd machine does not exist, return -2 instead of -1,
so that applications don't need to repeat the tedious error
checking code
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

To register virtual machines and containers with systemd-machined,
and thus have cgroups auto-created, we need to talk over DBus.
This is somewhat tedious code, so introduce a dedicated function
to isolate the DBus call in one place.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>