Introduce virStoragePoolSaveState to properly format the state XML in
the same manner as virStoragePoolDefFormat, except for adding a
<poolstate> ... </poolstate> around the definition. This is similar to
virNetworkObjFormat used to save the live/active network information.

When modifying config/status XML, it might be handy to include some
additional XML elements (e.g. <poolstate>). In order to do so,
introduce new formatting function virStoragePoolDefFormatBuf and make
virStoragePoolDefFormat call it.

Recent testing on large memory systems revealed a bug in the Xen xl
tool's freemem() function.  When autoballooning is enabled, freemem()
is used to ensure enough memory is available to start a domain,
ballooning dom0 if necessary.  When ballooning large amounts of memory
from dom0, freemem() would exceed its self-imposed wait time and
return an error.  Meanwhile, dom0 continued to balloon.  Starting the
domain later, after sufficient memory was ballooned from dom0, would
succeed.  The libvirt implementation in libxlDomainFreeMem() suffers
the same bug since it is modeled after freemem().

In the end, the best place to fix the bug on the Xen side was to
slightly change the behavior of libxl_wait_for_memory_target().
Instead of failing after caller-provided wait_sec, the function now
blocks as long as dom0 memory ballooning is progressing.  It will return
failure only when more memory is needed to reach the target and wait_sec
have expired with no progress being made.  See xen.git commit fd3aa246.
There was a dicussion on how this would affect other libxl apps like
libvirt

http://lists.xen.org/archives/html/xen-devel/2015-03/msg00739.html

If libvirt containing this patch was build against a Xen containing
the old libxl_wait_for_memory_target() behavior, libxlDomainFreeMem()
will fail after 30 sec and domain creation will be terminated.
Without this patch and with old libxl_wait_for_memory_target() behavior,
libxlDomainFreeMem() does not succeed after 30 sec, but returns success
anyway.  Domain creation continues resulting in all sorts of fun stuff
like cpu soft lockups in the guest OS.  It was decided to properly fix
libxl_wait_for_memory_target(), and if anything improve the default
behavior of apps using the freemem reference impl in xl.

xl was patched to accommodate the change in libxl_wait_for_memory_target()
with xen.git commit 883b30a0.  This patch does the same in the libxl
driver.  While at it, I changed the logic to essentially match
freemem() in $xensrc/tools/libxl/xl_cmdimpl.c.  It was a bit cleaner
IMO and will make it easier to spot future, potentially interesting
divergences.

Dependant is flagged as wrong in US dictionary (only valid in UK
dictionary, and even then, it has only the financial sense and not the
inter-relatedness sense that we are more prone to be wanting throughout
code).
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Reported-by: NPeter Phaal <peter.phaal@gmail.com>
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

'virPCIDeviceList' is actually an array. Removing one element makes the
rest of the element move.

Use while loop, increase index only when not virPCIDeviceListDel(pcidevs, dev)
Signed-off-by: NHuanle Han <hanxueluo@gmail.com>

Commit cd5dc303 added this test, but it fails if
LIBXL_HAVE_BUILDINFO_USBDEVICE_LIST is not defined:

6) Xen XM-2-XML Format fullvirt-multiusb
... libvirt:  error : unsupported configuration: multiple USB
devices not supported
FAILED

In virDomainVirtioSerialAddrNext, add another controller
if we've exhausted all ports of the existing controllers.

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

Instead of always using controller 0 and incrementing port number,
respect the maximum port numbers of controllers and use all of them.

Ports for virtio consoles are quietly reserved, but not formatted
(neither in XML nor on QEMU command line).

Also rejects duplicate virtio-serial addresses.
https://bugzilla.redhat.com/show_bug.cgi?id=890606
https://bugzilla.redhat.com/show_bug.cgi?id=1076708

Test changes:
* virtio-auto.args
  Filling out the port when just the controller is specified.
  switched from using
    maxport + 1
  to:
    first free port on the controller
* virtio-autoassign.args
  Filling out the address when no <address> is specified.
  Started using all the controllers instead of 0, also discards
  the bus value.
* xml -> xml output of virtio-auto
  The port assignment is no longer done as a part of XML parsing,
  so the unspecified values stay 0.

Create a sorted array of virtio-serial controllers.
Each of the elements contains the controller index
and a bitmap of available ports.

Buses are not tracked, because they aren't supported by QEMU.

Add a test to demonstrate the effect of automatic virtio-serial
address assignment.

Seems to be a remnant that was never cleaned up from original submit...
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

If the call to virStorageBackendISCSIGetHostNumber failed, we set
retval = -1, but yet still called virStorageBackendSCSIFindLUs.
Need to add a goto cleanup - while at it, adjust the logic to
initialize retval to -1 and only changed to 0 (zero) on success.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Don't supercede the error message virStorageBackendSCSIFindLUs as the
message such as "error: Failed to find LUs on host 60: ..." is not overly
clear as to what the real problem might be.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Make XML definition saving more generic by moving the common code into
virStoragePoolSaveXML and leave case specific code to
PoolSave{Status,Config,...} functions.

