The code preparing data for creating/attaching the target image of block
copy didn't use the correct reference to the existing backing chain in
case when the copy should inherit it. This meant that qemu actually
opened a second copy of the chain and operated on that.

This would de-sync qemu from libvirt's view of node names. Luckily this
is only hypothetical at this point since it happens only when -blockdev
is enabled.

Fix it by passing 'mirrorBacking' which has the proper data as the
backing store when calling
qemuBuildStorageSourceChainAttachPrepareBlockdevTop.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

In some cases we'll need to pass in a backing store which is not
recorded as the backing store of @src. Export backingStore as variable
and fix all callers to pass in the backing store. No semantic changes
for now.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Pass backing store as an argument rather than extracting it locally and
fix the callers.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Extract the loop and supporting infrastructure to the caller as only one
of the two callers actually cares about looping and rename the helper to
qemuBuildStorageSourceChainAttachPrepareBlockdevOne.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Pass in backing store explicitly to qemuBlockStorageSourceGetBlockdevProps
and fix the callers.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Move all bits of the formatting of the 'backing' attribute to a single
condition and make it use a single extracted copy of the backing store.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Since libvirt stores the backing chain into the XML in a nested way it
is the prime possibility to hit libxml2's parsing limit of 256 layers.

Introduce code which will crawl the backing chain and verify that it's
not too deep. The maximum nesting is set to 200 layers so that there's
still some space left for additional properties or nesting into snapshot
XMLs.

The check is applied to all disk use cases (starting, hotplug, media
change) as well as block copy which changes image and snapshots.

We simply report an error and refuse the operation.

Without this check a restart of libvirtd would result in the status XML
failing to be parsed and thus losing the VM.

https://bugzilla.redhat.com/show_bug.cgi?id=1524278Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Use VIR_AUTOUNREF and get rid of the cleanup label.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

With blockdev we must issue the block_set_io_throttle QMP command to
setup disk throttling as we currently can't do it with the 'throttle'
layer.

Unfortunately there's nothing we can do if it fails.

https://bugzilla.redhat.com/show_bug.cgi?id=1733163Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Get rid of the last manually freed var.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Switch to using VIR_AUTOFREE and remove the cleanup label.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

When virtlogd is used to capture QEMU's stdout, qemuDomainObjTaint would
always fail to write the message to the log file when QEMU is already
running (i.e., outside qemuProcessLaunch). This can happen during device
hotplug or by sending a custom QEMU guest agent command:

    warning : qemuDomainObjTaint:8757 : Domain id=9 name='blaf'
        uuid=9cfa4e37-2930-405b-bcb4-faac1829dad8 is tainted:
        custom-ga-command
    error : virLogHandlerDomainOpenLogFile:388 : Cannot open log file:
        '/var/log/libvirt/qemu/blaf.log': Device or resource busy
    error : virNetClientProgramDispatchError:172 : Cannot open log file:
        '/var/log/libvirt/qemu/blaf.log': Device or resource busy

The fix is easy, we just need to use the right API for appending a
message to QEMU log file instead of creating a new log context.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The attribute is named 'secret', not 'uuid'
Signed-off-by: NCole Robinson <crobinso@redhat.com>

Reviewed-by: NLaine Stump <laine@laine.org>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The offset is unsigned long long thus 'U' must be used.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Actually test that the full range is available.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The 'u' modifier creates an unsigned int JSON attribute but the disk size
and capacity fields are unsigned long long. If the size of the created
image would be more than 4GiB we'd overflow and create sub-4G image.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NJim Fehlig <jfehlig@suse.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

The xenapi driver has not seen any development since its initial
contribution 9 years ago. There have been no bug reports, no patches,
and no queries about the driver on the developer or user mailing lists.
Remove the driver from the libvirt sources.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Signed-off-by: NJim Fehlig <jfehlig@suse.com>

* docs/news.xml: updated for release
Signed-off-by: NDaniel Veillard <veillard@redhat.com>

Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

A specially crafted XML which would reference a non-existing disk but
request the mirror to be registered with the blockjob could potentially
make the parser dereference NULL. Fix it by moving the code slightly and
just treat it as a wrong job XML. Found by Coverity.
Reported-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

