virConnectGetConfig and virConnectGetConfigPath were static libvirt
methods, merely because there hasn't been any need for having them
internally exported yet. Since libvirt-admin also needs to reference
its config file, 'xGetConfig' should be exported.
Besides moving, this patch also renames the methods accordingly,
as they are libvirt config specific.

Since libvirt-admin is a separate library, it should also have a separate
config file. Available settings are currently the same as for libvirt.conf.

Check if virtio-gpu provides virgl option, and add qemu command line
formatter.

It is enabled with the existing accel3d attribute:
<model type='virtio' heads='1'>
 <acceleration accel3d='yes'/>
</model>
Signed-off-by: NMarc-André Lureau <marcandre.lureau@gmail.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

qemu 2.5 provides virtio video device.  It can be used with -device
virtio-vga for primary devices, or -device virtio-gpu for non-vga
devices. However, only the primary device (VGA) is supported with this
patch.

Reference:
https://bugzilla.redhat.com/show_bug.cgi?id=1195176Signed-off-by: NMarc-André Lureau <marcandre.lureau@gmail.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Allowing to have the extra undefined/default state.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@gmail.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Following the domain XML naming
Signed-off-by: NMarc-André Lureau <marcandre.lureau@gmail.com>

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>

The libvirt_logd.aug and test_libvirt_logd.aug.in files
have never existed so shouldn't be in EXTRA_DIST. It was
a copy+paste mistake when closing virtlogd from virtlockd
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

With some versions of GLibC / GCC, a variable called 'daemon'
will result in a warning about clashing with the function also
named 'daemon'. Rename it to 'dmn' to avoid the clash.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Otherwise we fail on 32bit with:

CC     logging/virtlogd-log_daemon_dispatch.o
logging/log_daemon_dispatch.c: In function 'virLogManagerProtocolDispatchDomainReadLogFile':
logging/log_daemon_dispatch.c:120:9: error: format '%zu' expects argument of type 'size_t', but argument 7 has type 'uint64_t' [-Werror=format]

Fix memory leaks, failure to restore umask and missing man
page docs.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The virtlogd daemon is launched with a 30 second timeout for
unprivileged users. Unfortunately the timeout is only inhibited
while RPC clients are connected, and they only connect for a
short while to open the log file descriptor. We need to hold
an inhibition for as long as the log file descriptor itself
is open.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Currently the QEMU stdout/stderr streams are written directly to
a regular file (eg /var/log/libvirt/qemu/$GUEST.log). While those
can be rotated by logrotate (using copytruncate option) this is
not very efficient. It also leaves open a window of opportunity
for a compromised/broken QEMU to DOS the host filesystem by
writing lots of text to stdout/stderr.

This makes it possible to connect the stdout/stderr file handles
to a pipe that is provided by virtlogd. The virtlogd daemon will
read from this pipe and write data to the log file, performing
file rotation whenever a pre-determined size limit is reached.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Currently the QEMU monitor is given an FD to the logfile. This
won't work in the future with virtlogd, so it needs to use the
qemuDomainLogContextPtr instead, but it shouldn't directly
access that object either. So define a callback that the
monitor can use for reporting errors from the log file.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

When the qemuProcessAttach/Stop methods write a marker into
the log file, they can use qemuDomainLogContextWrite to
write a formatted message.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Instead of writing directly to a log file descriptor, change
qemuLogOperation to use qemuDomainLogContextWrite().
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The qemuDomainTaint APIs currently expect to be passed a log file
descriptor. Change them to instead use a qemuDomainLogContextPtr
to hide the implementation details.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Convert the places which create/open log files to use the new
qemuDomainLogContextPtr object instead.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Introduce a qemuDomainLogContext object to encapsulate
handling of I/O to/from the domain log file. This will
hide details of the log file implementation from the
rest of the driver, making it easier to introduce
support for virtlogd later.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

There are two pretty similar functions qemuProcessReadLog and
qemuProcessReadChildErrors. Both read from the QEMU log file
and try to strip out libvirt messages. The latter then reports
an error, while the former lets the callers report an error.

Re-write qemuProcessReadLog so that it uses a single read
into a dynamically allocated buffer. Then introduce a new
qemuProcessReportLogError that calls qemuProcessReadLog
and reports an error.

Convert all callers to use qemuProcessReportLogError.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The rename operation only works on inactive virtual machines,
but it none the less writes to the log file used by the QEMU
processes. This log file is not intended to provide a general
purpose audit trail of operations performed on VMs. The audit
subsystem has recording of important operations. If we want
to extend that to cover all significant public APIs that is
a valid thing to consider, but we shouldn't arbitrarily log
specific APIs into the QEMU log file in the meantime.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Add the virLogManager API which allows for communication with
the virtlogd daemon to RPC program. This provides the client
side API to open log files for guest domains.