In order to be able to use 'checkPool' inside functions which do not
have any connection reference, 'conn' attribute needs to be discarded
from the checkPool's signature, since it's not used by any storage backend
anyway.

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

As described in virDomainBlockCopy() parameters description, the
VIR_DOMAIN_BLOCK_COPY_GRANULARITY parameter may require the value to
have some specific attributes (e.g. be a power of two or fall within a
certain range). And in qemu, a power of two is required. However, our
code does not check that and let qemu operation fail. Moreover, the
virsh man page is not as exact as it could be in this respect.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The 7c3c7f21 and f5c2d6 commits introduced a nodeinfo test.
In order to do that, some parts of sysfs had to be copied.
However, sysfs is full of symlinks, so during copying some
symlinks broke. Remove them, as on different systems they can
point to different files or be broken. At the same time, we don't
need all files added in those commits. For instance we don't care
about 'uevent' files, 'power' folders, and others.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

When we shutdown/reboot a guest using agent-mode, if the guest itself blocks infinitely,
libvirt would block in qemuAgentShutdown() forever.
Thus, we set a timeout for shutdown/reboot, from our experience, 60 seconds would be fine.
Signed-off-by: NZhang Bo <oscar.zhangbo@huawei.com>
Signed-off-by: NWang Yufei <james.wangyufei@huawei.com>

Copied from the vcpupin command, which has two modes of operation.

virDomainHasDiskMirror() currently detects only jobs that add the mirror
elements. Since some operations like migration are interlocked by
existing block jobs on the given domain the check needs to be
instrumented to check regular jobs too.

This patch renames virDomainHasDiskMirror to virDomainHasDiskBlockjob
and adds an argument that allows to select that it returns true only for
block copy jobs as those interlock making the domain persistent.

Other two uses trigger on any block job type.
Signed-off-by: NShanzhi Yu <shyu@redhat.com>
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

If any disk of a VM was involved in a (copy) block job we refused to do
a snapshot. As not only copy jobs interlock snapshots and the
interlocking is applicable to individual disks only we can make the
check in a more individual fashion and interlock all block job types
supported by libvirt.

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

Include them in the files that need them instead.

After splitting out most of virsh command, some includes
are no longer needed.

Some files have the libXML includes despite not needing them.

* "verify.h" from gnulib is included in internal.h
* <sys/select.h> is no longer needed
  added by commit da196338 to use fd_set in virExec prototype

No longer needed after commit dd477238

Unused since commit bc2f42a0.

Move it under the WITHOUT_DRIVER_MODULES #ifdef
and start using it again.

In the order of appearance:

* MAX_LISTEN - never used
  added by 23ad665c (qemud) and addec57 (lock daemon)

* NEXT_FREE_CLASS_ID - never used, added by 07d1b6b5

* virLockError - never used, added by eb8268a4

* OPENVZ_MAX_ARG, CMDBUF_LEN, CMDOP_LEN
  unused since the removal of ADD_ARG_LIT in d8b31306

* QEMU_NB_PER_CPU_STAT_PARAM - unused since 897808e7

* QEMU_CMD_PROMPT, QEMU_PASSWD_PROMPT - unused since 1dc10a7b

* TEST_MODEL_WORDSIZE - unused since c25c18f7

* TEMPDIR - never used, added by 714bef5b

* NSIG - workaround around old headers
  added by commit 60ed1d2a
  unused since virExec was moved by commit 02e86910

* DO_TEST_PARSE - never used, added by 9afa0060

* DIFF_MSEC, GETTIMEOFDAY - unused since eee6eb66

Use virBitmapNewCopy instead of a combination of virBitmapNew and
virBitmapCopy.

The function doesn't make sense. There's a simpler way to achieve the
same.

The function doesn't make sense. There's a simpler way to achieve the
same.

The function is used to set cpuset.cpus in various other helpers.

Two places would call to qemuPrepareCpumap() with priv->autoNodeset to
convert it to a cpuset. Remove the function and use the prepared cpuset
automatically.

When the default cpuset or automatic numa placement is used libvirt
would place the whole parent cgroup in the specified cpuset. This then
disallowed to re-pin the vcpus to a different cpu.

This patch pins only the vcpu threads to the default cpuset and thus
allows to re-pin them later.

The following config would fail to start:
<domain type='kvm'>
  ...
  <vcpu placement='static' cpuset='0-1' current='2'>4</vcpu>
  <cputune>
    <vcpupin vcpu='0' cpuset='2-3'/>
    ...

This is a regression since a39f69d2.

Use the default or auto cpuset if they are provided for IOThreads.

The automatic cpuset can be stored along with automatic nodeset and it
does not have to be recreated when used.