This patch introduces a new block job, useful for live storage
migration using pre-copy streaming.  Justification for including
this under virDomainBlockRebase rather than adding a new command
includes: 1) there are now two possible block jobs in qemu, with
virDomainBlockRebase starting either type of command, and
virDomainBlockJobInfo and virDomainBlockJobAbort working to end
either type; 2) reusing this command allows distros to backport
this feature to the libvirt 0.9.10 API without a .so bump.

Note that a future patch may add a more powerful interface named
virDomainBlockJobCopy, dedicated to just the block copy job, in
order to expose even more options (such as setting an arbitrary
format type for the destination without having to probe it from a
pre-existing destination file); adding a new command for targetting
just block copy would be similar to how we already have
virDomainBlockPull for targetting just the block pull job.

Using a live VM with the backing chain:
  base <- snap1 <- snap2
as the starting point, we have:

- virDomainBlockRebase(dom, disk, "/path/to/copy", 0,
    VIR_DOMAIN_BLOCK_REBASE_COPY)
creates /path/to/copy with the same format as snap2, with no backing
file, so entire chain is copied and flattened

- virDomainBlockRebase(dom, disk, "/path/to/copy", 0,
    VIR_DOMAIN_BLOCK_REBASE_COPY|VIR_DOMAIN_BLOCK_REBASE_COPY_RAW)
creates /path/to/copy as a raw file, so entire chain is copied and
flattened

- virDomainBlockRebase(dom, disk, "/path/to/copy", 0,
    VIR_DOMAIN_BLOCK_REBASE_COPY|VIR_DOMAIN_BLOCK_REBASE_SHALLOW)
creates /path/to/copy with the same format as snap2, but with snap1 as
a backing file, so only snap2 is copied.

- virDomainBlockRebase(dom, disk, "/path/to/copy", 0,
    VIR_DOMAIN_BLOCK_REBASE_COPY|VIR_DOMAIN_BLOCK_REBASE_REUSE_EXT)
reuse existing /path/to/copy (must have empty contents, and format is
probed[*] from the metadata), and copy the full chain

- virDomainBlockRebase(dom, disk, "/path/to/copy", 0,
    VIR_DOMAIN_BLOCK_REBASE_COPY|VIR_DOMAIN_BLOCK_REBASE_REUSE_EXT|
    VIR_DOMAIN_BLOCK_REBASE_SHALLOW)
reuse existing /path/to/copy (contents must be identical to snap1,
and format is probed[*] from the metadata), and copy only the contents
of snap2

- virDomainBlockRebase(dom, disk, "/path/to/copy", 0,
    VIR_DOMAIN_BLOCK_REBASE_COPY|VIR_DOMAIN_BLOCK_REBASE_REUSE_EXT|
    VIR_DOMAIN_BLOCK_REBASE_SHALLOW|VIR_DOMAIN_BLOCK_REBASE_COPY_RAW)
reuse existing /path/to/copy (must be raw volume with contents
identical to snap1), and copy only the contents of snap2

Less useful combinations:

- virDomainBlockRebase(dom, disk, "/path/to/copy", 0,
    VIR_DOMAIN_BLOCK_REBASE_COPY|VIR_DOMAIN_BLOCK_REBASE_SHALLOW|
    VIR_DOMAIN_BLOCK_REBASE_COPY_RAW)
fail if source is not raw, otherwise create /path/to/copy as raw and
the single file is copied (no chain involved)

- virDomainBlockRebase(dom, disk, "/path/to/copy", 0,
    VIR_DOMAIN_BLOCK_REBASE_COPY|VIR_DOMAIN_BLOCK_REBASE_REUSE_EXT|
    VIR_DOMAIN_BLOCK_REBASE_COPY_RAW)
makes little sense: the destination must be raw but have no contents,
meaning that it is an empty file, so there is nothing to reuse

The other three flags are rejected without VIR_DOMAIN_BLOCK_COPY.

[*] Note that probing an existing file for its format can be a security
risk _if_ there is a possibility that the existing file is 'raw', in
which case the guest can manipulate the file to appear like some other
format.  But, by virtue of the VIR_DOMAIN_BLOCK_REBASE_COPY_RAW flag,
it is possible to avoid probing of raw files, at which point, probing
of any remaining file type is no longer a security risk.

It would be nice if we could issue an event when pivoting from phase 1
to phase 2, but qemu hasn't implemented that, and we would have to poll
in order to synthesize it ourselves.  Meanwhile, qemu will give us a
distinct job info and completion event when we either cancel or pivot
to end the job.  Pivoting is accomplished via the new:

