Since the domain XML saved in a snapshot or saved image uses the
original guest CPU definition but we still want to enforce ABI when
restoring the domain if libvirt and QEMU are new enough, we save the
live updated CPU definition in a save cookie.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Since the domain XML send during migration uses the original guest CPU
definition but we still want the destination to enforce ABI if it is new
enough, we send the live updated CPU definition in a migration cookie.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

When persistent migration of a transient domain is requested but no
custom XML is passed to the migration API we would just let the
destination daemon make a persistent definition from the live definition
itself. This is not a problem now, but once the destination daemon
starts replacing the original CPU definition with the one from migration
cookie before starting a domain, it would need to add more ugly hacks to
reverse the operation. Let's just always send the persistent definition
in the cookie to make things a bit cleaner.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

The destination host may not be able to start a domain using the live
updated CPU definition because either libvirt or QEMU may not be new
enough. Thus we need to send the original guest CPU definition.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

When starting a domain we update the guest CPU definition to match what
QEMU actually provided (since it is allowed to add or removed some
features unless check='full' is specified). Let's store the original CPU
in domain private data so that we can use it to provide a backward
compatible domain XML.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

The following patches will add an actual content in the cookie and use
the data when restoring a domain.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

This patch implements a new save cookie object and callbacks for qemu
driver. The actual useful content will be added in the object later.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

virDomainXMLOption gains driver specific callbacks for parsing and
formatting save cookies.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

The new structure encapsulates save image header and associated data
(domain XML).
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

The function is now called virQEMUSaveDataWrite and it is now doing
everything it needs to save both the save image header and domain XML to
a file. Be it a new file or an existing file in which a user wants to
change the domain XML.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

The function is supposed to update the save image header after a
successful migration to the save image file.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

This is a preparation for creating a new virQEMUSaveData structure which
will encapsulate all save image header data.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Since virQEMUSaveHeader will be followed by more than just domain XML,
the old name would be confusing as it was designed to describe the
length of all data following the save image header.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

This will be used later when a save cookie will become part of the
snapshot XML using new driver specific parser/formatter functions.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Allow starting the block-copy job for a persistent domain if a user
declares by using a flag that the job will not be recovered if the VM is
switched off while the job is active.

This allows to use the block-copy job with persistent VMs under the same
conditions as would apply to transient domains.

Without this patch libvirt would just report the operation of a
completed job as "unknown" instead of "incoming migration".

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

vCPU ordering information would not be updated if a vCPU emerged or
disappeared during the time libvirtd is not running. This allowed to
create invalid configuration like:

    [...]
    <vcpu id='56' enabled='yes' hotpluggable='yes' order='57'/>
    <vcpu id='57' enabled='yes' hotpluggable='yes' order='58'/>
    <vcpu id='58' enabled='yes' hotpluggable='yes'/>

Call the function that records the information on reconnect.

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

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

Problem is, qemu fails to load guest memory image if these
attribute change on migration/restore from an image.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

While checking for ABI stability, drivers might pose additional
checks that are not valid for general case. For instance, qemu
driver might check some memory backing attributes because of how
qemu works. But those attributes may work well in other drivers.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

qemuDomainGetBlockInfo would error out if qemu did not report
'wr_highest_offset'. This usually does not happen, but can happen
briefly during active layer block commit. There's no need to report the
error, we can simply report that the disk is fully alocated at that
point.

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

In 48d9e6cd and friends we've allowed users to back guest
memory by a file inside the host. And in order to keep things
manageable the memory_backing_dir variable was introduced to
qemu.conf to specify the directory where the files are kept.
However, libvirt's policy is that directories are created on
domain startup if they don't exist. We've missed this one.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

commit a8eba503 added further checking of the guest shutdown cause, but
this enhancement is available since qemu 2.10, causing a crash because
of a NULL pointer dereference on older qemus.

Thread 1 "libvirtd" received signal SIGSEGV, Segmentation fault.
0x00007ffff72441af in virJSONValueObjectGet (object=0x0,
                                             key=0x7fffd5ef11bf "guest")
    at util/virjson.c:769
