Function xmlParseURI does not remove square brackets around IPv6
address when parsing. One of the solutions is making wrappers around
functions working with xmlURI*. This assures that uri->server will be
always properly assigned and it doesn't have to be changed when used
on some new place in the code.
For this purpose, functions virParseURI and virSaveURI were
added. These function are wrappers around xmlParseURI and xmlSaveUri
respectively.
Also there is one new syntax check function to prohibit these functions
anywhere else.

File changes:
 - src/util/viruri.h        -- declaration
 - src/util/viruri.c        -- definition
 - src/libvirt_private.syms -- symbol export
 - src/Makefile.am          -- added source and header files
 - cfg.mk                   -- added sc_prohibit_xmlURI
 - all others               -- ID name and include fixes

The /usr/include/python/pyconfig.h file pollutes the global
namespace with a huge number of HAVE_XXX and WITH_XXX
defines. These change what we detected in our own config.h
In particular if you try to build without DTrace, python's
headers turn it back on with predictable fail.

THe hack to workaround this is to rename WITH_DTRACE to
WITH_DTRACE_PROBES to avoid the namespace clash

It's possible to disable SPICE TLS in qemu.conf. When this happens,
libvirt ignores any SPICE TLS port or x509 directory that may have
been set when it builds the qemu command line to use. However, it's
not ignoring the secure channels that may have been set and adds
tls-channel arguments to qemu command line.
Current qemu versions don't report an error when this happens, and try to use
TLS for the specified channels.

Before this patch

<domain type='kvm'>
  <name>auto-tls-port</name>
  <memory>65536</memory>
  <os>
    <type arch='x86_64' machine='pc'>hvm</type>
  </os>
  <devices>
    <graphics type='spice' port='5900' tlsPort='-1' autoport='yes' listen='0' ke
      <listen type='address' address='0'/>
      <channel name='main' mode='secure'/>
      <channel name='inputs' mode='secure'/>
    </graphics>
  </devices>
</domain>

generates

-spice port=5900,addr=0,disable-ticketing,tls-channel=main,tls-channel=inputs

and starts QEMU.

After this patch, an error is reported if a TLS port is set in the XML
or if secure channels are specified but TLS is disabled in qemu.conf.
This is the behaviour the oVirt people (where I spotted this issue) said
they would expect.

This fixes bug #790436

This patch adds support for vmx files with empty networkName
values (which is the case for vmx generated by Workstation).
It also adds support for vmx containing NATed network interfaces.

Update test suite accordingly