The virtlogd daemon is setup to auto-spawn on first use when
running unprivileged. For privileged usage, systemd socket
activation is used instead.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Define a new RPC protocol for the virtlogd daemon that provides
for handling of logs. The initial RPC method defined allows a
client to obtain a file handle to use for writing to a log
file for a guest domain. The file handle passed back will not
actually refer to the log file, but rather an anonymous pipe.
The virtlogd daemon will forward I/O between them, ensuring
file rotation happens when required.

Initially the log setup is hardcoded to cap log files at
128 KB, and keep 3 backups when rolling over, which gives
a max usage of 512 KB per guest.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Copy the virtlockd codebase across to form the initial virlogd
code. Simple search & replace of s/lock/log/ and gut the remote
protocol & dispatcher. This gives us a daemon that starts up
and listens for connections, but does nothing with them.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Add virRotatingFileReader and virRotatingFileWriter objects
which allow reading & writing from/to files with automation
rotation to N backup files when a size limit is reached. This
is useful for guest logging when a guaranteed finite size
limit is required. Use of external tools like logrotate is
inadequate since it leaves the possibility for guest to DOS
the host in between invokations of logrotate.
Signed-off-by: NDaniel P. Berrange <berrange@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>

Link it to virDomainDetachDeviceFlags.

https://bugzilla.redhat.com/show_bug.cgi?id=1257280Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Using qemuProcess{Init,Launch,FinishStartup} allows us to run
pre-migration commands on destination before asking QEMU to wait for
incoming migration data.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

NBD storage migration will not work with offline migration anyway and we
already checked that the user did not ask for it. Thus it doesn't make
sense to keep the code after 'done' label where we jump in case of
offline migration.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Some failure paths in qemuMigrationPrepareAny forgot to kill the just
started QEMU process. This patch fixes this by combining 'stop' and
'endjob' label into a new label 'stopjob'. This name was chosen to avoid
confusion with the most common semantics of 'endjob'. Normally, 'endjob'
is always called at the end of an API to stop the job we entered at the
beginning. In qemuMigrationPrepareAny we only want to stop the job in
failure path; on success we need to carry the job over to the Finish
phase.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Finishes starting a new domain launched by qemuProcessLaunch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Once qemuProcessInit was called, qemuProcessLaunch will launch a new
QEMU process with stopped virtual CPUs.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

qemuProcessStart is going to be split in three parts: qemuProcessInit,
qemuProcessLaunch, and qemuProcessFinish so that migration Prepare phase
can insert additional code in the process. qemuProcessStart will be a
small wrapper for all other callers.

qemuProcessInit prepares the domain up to the point when priv->qemuCaps
is initialized.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Only one panic device per model is allowed.

'model' attribute was added to a panic device but only one panic
device is allowed. This patch changes panic device presence
from 'optional' to 'zeroOrMore'.

Panic device type used depends on 'model' attribute.

If no model is specified then device type depends on hypervisor
and guest arch. 'pseries' model is used for pSeries guest and
'isa' model is used in other cases.

XML:
<devices>
  <panic model='hyperv'/>
</devices>

QEMU command line:
qemu -cpu <cpu_model>,hv_crash

Libvirt already has two types of panic devices - pvpanic and pSeries firmware.
This patch introduces the 'model' attribute and a new type of panic device.

'isa' model is for ISA pvpanic device.
'pseries' model is a default value for pSeries guests.
'hyperv' model is the new type. It's used for Hyper-V crash.

Schema and docs are updated for the new attribute.

A PCI device may have the capability to setup virtual functions (VFs)
but have them currently all disabled. Prior to this patch, if that was
the case the the node device XML for the device wouldn't report any
virtual_functions capability.

With this patch, if a file called "sriov_totalvfs" is found in the
device's sysfs directory, its contents will be interpreted as a
decimal number, and that value will be reported as "maxCount" in a
capability element of the device's XML, e.g.:

   <capability type='virtual_functions' maxCount='7'/>

This will be reported regardless of whether or not any VFs are
currently enabled for the device.

NB: sriov_numvfs (the number of VFs currently active) is also
available in sysfs, but that value is implied by the number of items
in the list that is inside the capability element, so there is no
reason to explicitly provide it as an attribute.

sriov_totalvfs and sriov_numvfs are available in kernels at least as far
back as the 2.6.32 that is in RHEL6.7, but in the case that they
simply aren't there, libvirt will behave as it did prior to this patch
- no maxCount will be displayed, and the virtual_functions capability
will be absent from the device's XML when 0 VFs are enabled.