virDomainBlockJobAbort(dom, disk, VIR_DOMAIN_BLOCK_JOB_ABORT_PIVOT)

Management applications can pre-create the copy with a relative
backing file name, and use the VIR_DOMAIN_BLOCK_REBASE_REUSE_EXT
flag to have qemu reuse the metadata; if the management application
also copies the backing files to a new location, this can be used
to perform live storage migration of an entire backing chain.

* include/libvirt/libvirt.h.in (VIR_DOMAIN_BLOCK_JOB_TYPE_COPY):
New block job type.
(virDomainBlockJobAbortFlags, virDomainBlockRebaseFlags): New enums.
* src/libvirt.c (virDomainBlockRebase): Document the new flags,
and implement general restrictions on flag combinations.
(virDomainBlockJobAbort): Document the new flag.
(virDomainSaveFlags, virDomainSnapshotCreateXML)
(virDomainRevertToSnapshot, virDomainDetachDeviceFlags): Document
restrictions.
* include/libvirt/virterror.h (VIR_ERR_BLOCK_COPY_ACTIVE): New
error.
* src/util/virterror.c (virErrorMsg): Define it.

This patch modifies the CPU comparrison function to report the
incompatibilities in more detail to ease identification of problems.

* src/cpu/cpu.h:
    cpuGuestData(): Add argument to return detailed error message.
* src/cpu/cpu.c:
    cpuGuestData(): Add passthrough for error argument.
* src/cpu/cpu_x86.c
    x86FeatureNames(): Add function to convert a CPU definition to flag
                       names.
    x86Compute(): - Add error message parameter
                  - Add macro for reporting detailed error messages.
                  - Improve error reporting.
                  - Simplify calculation of forbidden flags.
    x86DataIteratorInit():
    x86cpuidMatchAny(): Remove functions that are no longer needed.
* src/qemu/qemu_command.c:
    qemuBuildCpuArgStr(): - Modify for new function prototype
                          - Add detailed error reports
                          - Change error code on incompatible processors
                            to VIR_ERR_CONFIG_UNSUPPORTED instead of
                            internal error
* tests/cputest.c:
    cpuTestGuestData(): Modify for new function prototype

commit 2223ea98 removes src/libvirt_dbus.syms, but it forgets
to remove it from EXTRA_DIST. It will cause 'make dist' failed.

virThreadSelf tries to access the virThreadPtr stored in TLS for the
current thread via TlsGetValue. When virThreadSelf is called on a thread
that was not created via virThreadCreate (e.g. the main thread) then
TlsGetValue returns NULL as TlsAlloc initializes TLS slots to NULL.

virThreadSelf can be called on the main thread via this call chain from
virsh

vshDeinit
virEventAddTimeout
virEventPollAddTimeout
virEventPollInterruptLocked
virThreadIsSelf

triggering a segfault as virThreadSelf unconditionally dereferences the
return value of TlsGetValue.

Fix this by making virThreadSelf check the TLS slot value for NULL and
setting the given virThreadPtr accordingly.

Reported by Marcel Müller.

Caused by commit 4445e16b that
made the code used the connection private data pointer before
it was initialized.

POSIX says that sa_sigaction is only safe to use if sa_flags
includes SA_SIGINFO; conversely, sa_handler is only safe to
use when flags excludes that bit.  Gnulib doesn't guarantee
an implementation of SA_SIGINFO, but does guarantee that
if SA_SIGINFO is undefined, we can safely define it to 0 as
long as we don't dereference the 2nd or 3rd argument of
any handler otherwise registered via sa_sigaction.

Based on a report by Wen Congyang.

* src/rpc/virnetserver.c (SA_SIGINFO): Stub for mingw.
(virNetServerSignalHandler): Avoid bogus dereference.
(virNetServerFatalSignal, virNetServerNew): Set flags properly.
(virNetServerAddSignalHandler): Drop unneeded #ifdef.

I almost copied-and-pasted some redundant () into my new code,
and figured a general cleanup prereq patch would be better instead.

No semantic change.