[forwarding this here from RH bug #796732]

When creating a network (virsh net-create) with an erroneous XML
containing an empty <name> element, the error message is misleading:

error: Failed to create network from foo.xml
error: missing domain name information

It took me a bit of time to figure out that it was the *network* name
that was missing (I generate this xml and didn't look at it, first).

I realized that the same message is used for missing name when creating
a domain, network, or device node.

https://bugzilla.redhat.com/show_bug.cgi?id=795656 mentions
that a graceful destroy request can time out, meaning that the
error message is user-visible and should be more appropriate
than just internal error.

* src/qemu/qemu_driver.c (qemuDomainDestroyFlags): Swap error type.

Migrating domains with disks using cache != none is unsafe unless the
disk images are stored on coherent clustered filesystem. Thus we forbid
migrating such domains unless VIR_MIGRATE_UNSAFE flags is used.

This patch adds VIR_MIGRATE_UNSAFE flag for migration APIs and new
VIR_ERR_MIGRATION_UNSAFE error code.  The error code should be returned
whenever migrating a domain is considered unsafe (e.g., it's configured
in a way that does not ensure data integrity once it is migrated).
VIR_MIGRATE_UNSAFE flag may be used to force migration even though it
would normally be considered unsafe and forbidden.

AC_CHECK_PROG checks for program in given path. However, if it doesn't
exists, [variable] is set to [value-if-not-found]. We don't want this
to be the empty string in case of 'modprobe' and 'scrub' as we want to
fallback to runtime detection.

Despite documentation, if we do fork() parent always returns -1
even if file is accessible. Which is wrong obviously.

Clarify the documentation of virConnectListDomains.

Adding "Expect:" to the header list stops libcurl from sending a
Expect header at all.

Before, a dummy Expect header was added that might confuse HTTP
proxies and result in HTTP error code 417 being reported.

Previously we would have:

"os type 'hvm' & arch 'idontexist' combination is not supported"

Now we get

"No guest options available for arch 'idontexist'"

or if options available but guest OS type not applicable:

"No os type 'xen' available for arch 'x86_64'"

* src/util/virfile.h: the virFileWrapperFdFlags being defined as
  a globa variable instead of a type ended up generating a duplicate
  symbol error.
* AUTHORS: added Lincoln Myers

Improve the logging during driver initialization when testing the command
line tools.

* src/qemu/qemu_process.c (qemuFindAgentConfig): avoid crash libvirtd due to
deref a NULL pointer.

* How to reproduce?
1. virsh edit the following xml into guest configuration:
    <channel type='pty'>
      <target type='virtio'/>
    </channel>
2. virsh start <domain>

or
% virt-install -n foo -r 1024 --disk path=/var/lib/libvirt/images/foo.img,size=1 \
--channel pty,target_type=virtio -l <installation tree>
Signed-off-by: NAlex Jia <ajia@redhat.com>

When migrating a qemu domain, we enter the monitor, send some commands,
try to connect to destination qemu, send other commands, end exit the
monitor. However, if we couldn't connect to destination qemu we forgot
to exit the monitor.

Bug introduced by commit d9d518b1.

In case libvirtd cannot detect host CPU model (which may happen if it
runs inside a virtual machine), the daemon is likely to segfault when
starting a new qemu domain. It segfaults when domain XML asks for host
(either model or passthrough) CPU or does not ask for any specific CPU
model at all.

Currently, if scrub (used for wiping algorithms) is not present
at compile time, we don't support any other wiping algorithms than
zeroing, even if it was installed later. Switch to runtime detection
instead.

Bug introduced in commit 35abced2.  On an inactive domain,
$ virsh snapshot-create-as dom snap
$ virsh snapshot-create dom
$ virsh snapshot-create dom
$ virsh snapshot-delete --children dom snap
could crash libvirtd, due to a use-after-free that results
when the callback freed the current element in the iteration.

* src/conf/domain_conf.c (virDomainSnapshotForEachChild)
(virDomainSnapshotActOnDescendant): Allow iteration to delete
current child.

This patch allows libvirt to add interfaces to already
existing Open vSwitch bridges. The following syntax in
domain XML file can be used:

    <interface type='bridge'>
      <mac address='52:54:00:d0:3f:f2'/>
      <source bridge='ovsbr'/>
      <virtualport type='openvswitch'>
        <parameters interfaceid='921a80cd-e6de-5a2e-db9c-ab27f15a6e1d'/>
      </virtualport>
      <address type='pci' domain='0x0000' bus='0x00'
                          slot='0x03' function='0x0'/>
    </interface>

or if libvirt should auto-generate the interfaceid use
following syntax:

    <interface type='bridge'>
      <mac address='52:54:00:d0:3f:f2'/>
      <source bridge='ovsbr'/>
      <virtualport type='openvswitch'>
      </virtualport>
      <address type='pci' domain='0x0000' bus='0x00'
                          slot='0x03' function='0x0'/>
    </interface>

It is also possible to pass an optional profileid. To do that
use following syntax:

   <interface type='bridge'>
     <source bridge='ovsbr'/>
     <mac address='00:55:1a:65:a2:8d'/>
     <virtualport type='openvswitch'>
       <parameters interfaceid='921a80cd-e6de-5a2e-db9c-ab27f15a6e1d'
                   profileid='test-profile'/>
     </virtualport>
   </interface>

To create Open vSwitch bridge install Open vSwitch and
run the following command:

    ovs-vsctl add-br ovsbr

An upcoming patch will add a <virtualport> element to interfaces of
type='bridge', so it makes sense to give this function a more generic
name.

The current default method of terminating the qemu process is to send
a SIGTERM, wait for up to 1.6 seconds for it to cleanly shutdown, then
send a SIGKILL and wait for up to 1.4 seconds more for the process to
terminate. This is problematic because occasionally 1.6 seconds is not
long enough for the qemu process to flush its disk buffers, so the
guest's disk ends up in an inconsistent state.

Since this only occasionally happens when the timeout prior to SIGKILL
is 1.6 seconds, this patch increases that timeout to 10 seconds. At
the very least, this should reduce the occurrence from "occasionally"
to "extremely rarely". (Once SIGKILL is sent, it waits another 5
seconds for the process to die before returning).

Note that in the cases where it takes less than this for qemu to
shutdown cleanly, libvirt will *not* wait for any longer than it would
without this patch - qemuProcessKill polls the process and returns as
soon as it is gone.

This patch is based on an earlier patch by Eric Blake which was never
committed:

https://www.redhat.com/archives/libvir-list/2011-November/msg00243.html

Aside from rebasing, this patch only drops the driver lock once (prior
to the first time the function sleeps), then leaves it dropped until
it returns (Eric's patch would drop and re-acquire the lock around
each call to sleep).

At the time Eric sent his patch, the response (from Dan Berrange) was
that, while it wasn't a good thing to be holding the driver lock while
sleeping, we really need to rethink locking wrt the driver object,
switching to a finer-grained approach that locks individual items
within the driver object separately to allow for greater concurrency.

This is a good plan, and at the time it made sense to not apply the
patch because there was no known bug related to the driver lock being
held in this function.

However, we now know that the length of the wait in qemuProcessKill is
sometimes too short to allow the qemu process to fully flush its disk
cache before SIGKILL is sent, so we need to lengthen the timeout (in
order to improve the situation with management applications until they
can be updated to use the new VIR_DOMAIN_DESTROY_GRACEFUL flag added
in commit 72f8a7f1). But, if we
lengthen the timeout, we also lengthen the amount of time that all
other threads in libvirtd are essentially blocked from doing anything
(since just about everything needs to acquire the driver lock, if only
for long enough to get a pointer to a domain).

The solution is to modify qemuProcessKill to drop the driver lock
while sleeping, as proposed in Eric's patch. Then we can increase the
timeout with a clear conscience, and thus at least lower the chances
that someone running with existing management software will suffer the
consequence's of qemu's disk cache not being flushed.

In the meantime, we still should work on Dan's proposal to make
locking within the driver object more fine grained.

(NB: although I couldn't find any instance where qemuProcessKill() was
called with no jobs active for the domain (or some other guarantee
that the current thread had at least one refcount on the domain
object), this patch still follows Eric's method of temporarily adding
a ref prior to unlocking the domain object, because I couldn't
convince myself 100% that this was the case.)

via user agent. Allow targets mem & hybrid iff system_wakeup
monitor command is available.

In the future (my next patch in fact) we may want to make
decisions depending on qemu having a monitor command or not.
Therefore, we want to set qemuCaps flag instead of querying
on the monitor each time we are about to make that decision.

When blkdeviotune was first committed in 0.9.8, we had the limitation
that setting one value reset all others.  But bytes and iops should
be relatively independent.  Furthermore, setting tuning values on
a live domain followed by dumpxml did not output the new settings.

* src/qemu/qemu_driver.c (qemuDiskPathToAlias): Add parameter, and
update callers.
(qemuDomainSetBlockIoTune): Don't lose previous unrelated
settings.  Make live changes reflect to dumpxml output.
* tools/virsh.pod (blkdeviotune): Update documentation.

Some programs, notably dnsmasq, which are writing pidfiles on their
own do append a whitespace character after pid, e.g. '\n'.

This reverts commit 7b345b69.

Conflicts:

	tests/qemuxml2argvdata/qemuxml2argv-disk-scsi-vscsi.xml

This reverts commit c9abfadf.

Conflicts:

	tests/qemuxml2argvdata/qemuxml2argv-disk-scsi-virtio-scsi.xml

Replace calls to fwrite() and fscanf() with more portable-friendly
version, such as snprintf() and virStrToLong().

It breaks the build on Mingw32,  because PRIx64 is coming
from the Win32 headers, but virAsprintf uses the gnulib printf.

Detected by valgrind. Leaks are introduced in commit c1b22644.

* src/remote/remote_driver.c (doRemoteOpen): free client program memory in failure path.

* How to reproduce?
% valgrind -v --leak-check=full virsh -c qemu:

* Actual result

==3969== 40 bytes in 1 blocks are definitely lost in loss record 8 of 28
==3969==    at 0x4A04A28: calloc (vg_replace_malloc.c:467)
    ==3969==    by 0x4C89C41: virAlloc (memory.c:101)
    ==3969==    by 0x4D5A236: virNetClientProgramNew (virnetclientprogram.c:60)
    ==3969==    by 0x4D47AB4: doRemoteOpen (remote_driver.c:658)
    ==3969==    by 0x4D49FFF: remoteOpen (remote_driver.c:871)
    ==3969==    by 0x4D13373: do_open (libvirt.c:1196)
    ==3969==    by 0x4D14535: virConnectOpenAuth (libvirt.c:1422)
    ==3969==    by 0x425627: main (virsh.c:18537)
    ==3969==
    ==3969== 40 bytes in 1 blocks are definitely lost in loss record 9 of 28
    ==3969==    at 0x4A04A28: calloc (vg_replace_malloc.c:467)
    ==3969==    by 0x4C89C41: virAlloc (memory.c:101)
    ==3969==    by 0x4D5A236: virNetClientProgramNew (virnetclientprogram.c:60)
    ==3969==    by 0x4D47AD7: doRemoteOpen (remote_driver.c:664)
    ==3969==    by 0x4D49FFF: remoteOpen (remote_driver.c:871)
    ==3969==    by 0x4D13373: do_open (libvirt.c:1196)
    ==3969==    by 0x4D14535: virConnectOpenAuth (libvirt.c:1422)
    ==3969==    by 0x425627: main (virsh.c:18537)
    ==3969==
    ==3969== LEAK SUMMARY:
    ==3969==    definitely lost: 80 bytes in 2 blocks
Signed-off-by: NAlex Jia <ajia@redhat.com>

The auto-generated WWN comply with the new addressing schema of WWN:

<quote>
the first nibble is either hex 5 or 6 followed by a 3-byte vendor
identifier and 36 bits for a vendor-specified serial number.
</quote>

We choose hex 5 for the first nibble. And for the 3-bytes vendor ID,
we uses the OUI according to underlying hypervisor type, (invoking
virConnectGetType to get the virt type). e.g. If virConnectGetType
returns "QEMU", we use Qumranet's OUI (00:1A:4A), if returns
ESX|VMWARE, we use VMWARE's OUI (00:05:69). Currently it only
supports qemu|xen|libxl|xenapi|hyperv|esx|vmware drivers. The last
36 bits are auto-generated.

Some audit records generated by libvirt contain fields enclosed by single
quotes. Since those fields are inside the msg field, which is enclosed by
single quotes, these records generated by libvirt are not correctly parsed by
libauparse.

Bug introduced in commit c6ec021b.
Signed-off-by: NLai Jiangshan <laijs@cn.fujitsu.com>

Some tools, such as virt-manager, prefers having the default USB
controller explicit in the XML document. This patch makes sure there
is one. With this patch, it is now possible to switch from USB1 to
USB2 from the release 0.9.1 of virt-manager.

Fix tests to pass with this change.

romfile wasn't mentioned in the comment, and the fact that rombar is
now supported for network interfaces also wasn't there.