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>

Well, yet again one case of 'goto cleanup' while 'goto endjob'
was needed. Sorry.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

Since iothread_id == 0 is an invalid value for QEMU let's point
that out specifically.  For the IOThreadDel code, the failure would
have ended up being a failure to find the IOThread ID; however, for
the IOThreadAdd code - an IOThread 0 was added and that isn't good.

It seems during many reviews/edits to the code the check for
iothread_id = 0 being invalid was lost - it could have originally
been in the API code, but requested to be moved - I cannot remember.

Just like in commit 704cf06a, if virCgroup*() fails, the error is
already reported. There's no need to overwrite the error with a
generic one and possibly hiding the true root cause of the error.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>

It may happen that user (mistakenly) wants to rename a domain to
itself. Which is no renaming at all. We should reject that with
some meaningful error message.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Coverity complained that 'vm' wasn't initialized before jumping to
cleanup: and calling virDomainObjEndAPI if the VIR_STRDUP fails.
So I initialized vm = NULL and also moved the VIR_STRDUP closer to
usage and used endjob for goto. Lots of other reasons for failures.

Currently supports only renaming inactive domains without snapshots.
Signed-off-by: NTomas Meszaros <exo@tty.sk>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Pinning information returned for emulatorpin and vcpupin calls is being
returned from our data without querying cgroups for some time.  However,
not all the data were utilized.  When automatic placement is used the
information is not returned for the calls mentioned above.  Since the
numad hint in private data is properly saved/restored, we can safely use
it to return true information.

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

Well, there are just two places that needs adjustment:

qemuDomainGetInterfaceParameters - to report the @floor
qemuDomainSetInterfaceParameters - now that the function has been
fixed, we can allow updating @floor too.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

As sketched in previous commits, imagine the following scenario:

  virsh # domiftune gentoo vnet0
  inbound.average: 100
  inbound.peak   : 0
  inbound.burst  : 0
  outbound.average: 100
  outbound.peak  : 0
  outbound.burst : 0

  virsh # domiftune gentoo vnet0 --inbound 0

  virsh # shutdown gentoo
  Domain gentoo is being shutdown

  virsh # list --all
  error: Failed to list domains
  error: Cannot recv data: Connection reset by peer

  Program received signal SIGSEGV, Segmentation fault.
  0x00007fffe80ea221 in networkUnplugBandwidth (net=0x7fff9400c1a0, iface=0x7fff940ea3e0) at network/bridge_driver.c:4881
  4881            net->floor_sum -= ifaceBand->in->floor;