769	    if (object->type != VIR_JSON_TYPE_OBJECT)
(gdb) bt
0  in virJSONValueObjectGet
1  in virJSONValueObjectGetBoolean
2  in qemuMonitorJSONHandleShutdown
3  in qemuMonitorJSONIOProcessEvent
4  in qemuMonitorJSONIOProcessLine
5  in qemuMonitorJSONIOProcess
6  in qemuMonitorIOProcess
Signed-off-by: NErik Skultety <eskultet@redhat.com>

QEMU will likely report the details of it shutting down, particularly
whether the shutdown was initiated by the guest or host.  We should
forward that information along, at least for shutdown events.  Reset
has that as well, however that is not a lifecycle event and would add
extra constants that might not be used.  It can be added later on.

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

This option turns on extended interrupt mode,
which allows more than 255 vCPUs.

https://bugzilla.redhat.com/show_bug.cgi?id=1451282Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

'param' contains the correct element from 'params'.

If the group name would not be the first parameter libvirtd would crash.

Introduced in c53bd25b.

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

The @meminfo allocated in qemuMonitorGetMemoryDeviceInfo() may be
lost when qemuDomainObjExitMonitor() failed.
Signed-off-by: NYi Wang <wang.yi59@zte.com.cn>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Setting the 'group_name' for a disk would falsely trigger a error path
as in commit 4b57f765 we did not properly check the return value of
VIR_STRDUP.

Otherwise the private data entry would be kept across instances of the
same VM even if it's not configured to do so.

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

priv and qemuCaps variables are not used anymore.
Signed-off-by: NKothapally Madhu Pavan <kmp@linux.vnet.ibm.com>

This reverts commit 2841e675.

It turns out that adding the host_mtu field to the PCI capabilities in
the guest bumps the length of PCI capabilities beyond the 32 byte
boundary, so the virtio-net device gets 64 bytes of ioport space
instead of 32, which offsets the address of all the other following
devices. Migration doesn't work very well when the location and length
of PCI capabilities of devices is changed between source and
destination.

This means that we need to make sure that the absence/presence of
host_mtu on the qemu commandline always matches between source and
destination, which means that we need to make setting of host_mtu an
opt-in thing (it can't happen automatically when the bridge being used
has a non-default MTU, which is what commit 2841e675 implemented).

I do want to re-implement this feature with an <mtu auto='on'/>
setting, but probably won't backport that to any stable branches, so
I'm first reverting the original commit, and that revert can be pushed
to the few releases that have been made since the original (3.1.0 -
3.3.0)

Resolves: https://bugzilla.redhat.com/1449346

Use a macro instead of hardcoding "127.0.0.1" throughout the
sources.

Only set releaseaddr to true after the address has been
reserved successfully.

https://bugzilla.redhat.com/show_bug.cgi?id=1452581Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

The error message would contain first vcpu id after the list of vcpus
selected for modification. To print the proper vcpu id remember the
first vcpu selected to be modified.

The code causes the 'offset' variable to be overwritten (possibly with
NULL if neither of the vCPUs is halted) which causes a crash since the
variable is still used after that part.

Additionally there's a bug, since strstr() would look up the '(halted)'
string in the whole string rather than just the currently processed line
the returned data is completely bogus.

Rather than switching to single line parsing let's remove the code
altogether since it has a commonly used JSON monitor alternative and
the data itself is not very useful to report.

The code was introduced in commit cc5e695b

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

Namely, this patch is about virMediatedDeviceGetIOMMUGroup{Dev,Num}
functions. There's no compelling reason why these functions should take
an object, on the contrary, having to create an object every time one
needs to query the IOMMU group number, discarding the object afterwards,
seems odd.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Since we allow active layer block commit the users are allowed to commit
the top of the chain (e.g. vda) into the backing image. The API would
not accept that parameter, as it tried to look up the image in the
backing chain.

Add the ability to use the top level image target name explicitly as the
top image of the block commit operation.

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

The QEMU default is GICv2, and some of the code in libvirt
relies on the exact value. Stop pretending that's not the
case and use GICv2 explicitly where needed.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

There are currently some limitations in the emulated GICv3
that make it unsuitable as a default. Use GICv2 instead.

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

Signed-off-by: NAndrea Bolognani <abologna@redhat.com>