The (pre-copy) bandwidth was historically the only bandwidth we
supported and thus it is called just "bandwidth" in all other places.
E.g., virsh migrate-setspeed or in the migration typed parameter name.
Let's make the new option for virsh migrate consistent.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

The (pre-copy) bandwidth was historically the only bandwidth we
supported and thus it is called just "bandwidth" in all other places.
E.g., virsh migrate-setspeed or in the migration typed parameter name.
Let's make the new option for virsh migrate consistent.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

If a block job reaches failed/cancelled state, or is completed
without pivot then we must remove security driver metadata
associated to the backing chain so that we don't leave any
metadata behind.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1741456Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
ACKed-by: NPeter Krempa <pkrempa@redhat.com>

When a block job is completed, the security image metadata are
moved to the new image. If this fails an warning is printed, but
the message contains only domain name and lacks image paths. Put
them both into the warning message.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
ACKed-by: NPeter Krempa <pkrempa@redhat.com>

Currently, there are only a few lines of code so a separate
function was not necessary, but this will change. So instead of
putting all the new code under 'case
QEMU_BLOCKJOB_TYPE_ACTIVE_COMMIT' create a separate function.
Just like every other case has one.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
ACKed-by: NPeter Krempa <pkrempa@redhat.com>

I guess the reason for that was the automatic interpretation/stringification of
setfilecon_errno, but the code was not nice to read and it was a bit confusing.
Also, the logs and error states get cleaner this way.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Coverity noted that 'reply' can be NULL after calling
qemuAgentCommand().  Avoid dereferencing reply in
qemuAgentErrorComandUnsupported() in that case.
Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com>

Introduced by commit <c854e0bd> that
tried to fix an issue where we would fail to parse values from files.

We cannot change the original pointer that is going to be used by
VIR_AUTOFREE.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1747440Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
Acked-by: NPeter Krempa <pkrempa@redhat.com>

'virQEMUDriverConfigPtr cfg' is declared, initiated, but never
used in virQEMUDriverCreateCapabilities().
Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>
Reviewed-by: NChristophe de Dinechin <dinechin@redhat.com>

There are some network file systems that do support XATTRs (e.g.
gluster via FUSE). And they appear to support SELinux too.
However, not really. Problem is, that it is impossible to change
SELinux label of a file stored there, and yet we claim success
(rightfully - hypervisor succeeds in opening the file). But this
creates a problem for us - from XATTR bookkeeping POV, we haven't
changed the label and thus if we remembered any label, we must
roll back and remove it.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1740506Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMartin Kletzander <mkletzan@redhat.com>

This function is no longer needed because after previous commits
it's just an alias to virSecuritySELinuxSetFilecon.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMartin Kletzander <mkletzan@redhat.com>

Now, that we don't need to remember if setting context is
'optional' (the argument only made
virSecuritySELinuxSetFileconImpl() return a different success
code), we can drop it from the _virSecuritySELinuxContextItem
structure as we don't need to remember it in transactions.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMartin Kletzander <mkletzan@redhat.com>

There is no real difference between
virSecuritySELinuxSetFilecon() and
virSecuritySELinuxSetFileconOptional(). Drop the latter in favour
of the former.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMartin Kletzander <mkletzan@redhat.com>

The only thing that the @optional argument does is that it makes
the function return 1 instead of 0 if setting SELinux context
failed in a non-critical fashion. Drop the argument then and
return 1 in that case. This enables caller to learn if SELinux
context was set or not.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMartin Kletzander <mkletzan@redhat.com>

As qemu documents we should use everything in the 'props' sub-object of
the data returned by query-hotpluggable-cpus. Until now we only used
everything we recognized, but that may break in cases when qemu
introduces new fields.

This change requires a fix to the test data as some fields were
reordered.

https://bugzilla.redhat.com/show_bug.cgi?id=1741658Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

In addition to the data that libvirt needs and extracts internally,
copy and store the whole 'props' JSON sub-object of the data returned by
query-hotpluggable-cpus for future use.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>