This is rather unfortunate. We should not SIGSEGV here. The
problem is, that while in the second step the inbound QoS was
cleared out, the network part of it was not updated (moreover, we
don't report that vnet0 had inbound.floor set). Internal
structure therefore still had some fragments left (e.g.
class_id). So when qemuProcessStop() started to clean up the
environment it got to networkUnplugBandwidth(). Here, class_id is
set therefore function assumes that there is an inbound QoS. This
actually is a fair assumption to make, there's no need for a
special QoS box in network's QoS when there's no QoS to set.
Anyway, the problem is not the networkUnplugBandwidth() rather
than qemuDomainSetInterfaceParameters() which completely forgot
about QoS being disperse (some parts are set directly on
interface itself, some on bridge the interface is plugged into).
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Qemu reports physical size 0 for block devices. As 15fa84ac
changed the behavior of qemuDomainGetBlockInfo to just query the monitor
this created a regression since we didn't report the size correctly any
more.

This patch adds code to refresh the physical size of a block device by
opening it and seeking to the end and uses it both in
qemuDomainGetBlockInfo and also in qemuDomainGetStatsOneBlock that was
broken since it was introduced in this respect.

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

If cpuset is disabled or not available, it libvirt must not use it.
Mainly for actions that do not need it and can use sched_setaffinity()
or numa_membind() instead, because they will fail without good reason.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1244664Signed-off-by: NLuyao Huang <lhuang@redhat.com>

When stopping a domain on the destination host after a failed migration,
we need to avoid reseting security labels since the domain is still
running on the source host. While we were correctly doing so in some
cases, there were still some paths which did this wrong.

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

Our atomic increment (virAtomicIntInc) uses (if available) gcc
__sync_add_and_fetch builtin. In qemu driver though, we'd profit more
from __sync_fetch_and_add builtin. To keep it simplistic, this patch
adjusts qemu driver initialization rather than adding a new atomic
increment macro.

Commit d506a51a meant to check for
QEMU_CAPS_DRIVE_IOTUNE_MAX, but checked for QEMU_CAPS_DRIVE_IOTUNE
instead.  That's clearly visible from the diff, but it got in.  Because
of that, we were supplying information unknown for QEMU if it wasn't new
enough and we couldn't even properly handle the error, leading to
"Unexpected error".  Also iops_size came at the same time with all the
other "_max" options, so check whether we're not setting that either if
QEMU_CAPS_DRIVE_IOTUNE_MAX is not supported.

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

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

We won't return the errno after commit 0d7f45ae, and
the more clearly error will be set in the code in vircgroup*.
Also We will always report error "Operation not permitted",
because the return is -1.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>

Few parts of the code looked at the current progress of and assumed that
a two phase blockjob is in the _READY state as soon as the progress
reached 100% (info.cur == info.end). In current versions of qemu this
assumption is invalid and qemu exposes a new flag 'ready' in the
query-block-jobs output that is set to true if the job is actually
finished.

This patch adds internal data handling for reading the 'ready' flag and
acting appropriately as long as the flag is present.

While this still doesn't fix the virsh client problem with two phase
block jobs and the --pivot option, it at least improves the error
message:

$ virsh blockcommit  --wait --verbose vm vda  --base vda[1] --active --pivot
Block commit: [100 %]error: failed to pivot job for disk vda
error: internal error: unable to execute QEMU command 'block-job-complete': The active block job for device 'drive-virtio-disk0' cannot be completed

to

$ virsh blockcommit  --wait --verbose VM vda  --base vda[1] --active --pivot
Block commit: [100 %]error: failed to pivot job for disk vda
error: block copy still active: disk 'vda' not ready for pivot yet

If one calls update-device with information that is not updatable,
libvirt reports success even though no data were updated.  The example
used in the bug linked below uses updating device with <boot order='2'/>
which, in my opinion, is a valid thing to request from user's
perspective.  Mainly since we properly error out if user wants to update
such data on a network device for example.

And since there are many things that might happen (update-device on disk
basically knows just how to change removable media), check for what's
changing and moreover, since the function might be usable in other
drivers (updating only disk path is a valid possibility) let's abstract
it for any two disks.

We can't possibly check for everything since for many fields our code
does not properly differentiate between default and unspecified values.
Even though this could be changed, I don't feel like it's worth the
complexity so it's not the aim of this patch.

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

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

In one of my previous ptaches (bcd9a564) I've tried to fix the problem
that we blindly assumed strict NUMA mode for guests. This led to
several problems like us pinning a domain onto a nodeset via libnuma
among with CGroups. Once the nodeset was changed by user, well, it did
not result in desired effect. See the original commit for more info.
But, the commit I wrote had a bug: when NUMA parameters are changed on
a running domain we require domain to be strictly pinned onto a
nodeset. Due to a typo a condition was mis-evaluated.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Add the sysfs_prefix argument to the call to allow for setting the
path for tests to something other than SYSFS_SYSTEM_PATH.

Add the sysfs_prefix argument to the call to allow for setting the
path for tests to something other than SYSFS_SYSTEM_PATH.

Add the sysfs_prefix argument to the call to allow for setting the
path for tests to something other than SYSFS_SYSTEM_PATH.

Add the sysfs_prefix argument to the call to allow for setting the
path for tests to something other than SYSFS_SYSTEM_PATH.