Let the function report errors internally and change it to return
standard return codes.

The cpu hotplug helper functions used negative error handling in a part
of them, although some code that was added later didn't properly set the
error codes in some cases. This would cause improper error messages in
cases where we couldn't modify the numa cpu mask and a few other cases.

Fix the logic by converting it to the regularly used pattern.

There's only very little common code among the two operations. Split the
functions so that the internals are easier to understand and refactor
later.

With a very unfortunate timing, the agent might vanish before we do the
second call while the locks were down. Re-check that the agent is
available before attempting it again.

Separate the code so that qemuDomainSetVcpusFlags contains only code
relevant to hardware hotplug/unplug.

Finalize the refactor by adding the 'virDomainDefGetVCpusMax' getter and
reusing it accross libvirt.

The code can be unified into the new accessor rather than being
scattered accross the drivers.

To support further refactors replace all write access to def->maxvcpus
with a accessor function.

The qemuDomainTaint APIs currently expect to be passed a log file
descriptor. Change them to instead use a qemuDomainLogContextPtr
to hide the implementation details.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The rename operation only works on inactive virtual machines,
but it none the less writes to the log file used by the QEMU
processes. This log file is not intended to provide a general
purpose audit trail of operations performed on VMs. The audit
subsystem has recording of important operations. If we want
to extend that to cover all significant public APIs that is
a valid thing to consider, but we shouldn't arbitrarily log
specific APIs into the QEMU log file in the meantime.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

We only started an async job for incoming migration from another host.
When we were starting a domain from scratch or restoring from a saved
state (migration from file) we didn't set any async job. Let's introduce
a new QEMU_ASYNC_JOB_START for these cases.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Make callers of qemuBuildCommandLine responsible for providing the URI
which should be passed as a parameter for -incoming.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

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

Commit id '9deb96f9' removed the code to fetch the nodeset from the
CpusetMems cgroup for a running vm in favor of using the return from
virDomainNumatuneFormatNodeset introduced by commit id '43b67f2e'.
However, that API will return the value of the passed 'auto_nodeset'
when placement is VIR_DOMAIN_NUMATUNE_PLACEMENT_AUTO, which happens
to be NULL.

Since commit id 'c74d58ad' started using priv->autoNodeset in order
to manage the auto placement value during qemuProcessStart, it should
be passed along in order to return the correct value if the domain
requests the auto placement.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>

Although theoretically both should be the same value, the niothreadids
should be used in favor of iothreads when performing comparisons. This
leaves the iothreads as a purely numeric value to be saved in the config
file.  The one exception to the rule is virDomainIOThreadIDDefArrayInit
where the iothreadids are being generated from the iothreads count since
iothreadids were added after initial iothreads support.

So imagine you want to crate new security manager:

  if (!(mgr = virSecurityManagerNew("selinux", "QEMU", false, true, false, true)));

Hard to parse, right? What about this:

  if (!(mgr = virSecurityManagerNew("selinux", "QEMU",
                                    VIR_SECURITY_MANAGER_DEFAULT_CONFINED |
                                    VIR_SECURITY_MANAGER_PRIVILEGED)));

Now that's better! This is what the commit does.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Use the migration @flags for checking various migration aspects rather
than picking them out as booleans. Document the new semantics in the
function header.

Now that qemuMigrationIsAllowed is always called with @vm, we can drop
the @def argument and simplify the control flow.

Additionally the comment is invalid so drop it.

Commit 307fb904 (Sep 10) added a 'privileged' variable when creating
the DAC driver:

@@ -153,6 +157,7 @@ virSecurityManagerNewDAC(const char *virtDriver,
                          bool defaultConfined,
                          bool requireConfined,
                          bool dynamicOwnership,
+                         bool privileged,
                          virSecurityManagerDACChownCallback chownCallback)

But argument order is mixed up at the caller, swapping dynamicOwnership
and privileged values. This corrects the argument order

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

This seemed to be more of a false positive as for some reason Coverity
was missing the "ret < 0" goto error condition and somehow believing that
event could be overwritten.  At first I thought it was just the ret != 0
condition difference, but it wasn't.

In any case, make use of the recent change to qemuDomainEventQueue to
check event == NULL and just pass it as a parameter directly in the
error path. That avoids the error.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

As it turns out, ret can only be 0 or -1, so rather than have some comparisons
be "ret < 0" and others be "ret != 0", make them all "ret < 0".

So while working on my previous patches, I've noticed that
virDomainRestore implementation in qemu and test drivers has the
same problem as I am fixing.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

So far we have the following pattern occurring over and over
again:

  if (!vm->persistent)
      qemuDomainRemoveInactive(driver, vm);

It's safe to put the check into the function and save some LoC.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

So, you want to create a domain from XML. The domain already
exists in libvirt's database of domains. It's okay, because name
and UUID matches. However, on domain startup, internal
representation of the domain is overwritten with your XML even
though we claim that the XML you've provided is a transient one.
The bug is to be found across nearly all the drivers.
Le sigh.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

Okay, so we allow users to 'virsh create' an already existing
domain, providing completely different XML than the one stored in
Libvirt. Well, as long as name and UUID matches. However, in some
drivers the code that handles errors unconditionally removes the
domain that failed to start even though the domain might have
been persistent. Fortunately, the domain is removed just from the
internal list of domains and the config file is kept around.

Steps to reproduce:

1) virsh dumpxml $dom > /tmp/dom.xml
2) change XML so that it is still parse-able but won't boot, e.g.
change guest agent path to /foo/bar
3) virsh create /tmp/dom.xml
4) virsh dumpxml $dom
5) Observe "No such domain" error
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

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.

https://bugzilla.redhat.com/show_bug.cgi?id=1159219Signed-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>

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>

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>

We may want to do some decisions in drivers based on fact if we
are running as privileged user or not. Propagate this info there.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This reverts commit 1ce7c1d2,
which introduced a significant semantic change to the
virDomainGetInfo() API. Additionally, the change was only
made to 2 of the 15 virt drivers.

Conflicts:
	src/qemu/qemu_driver.c
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

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

Make a call virCgroupGetBlkioWeight to re-read blkio.weight right
after it is set in order to keep internal data up-to-date.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>

We will try to set the node to cpuset.mems without check if
it is available, since we already have helper to check this.
Call virNumaNodesetIsAvailable to check if node is available,
then try to change it in the cgroup.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>

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

The problem here is that there are some values that kernel accepts, but
does not set them, for example 18446744073709551615 which acts the same
way as zero.  Let's do the same thing we do with other tuning options
and re-read them right after they are set in order to keep our internal
structures up-to-date.

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