When implementing memory hotplug I've opted to recalculate the initial
memory size (contents of the <memory> element) as a sum of the sizes of
NUMA nodes when NUMA was enabled. This was based on an assumption that
qemu did not allow starting when the NUMA node size total didn't equal
to the initial memory size. Unfortunately the check was introduced to
qemu just lately.

This patch uses the new XML parser flag to decide whether it's safe to
update the memory size total from the NUMA cell sizes or not.

As an additional improvement we now report an error in case when the
size of hotplug memory would exceed the total memory size.

The rest of the changes assures that the function is called with correct
flags.

Add 'initial_memory' member to struct virDomainMemtune so that the
memory size can be pre-calculated once instead of inferring it always
again and again.

Separating of the fields will also allow finer granularity of decisions
in later patches where it will allow to keep the old initial memory
value in cases where we are handling incomming migration from older
versions that did not always update the size from NUMA as the code did
previously.

The change also requires modification of the qemu memory alignment
function since at the point where we are modifying the size of NUMA
nodes the total size needs to be recalculated too.

The refactoring done in this patch also fixes a crash in the hyperv
driver that did not properly initialize def->numa and thus
virDomainNumaGetMemorySize(def->numa) crashed.

In summary this patch should have no functional impact at this point.

The name of the variable was misleading. Rename it and it's setting
accessor before other fixes.

The post parse func is growing rather large. Since later patches will
introduce more logic in the memory post parse code, split it into a
separate handler.

Add a new parser flag that will mark code paths that parse XML files
wich will not be used with existing VM state so that post parse
callbacks can possibly do ABI incompatible changes if needed.

The flag was used only for formatting the XML and once the parser and
formatter flags were split in 0ecd6851
it doesn't make sense any more to have it.

Extract the size determination into a separate function and reuse it
across the memory device alignment functions. Since later we will need
to decide the alignment size according to architecture let's pass def to
the functions.

Add a simple helper so that the code doesn't have to rewrite the same
condition multiple times.

Commits 45697fe5 and f863ac80 used direct access to the variable instead
of the preferred accessor method.

Since test suite now correctly creates capabilities cache, the hack is not
needed any more.
Signed-off-by: NPavel Fedin <p.fedin@samsung.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Use the new API in order to correctly add capability sets to the cache
before parsing XML files
Signed-off-by: NPavel Fedin <p.fedin@samsung.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

The main purpose of this patch is to introduce test mode to
virQEMUCapsCacheLookup(). This is done by adding a global variable, which
effectively overrides binary name. This variable is supposed to be set by
test suite.

The second addition is qemuTestCapsCacheInsert() function which allows the
test suite to actually populate the cache.
Signed-off-by: NPavel Fedin <p.fedin@samsung.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Two utility functions are introduced for proper initialization and
cleanup of the driver.
Signed-off-by: NPavel Fedin <p.fedin@samsung.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

 Invalid read of size 4
    at 0x945CA30: __pthread_mutex_unlock_full (in /lib64/libpthread-2.20.so)
    by 0x4F0404B: virMutexUnlock (virthread.c:94)
    by 0x4F7161B: virStoragePoolObjUnlock (storage_conf.c:2603)
    by 0x4FE0476: testStoragePoolUndefine (test_driver.c:4328)
    by 0x4FCF086: virStoragePoolUndefine (libvirt-storage.c:656)
    by 0x15A7F5: cmdPoolUndefine (virsh-pool.c:1721)
    by 0x12F48D: vshCommandRun (vsh.c:1212)
    by 0x132AA7: main (virsh.c:943)
  Address 0xfda56a0 is 16 bytes inside a block of size 104 free'd
    at 0x4C2BA6C: free (vg_replace_malloc.c:473)
    by 0x4EA5C96: virFree (viralloc.c:582)
    by 0x4F70B69: virStoragePoolObjFree (storage_conf.c:412)
    by 0x4F7167B: virStoragePoolObjRemove (storage_conf.c:437)
    by 0x4FE0468: testStoragePoolUndefine (test_driver.c:4323)
    by 0x4FCF086: virStoragePoolUndefine (libvirt-storage.c:656)
    by 0x15A7F5: cmdPoolUndefine (virsh-pool.c:1721)
    by 0x12F48D: vshCommandRun (vsh.c:1212)
    by 0x132AA7: main (virsh.c:943)

Rather than inlining the code, use the common API.

Rather than inlining the code, use the common API.

Rather than inlining the code, use the common API

Similar to commit id '35847860', it's possible to attempt to create
a 'netfs' directory in an NFS root-squash environment which will cause
the 'vol-delete' command to fail.  It's also possible error paths from
the 'vol-create' would result in an error to remove a created directory
if the permissions were incorrect (and disallowed root access).

Thus rename the virFileUnlink to be virFileRemove to match the C API
functionality, adjust the code to following using rmdir or unlink
depending on the path type, and then use/call it for the VIR_STORAGE_VOL_DIR