* src/conf/domain_conf.c (virDomainLeaseDefParseXML)
(virDomainDiskDefParseXML, virDomainFSDefParseXML)
(virDomainActualNetDefParseXML, virDomainNetDefParseXML)
(virDomainGraphicsDefParseXML, virDomainVideoAccelDefParseXML)
(virDomainVideoDefParseXML, virDomainHostdevFind)
(virDomainControllerInsertPreAlloced, virDomainDefParseXML)
(virDomainObjParseXML, virDomainCpuSetFormat)
(virDomainCpuSetParse, virDomainDiskDefFormat)
(virDomainActualNetDefFormat, virDomainNetDefFormat)
(virDomainTimerDefFormat, virDomainGraphicsListenDefFormat)
(virDomainDefFormatInternal, virDomainNetGetActualHostdev)
(virDomainNetGetActualBandwidth, virDomainGraphicsGetListen):
Reduce extra ().

Ensure we don't introduce any more lousy integer parsing in new
code, while avoiding a scrub-down of existing legacy code.

Note that we also need to enable sc_prohibit_atoi_atof (see cfg.mk
local-checks-to-skip) before we are bulletproof, but that also
entails scrubbing I'm not ready to do at the moment.

* src/util/util.c (virStrToLong_i, virStrToLong_ui)
(virStrToLong_l, virStrToLong_ul, virStrToLong_ll)
(virStrToLong_ull, virStrToDouble): Mark exemptions.
* src/util/virmacaddr.c (virMacAddrParse): Likewise.
* cfg.mk (sc_prohibit_strtol): New syntax check.
(exclude_file_name_regexp--sc_prohibit_strtol): Ignore files that
I'm not willing to fix yet.
(local-checks-to-skip): Re-enable sc_prohibit_atoi_atof.

https://bugzilla.redhat.com/show_bug.cgi?id=617711 reported that
even with my recent patched to allow <memory unit='G'>1</memory>,
people can still get away with trying <memory>1G</memory> and
silently get <memory unit='KiB'>1</memory> instead.  While
virt-xml-validate catches the error, our C parser did not.

Not to mention that it's always fun to fix bugs while reducing
lines of code.  :)

* src/conf/domain_conf.c (virDomainParseMemory): Check for parse error.
(virDomainDefParseXML): Avoid strtoll.
* src/conf/storage_conf.c (virStorageDefParsePerms): Likewise.
* src/util/xml.c (virXPathLongBase, virXPathULongBase)
(virXPathULongLong, virXPathLongLong): Likewise.

We were forgetting to check errno for overflow.

* tools/virsh.c (get_integer_keycode, vshCommandOptInt)
(vshCommandOptUInt, vshCommandOptUL, vshCommandOptLongLong)
(vshCommandOptULongLong): Rewrite to be safer.

Commit 78345c68 makes at least gcc 4.1.2 on RHEL 5 complain:

cc1: warnings being treated as errors
In file included from vbox/vbox_V4_0.c:13:
vbox/vbox_tmpl.c: In function 'vboxDomainUndefineFlags':
vbox/vbox_tmpl.c:5298: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]

* src/vbox/vbox_tmpl.c (vboxDomainUndefineFlags): Use union to
avoid compiler warning.

Building a fresh checkout on RHEL 5 has been broken since commit
29db7a00, due to a gnulib regression in the bootstrap script
(incremental builds from a checkout earlier than that point were
okay, though).

* .gnulib: Update to latest, for bootstrap fixes.
* bootstrap: Resync from gnulib.
* gnulib/local/top/maint.mk.diff: Drop patch that was added
upstream in the meantime.

Detected by valgrind, via Alex Jia.  Caused by imcomplete
copy-and-paste from vshWatchJob in commit 3b96a892.

* tools/virsh.c (cmdBlockPull): fix uninitialized memory usage.

* How to reproduce?
$ qemu-img create /var/lib/libvirt/images/test 1M
$ cat > /tmp/test.xml <<EOF
<domain type='qemu'>
  <name>test</name>
  <memory>219200</memory>
  <vcpu>1</vcpu>
  <os>
    <type arch='x86_64'>hvm</type>
    <boot dev='hd'/>
  </os>
  <devices>
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/images/test'/>
      <target dev='vda' bus='virtio'/>
    </disk>
    <input type='mouse' bus='ps2'/>
    <graphics type='spice' autoport='yes' listen='0.0.0.0'/>
  </devices>
</domain>
EOF
$ virsh define /tmp/test.xml
$ valgrind -v virsh blockpull test /var/lib/libvirt/images/test --wait

actual result:

==10906== 1 errors in context 1 of 1:
==10906== Syscall param rt_sigaction(act->sa_flags) points to uninitialised byte(s)
==10906==    at 0x39CF80F5BE: __libc_sigaction (sigaction.c:67)
==10906==    by 0x43016C: cmdBlockPull (virsh.c:7638)
==10906==    by 0x4150D4: vshCommandRun (virsh.c:18574)
==10906==    by 0x425E73: main (virsh.c:20178)
==10906==  Address 0x7fefffae8 is on thread 1's stack

