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

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

Since its introduction in commit 874e65aa, if someone requests:
<os><bios useserial="yes"/><os/>
we report an error if we cannot successfully count the number
of serial devices via an XPath query.

Instead of fixing the check (and moving it to the validation phase,
to prevent existing domains from disappearing), drop it completely.
For QEMU, the number of serials is checked when building the command
line.

When security drivers are active but confinement is not enabled,
there is no need to autogenerate <seclabel> elements when starting
a domain def that contains no <seclabel> elements. In fact,
autogenerating the elements can result in needless save/restore and
migration failures when the security driver is not active on the
restore/migration target.

This patch changes the virSecurityManagerGenLabel function in
src/security_manager.c to only autogenerate a <seclabel> element
if none is already defined for the domain *and* default
confinement is enabled. Otherwise the needless <seclabel>
autogeneration is skipped.

Resolves: https://bugzilla.opensuse.org/show_bug.cgi?id=1051017

The virDomainDef created by testBuildDomainDef in securityselinuxtest
adds a seclabel but does not increment nseclabels. Also, it should
populate seclabel->model with 'selinux'.

While at it, use the secdef itself to populate values instead of
the indirection through def->seclabels[0].

It was not entirely clear that PARALLEL_SHUTDOWN setting is applied only
when the desired action is "shutdown".
Signed-off-by: NLily Zhu <lizhu@redhat.com>

Address some minor flaws in the original document that
were pointed out during review.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

I mistakenly thought pSeries guests supported 32 PHBs,
but it turns out they only support 31. Validate the
target index accordingly.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1479647Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

Validation should happen after parsing, so the proper
location for it is virDomainControllerDefValidate()
rather than virDomainControllerDefParseXML().
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

Split one of the existing tests to ensure both configuration
errors it contained cause a failure, and introduce a new
test case.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

Use the new facility which allows to ignore failures in post parse
callbacks if they are not fatal so that VM configs are not lost if the
emulator binary is missing.

If qemuCaps can't be populated on daemon restart skip certain portions
of the post parse callbacks during config reload and re-run the callback
during VM startup.

This fixes VMs vanishing if the emulator binary was broken or
uninstalled and libvirtd was restarted.

qemuDomainControllerDefPostParse assigns the default USB controller
model when it was not specified by the user. Skip this step if @qemuCaps
is missing so that we don't fill wrong data. This will then be fixes by
re-running the post parse callback.

Return NULL in qemuDomainDefaultNetModel if qemuCaps is missing and the
network card model would be determined by the capabilities.

Report the given GIC version as unsupported if @qemuCapsi is NULL. This
will be helpful to run post parse callbacks even if qemu is not
currently installed.

If qemuCaps are not present, just return the original machine type name.

This will help in situations when qemuCaps is not available in the post
parse callback.

Some failures of the post parse callback can be tolerated. This is
specifically desired when loading the configs of existing VMs. In such
case the post parse callback should not really be modifying anything
in the definition.

This patch adds a parse flag VIR_DOMAIN_DEF_PARSE_ALLOW_POST_PARSE_FAIL
which will allow the callbacks to report non-fatal failures by returning
a positive return value. In such case the field 'postParseFailed' in the
domain definition is set to true, to notify the drivers that the
callback failed and possibly needs to be re-run.

Post parse callbacks will need to be able to signal that they failed
non-fatally. This means that we need to return the value returned by the
callback without modification.

The domain post parse callback, domain address callback and the domain
device callback (for every single device) would each grab qemuCaps for
the current emulator. This is quite wasteful. Use the new callback to do
this just once.

Some drivers use def-specific private data across callbacks (e.g.
qemuCaps in the qemu driver). Currently it's mostly allocated in every
single callback. This is rather wasteful, given that every single call
to the device callback allocates it.

The new callback will allocate the data (if not provided externally) and
then use it for the VM, address and device post parse callbacks.

Add yet another post parse callback, which is executed prior the real
one without @parseOpaque. This is meant to set basics before
@parseOpaque (in case of the qemu driver qemuCaps) can be allocated.