As far as not every call of prlsdkUUIDParse assume correct UUID
supplied, there is no use to complain about wrong format in it.
Otherwise our log is flooded with false error messages.
For instance, calling prlsdkUUIDParse from prlsdkEventsHandler
works as a filter and in case of uuid absence for event issuer,
we simply know that we shouldn't continue further processing.
Instead of error logging for all calls we should explicitly take
into accaunt where it is called from.
Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

https://bugzilla.redhat.com/show_bug.cgi?id=1159219Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

So far this function was not kept in sync with changing
virDomainDiskDef. Fill in all the missing checks and reorganize
their order so it's easier to track which items are not being
checked for.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

I always felt like this function is qemu specific rather than
libvirt-wide. Other drivers may act differently on virDomainDef
change and in fact may require talking to underlying hypervisor
even if something else's than disk->src has changed.  I know that
the function is still incomplete, but lets break that into two
commits that are easier to review. This one is pure code
movement.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Firstly, our coding guidelines suggest using 'cleanup' label
instead of 'end'. Then, @ret should be set to value representing
success as the last statement before the 'cleanup' label.
And while I am at this function, lets enumerate all the possible
enum items (virDomainDiskDevice) and avoid using 'default' in
switch(). Pooh. Also, nothing bad happens if we look up the disk
to change in the domain upfront. In fact, it's going to be
helpful later when we want to keep some old values for performing
a rollback.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This new private API should return true iff sources of two disks
differs in sense that qemu should be instructed to change the
disk backend. For instance, ejecting a CDROM is such case, or
pointing disk into a different ISO location, and so on.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

While we currently only allow changing a media in a disk, this is
going to change in a while, so the function name would be
invalid. Moreover, the old name does not match the pattern laid
out by other update functions.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

So, in 11e058ca I've tried to make UpdateDevice update
startupPolicy too. And it worked well until somebody came around
and pushed d0dc6c03 which accidentally removed my
contribution. Redo my commit.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

When persistently migrating a domain to a destination host where the
same domain already exists (i.e., it is persistent and shutdown at the
destination), we would happily throw away the original persistent
definition without properly freeing it. And when updating the definition
fails for some reason we don't properly revert to the original state
leaving the domain broken.

In addition to fixing these issues, the patch also makes sure the domain
definition parsed from a migration cookie is either used or freed.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

For quite a long time we don't need to postpone queueing events until
the end of the function since we no longer have the big driver lock.
Let's make the code of qemuMigrationFinish simpler by queuing events at
the time we generate them.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Every single call to qemuDomainEventQueue() uses the following pattern:

    if (event)
        qemuDomainEventQueue(driver, event);

Let's move the check for valid event to qemuDomainEventQueue and
simplify all callers.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Finish is the final state in v2 of our migration protocol. If something
fails, we have no option to abort the migration and resume the original
domain. Non fatal errors (such as failure to start guest CPUs or make
the domain persistent) has to be treated as success. Keeping the domain
running while reporting the failure was just asking for trouble.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Whenever something fails during incoming migration in Finish phase
before we started guest CPUs, we need to kill the domain in addition to
reporting the failure.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

When we save status XML at the point during migration where we have
already started the domain on destination, we can't really go back and
abort migration. Thus the only thing we can do is to log a warning and
report success.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Offline migration is quite special because we don't really need to do
anything but make the domain persistent. Let's do it separately from
normal migration to avoid cluttering the code with
!(flags & VIR_MIGRATE_OFFLINE).
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Separate code which makes incoming domain persistent into
qemuMigrationPersist.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

After attach-device a <hostdev> with --config, new device doesn't
show up in dumpxml and in guest.

To fix that, set dev->data.hostdev = NULL after work so that the
pointer is not freed, since vmdef has the pointer and still need it.
Signed-off-by: NChunyan Liu <cyliu@suse.com>

Tool such as libguestfs need the datacenter path to get access to disk
images. The ESX driver knows the correct datacenter path, but this
information cannot be accessed using libvirt API yet. Also, it cannot
be deduced from the connection URI in a robust way.

Expose the datacenter path in the domain XML as <vmware:datacenterpath>
node similar to the way the <qemu:commandline> node works. The new node
is ignored while parsing the domain XML. In contrast to <qemu:commandline>
it is output only.

Commit id 'f1f68ca3' added code to remove the directory paths for
auto-generated sockets, but that code could be called before the
paths were created resulting in generating error messages from
virFileDeleteTree indicating that the file doesn't exist.

Rather than "enforce" all callers to make the non-NULL and existence
checks, modify the virFileDeleteTree API to silently ignore NULL on
input and non-existent directory trees.

We have the same argument to many other commands that produce an
XML based on what user typed. But unfortunately attach-interface
was missing it. Maybe nobody had needed it yet. Well, I did
just now.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

When looking for a QEMU binary suitable for running ppc64le guests
we have to take into account the fact that we use the QEMU target
as key for the hash, so direct comparison is not good enough.

Factor out the logic from virQEMUCapsFindBinaryForArch() to a new
virQEMUCapsFindTarget() function and use that both when looking
for QEMU binaries available on the system and when looking up
QEMU capabilities later.

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