DBus connection. The HAL device code further requires that
the DBus connection is integrated with the event loop and
provides such glue logic itself.

The forthcoming FirewallD integration also requires a
dbus connection with event loop integration. Thus we need
to pull the current event loop glue out of the HAL driver.

Thus we create src/util/virdbus.{c,h} files. This contains
just one method virDBusGetSystemBus() which obtains a handle
to the single shared system bus instance, with event glue
automagically setup.

Fix the support for trusted DHCP server in the ebtables code's
hard-coded function applying DHCP only filtering rules:
Rather than using a char * use the more flexible
virNWFilterVarValuePtr that contains the trusted DHCP server(s)
IP address. Process all entries.

Since all callers so far provided NULL as parameter, no changes
are necessary in any other code.

For threading support, add atomic add and sub operations working on
integers. Base this on locking support provided by virMutex.

Implement function to remove all entries of a hash table.

The sequence:
  long long val;
  if ((long long) val != val)
is dead code.

* src/util/util.c (virStrToLong_ll, virStrToLong_ull): Remove
useless cast.

Currently upon a migration a callback is created when a 802.1qbg link
is set to PREASSOCIATE, this should not happen because this is a no-op
on most switches, and does not lead to an ASSOCIATE state.  This patch
only creates callbacks when CREATE or RESTORE is requested.  Migration
and libvirtd restart scenarios are already handled elsewhere.
Signed-off-by: ND. Herrendoerfer <d.herrendoerfer@herrendoerfer.name>

The below patch fixes the following memory leak.

==20624== 24 bytes in 2 blocks are definitely lost in loss record 532 of 1,867
==20624==    at 0x4A05E46: malloc (vg_replace_malloc.c:195)
==20624==    by 0x38EC27FC01: strdup (strdup.c:43)
==20624==    by 0x4EB6BA3: virDomainChrSourceDefCopy (domain_conf.c:1122)
==20624==    by 0x495D76: qemuProcessFindCharDevicePTYs (qemu_process.c:1497)
==20624==    by 0x498321: qemuProcessWaitForMonitor (qemu_process.c:1258)
==20624==    by 0x49B5F9: qemuProcessStart (qemu_process.c:3652)
==20624==    by 0x468B5C: qemuDomainObjStart (qemu_driver.c:4753)
==20624==    by 0x469171: qemuDomainStartWithFlags (qemu_driver.c:4810)
==20624==    by 0x4F21735: virDomainCreate (libvirt.c:8153)
==20624==    by 0x4302BF: remoteDispatchDomainCreateHelper (remote_dispatch.h:852)
==20624==    by 0x4F72C14: virNetServerProgramDispatch (virnetserverprogram.c:416)
==20624==    by 0x4F6D690: virNetServerHandleJob (virnetserver.c:164)
==20624==    by 0x4E8F43D: virThreadPoolWorker (threadpool.c:144)
==20624==    by 0x4E8EAB5: virThreadHelper (threads-pthread.c:161)
==20624==    by 0x38EC606CCA: start_thread (pthread_create.c:301)
==20624==    by 0x38EC2E0C2C: clone (clone.S:115) 

I'm tired of shell-scripting to wait for completion of a block pull,
when virsh can be taught to do the same.  I couldn't quite reuse
vshWatchJob, as this is not a case of a long-running command where
a second thread must be used to probe job status (at least, not unless
I make virsh start doing blocking waits for an event to fire), but it
served as inspiration for my simpler single-threaded loop.  There is
up to a half-second delay between sending SIGINT and the job being
aborted, but I didn't think it worth the complexity of a second thread
and use of poll() just to minimize that delay.

* tools/virsh.c (cmdBlockPull): Add new options to wait for
completion.
(blockJobImpl): Add argument.
(cmdBlockJob): Adjust caller.
* tools/virsh.pod (blockjob): Document new mode.

Most of our errors complaining about an inability to support a
particular action due to qemu limitations used CONFIG_UNSUPPORTED,
but we had a few outliers.  Reported by Jiri Denemark.

* src/qemu/qemu_command.c (qemuBuildDriveDevStr): Prefer
CONFIG_UNSUPPORTED.
* src/qemu/qemu_driver.c (qemuDomainReboot)
(qemuDomainBlockJobImpl): Likewise.
* src/qemu/qemu_hotplug.c (qemuDomainAttachPciControllerDevice):
Likewise.
* src/qemu/qemu_monitor.c (qemuMonitorTransaction)
(qemuMonitorBlockJob, qemuMonitorSystemWakeup): Likewise.

