This function for some weird reason returns integer instead of
virDomainNetType type. It is important to return the correct type
so that we know what values we can expect.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

There are couple of formatting issues. No functional change
though.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Not every system out there has syslog, that's why we check for it
in our configure script. However, in 640b58ab while fixing
another issue, some variables and functions are called that are
defined only when syslog.h is present. But these function
calls/variables were not guarded by #ifdef-s.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The smbios docs allow any string to be passed and libvirt does not
really do any validation on them. Allow passing any string.

Partially resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1373535

We pass free-form strings from the users to qemu, thus we need escape
commas since they are passed to qemu monitor.

Partially resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1373535

qemuBuildSmbiosBiosStr and qemuBuildSmbiosSystemStr return NULL if
there's nothing to format on the commandline. Reporting errors from
buffer creation doesn't make sense since it would be ignored.

This initially started as a fix of some debug printing in
virCgroupDetect. However it turned out that other places suffer
from the similar problem. While dealing with pids, esp. in cases
where we cannot use pid_t for ABI stability reasons, we often
chose an unsigned integer type. This makes no sense as pid_t is
signed.
Also, new syntax-check rule is introduced so we won't repeat this
mistake.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

It is stated in the manual already, so let's mention the same thing in
the description to avoid causing problems.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Consider the following scenario:

  virsh # freecell --all
      0:       2048 KiB
      1:       4096 KiB
  --------------------
  Total:       6144 KiB

  virsh # freecell 0
  0: 2048 KiB

  virsh # freecell 1
  1: 4096 KiB

And now before this change:

  virsh # freecell 2

After this change:

  virsh # freecell 2
  error: invalid argument: Range exceeds available cells
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

We have inclination to calling our loop variables i, j, k, not u.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>

Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1369633Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

There are two video devices with models without VGA compatibility mode.
They are primary used as secondary video devices, but in some cases it
is required to use them also as primary video devices.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

This improves commit 706b5b62 in a way that we check qemu capabilities
instead of what architecture we are running on to detect whether we can
use *virtio-vga* model or not.  This is not a case only for arm/aarch64.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Commit 21373feb added support for primary virtio-vga device but it was
checking for virtio-gpu.  Let's check for existence of virtio-vga if we
want to use it.

Virtio video device is currently represented by three different models
*virtio-gpu-device*, *virtio-gpu-pci* and *virtio-vga*.  The first two
models are tied together and if virtio video devices is compiled in they
both exist.  However, the *virtio-vga* model doesn't have to exist on
some architectures even if the first two models exist.  So we cannot
group all three together.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Before this patch we've checked qemu capabilities for video devices
only while constructing qemu command line using "-device" option.

Since we support qemu only if "-device" option is present we can use
the same capabilities to check also video devices while using "-vga"
option to construct qemu command line.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Runtime validation that depend on qemu capabilities should be moved
into qemuProcessStartValidateXML.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

All definition validation that doesn't depend on qemu capabilities
and was allowed previously as valid definition should be placed into
qemuDomainDefValidate.

The check whether video type is supported or not was based on an enum
that translates type into model.  Use switch to ensure that if new
video type is added, it will be properly handled.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

We generally uses QEMU_CAPS_DEVICE_$NAME to probe for existence of some
device and QEMU_CAPS_$NAME_$PROP to probe for existence of some property
of that device.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

If QEMU in question supports QMP, this capability is set if
QEMU_CAPS_DEVICE_QXL was set based on existence of "-device qxl". If
libvirt needs to parse *help*, because there is no QMP support, it
checks for existence of "-vga qxl", but it also parses output of
"-device ?" and sets QEMU_CAPS_DEVICE_QXL too.

Now that libvirt supports only QEMU that has "-device" implemented it's
safe to drop this capability and stop using it.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

This patch simplifies QEMU capabilities for QXL video device.  QEMU
exposes this device as *qxl-vga* and *qxl* and they are both the same
device with the same set of parameters, the only difference is that
*qxl-vga* includes VGA compatibility.

Based on QEMU code they are tied together so it's safe to check only for
presence of only one of them.

This patch also removes an invalid test case "video-qxl-sec-nodevice"
where there is only *qxl-vga* device and *qxl* device is not present.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

If one of QEMU_CAPS_DEVICE_QXL_VGA or QEMU_CAPS_DEVICE_QXL is set the
other one will always be set as well because both devices are tied
together in QEMU.

The change of args files is caused by the presence of capability
QEMU_CAPS_DEVICE_VIDEO_PRIMARY which means it's safe to use
"-device qxl-vga" instead of "-vga qxl", see commit (e3f2686b) and
by the fact that if QEMU_CAPS_VGA_QXL is set QEMU_CAPS_DEVICE_QXL_VGA
and QEMU_CAPS_DEVICE_QXL would be set too (since we support only qemu
with "-device" option).
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Qemu supports *xen* video device only with XEN and this code was part
of xenner code.  We dropped support for xenner in commit de9be0ab.

Before this patch if you used 'xen' video type you ended up with
domain without any video device at all.  Now we don't allow to start
such domain.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

If the VM is offline virsh attempted to at least report the pinning
information for the VM. This would not work properly now that the vcpus
can be sparse. Fix it by getting the vcpu states from the XML.

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

Put it into a separate function so that more fallback handling can be
added without making a mess.

cmdVcpuinfo will be split in upcomming patches thus extract the common
code that formats pinning cpumaps for the vcpus.

The fallback code used if virDomainGetVcpusFlags is not supported used
wrong XPath queries and basically did not work at all. Fix them to point
to the <domain> <vcpu> element instead of <vcpus> which was not present
until lately.

I managed to space most of the code by 5 spaces instead of 4 when
orignally implementing this function.

The functions just read the passed pointer so it can be marked as const.

The Requires relationship is very strong, in that it prevents
a unit from running unless all the units it Requires are
running as well.

This turns out to be a problem because we want to be able to
restart libvirtd at any time without having libvirt-guests
suspend or shutdown running guests.

Turn the Requires relationship into a Wants relationship:
this way starting libvirt-guests will cause systemd to (attempt
to) start libvirtd as well, but stopping or restarting libvirtd
will not alter libvirt-guests' running state.

It was never safe anyway and as such shouldn't have been enabled in the
first place.  Future patches will allow hot-(un)pluging of some ivshmem
devices as a workaround.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

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

Due to the switch of parameters in a call to virDomainShmemDefEquals()
no device was found when looking for device with all the information
except address.  Also fix the indentation.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>