This callback will allow to optimize passing of custom parseOpaque
through the callbacks.

When dropping a domain report which one was dropped so that it's not
necessary to rummage through the logs.

Offline migration transfers only the domain definition.

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

The helper returns true if a string contains any of the given chars.
virStringHasControlChars can be reimplemented using that helper.
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Let this new method handle the device object we obtained from the
monitor in order to enhance readability.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

So we have a sanity check for the udev monitor fd. Theoretically, it
could happen that the udev monitor fd changes (due to our own wrongdoing,
hence the 'sanity' here) and if that happens it means we are handling an
event from a different entity than we think, thus we should remove the
handle if someone somewhere somehow hits this hypothetical case.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

It might happen that virFileResolveLinkHelper fails on the lstat system
call. virFileResolveLink expects the caller to report an error when it
fails, however this wasn't the case for udevProcessMediatedDevice.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Testing qemu-2.10-rc3 shows issues like:
  qemu-system-aarch64: -drive file=/home/ubuntu/vm-start-stop/vms/
  7936-0_CODE.fd,if=pflash,format=raw,unit=1: Failed to unlock byte 100

There is an apparmor deny due to qemu now locking those files:
 apparmor="DENIED" operation="file_lock" [...]
 name="/home/ubuntu/vm-start-stop/vms/7936-0_CODE.fd"
 name="/var/lib/uvtool/libvirt/images/kvmguest-artful-normal.qcow"
 [...] comm="qemu-system-aarch64" requested_mask="k" denied_mask="k"

The profile needs to allow locking for loader and nvram files via
the locking (k) rule.
Signed-off-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>

Testing qemu-2.10-rc2 shows issues like:
  qemu-system-x86_64: -drive file=/var/lib/uvtool/libvirt/images/kvmguest- \
  artful-normal.qcow,format=qcow2,if=none,id=drive-virtio-disk0:
  Failed to lock byte 100

It seems the following qemu commit changed the needs for the backing
image rules:

(qemu) commit 244a5668106297378391b768e7288eb157616f64
Author: Fam Zheng <famz@redhat.com>
    file-posix: Add image locking to perm operations

The block appears as:
 apparmor="DENIED" operation="file_lock" [...]
 name="/var/lib/uvtool/libvirt/images/kvmguest-artful-normal.qcow"
 [...] comm="qemu-system-x86" requested_mask="k" denied_mask="k"

With that qemu change in place the rules generated for the image
and backing files need the allowance to also lock (k) the files.

Disks are added via add_file_path and with this fix rules now get
that permission, but no other rules are changed, example:
  -  "/var/lib/uvtool/libvirt/images/kvmguest-artful-normal-a2.qcow" rw,
  +  "/var/lib/uvtool/libvirt/images/kvmguest-artful-normal-a2.qcow" rwk
Signed-off-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>

XPath is good for random search of elements, not for accessing
attributes of one node.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Using XPath here doesn't add any benefit.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

The XPath call for these cases is more expensive than accessing the
XML dom node directly.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

XPath is good for random search of elements, not for accessing
attributes of one node.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

XPath is good for random search of elements, not for accessing
attributes of one node.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

XPath is good for random search of elements, not for accessing
attributes of one node.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

XPath is good for random search of elements, not for accessing
attributes of one node.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

XPath is good for random search of elements, not for accessing
attributes of one node.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

It's equivalent of calling virXPathString("string(.)", ctxt) but it
doesn't have to use the XPath resolving and parsing.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

The virXMLPropStringLimit is an equivalent of virXPathStringLimit
which should be preferred if you already have a XML dom node or
if you need to parse more than one property.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Back in the day when I was implementing QoS for networks there
were no self inflating virBitmaps. Only the static ones.
Therefore, I had to allocate the whole 8KB of memory in order to
keep track of used/unused class IDs. This is rather wasteful
because nobody is ever gonna use that much classes (kernel
overhead would drastically lower the bandwidth). Anyway, now that
we have self inflating bitmaps we can start small and allocate
more if there's need for it.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>