No semantic change.

* tools/virsh.c: Fix some spacing issues, {} usage, long lines,
and redundant ().

Passing a NULL pointer to IMachine::delete virtualbox API
causes VBoxSVC to raise an assertion. This patch passes
an empty array instead.

<filesystemtgt> is redundant, as every group uses it; <address>
shouldn't be in <filesystemtgt> in case of the meaning could be
"filesystemtarget"; The elements <address>, <alias>, <target>,
... should be interleaved.

So that a domain xml which doesn't have "placement" specified, but
"cpuset" is specified, could be parsed. And in this case, the
"placement" mode will be set as "static".

Since now we have fixed domain UUID for test driver, defining
a domain with different name but same UUID doesn't work any
more. This patch delete the UUID from the dumped XML so that
it could be generated.

The objects (domain, pool, network, etc) for testing are defined/
started each time when opening a connect to test driver, and thus
the UUID for the objects will be generated each time, with different
values. e.g.

% for i in {1..3}; do ./tools/virsh --connect \
  test:///default dumpxml test | grep uuid; done
  <uuid>a1b6ee1f-97de-f0ee-617a-0cdb74947df5</uuid>
  <uuid>ee68d7d2-3eb9-593e-2769-797ce1f4c4aa</uuid>
  <uuid>fecb1d3a-918a-8412-e534-76192cf32b18</uuid>

It's the potential bug which can cause operations like below to fail:

$ virsh -c test:///default dumpxml test > test.xml

[ Some modificatons, though it's not supported, but it should work ]

$ virsh -c test:///default define test.xml

This patch set fixed UUID for objects which support it. (domain,
pool, network).

A "ide-drive" device can be either a hard disk or a CD-ROM,
if there is ",media=cdrom" specified for the backend, it's
a CD-ROM, otherwise it's a hard disk.

Upstream qemu splitted "ide-drive" into "ide-hd" and "ide-cd"
since commit 1f56e32, and ",media=cdrom" is not required for
ide-cd anymore. "ide-drive" is still supported for backwards
compatibility, but no doubt we should go foward.

A "scsi-disk" device can be either a hard disk or a CD-ROM,
if there is ",media=cdrom" specified for the backend, it's
a CD-ROM, otherwise it's a hard disk.

But upstream qemu splitted "scsi-disk" into "scsi-hd" and
"scsi-cd" since commit b443ae, and ",media=cdrom" is not
required for scsi-cd anymore. "scsi-disk" is still supported
for backwards compatibility, but no doubt we should go
foward.

If console[0] is an alias for serial[0], do not enforce the former to
have a PTY source type. This breaks serial consoles on stdio and makes
no sense.
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>

When using the xm/xend stack to manage instances there is a bug
that causes the emulated interfaces to be unusable when the vif
config contains type=ioemu.

The current code already has a special quirk to not use this
keyword if no specific model is given for the emulated NIC
(defaulting to rtl8139).
Essentially it works because regardless of the type argument,i
the Xen stack always creates emulated and paravirt interfaces and
lets the guest decide which one to use. So neither xl nor xm stack
actually require the type keyword for emulated NICs.
Signed-off-by: NStefan Bader <stefan.bader@canonical.com>

It should be 0.9.12 instead of 0.9.11

'omitted' was mispelt 'commited' twice. One of the sentences with
the typo was also missing an 'is' ('each VCPU *is* pinned to all...')
which I added in this commit while I was at it.

Currently, we have 3 boolean arguments we have to pass
to qemuProcessStart(). As libvirt grows it is harder and harder
to remember them and their position. Therefore we should
switch to flags instead.

It's vznet.conf not vznetctl.conf, see e.g.:

http://git.openvz.org/?p=vzctl;a=blob;f=bin/vznetcfg.in;h=e91f5c4a0744c1ea149e1b8c241b666052e10b12;hb=HEAD

lvcreate want's the parent pool's name, not the pool path
lvchange and lvremove want lv specified as $vgname/$lvname

This largely worked before because these commands strip off a
starting /dev. But https://bugzilla.redhat.com/show_bug.cgi?id=714986
is from a user using a 'nested VG' that was having problems.

I couldn't find any info on nested LVM and the reporter never responded,
but I reproduced with XML that specified a valid source name, and
set target path to a symlink.