* src/qemu/qemu_monitor_text.h (qemuMonitorTextMigrate): Declare
in place of individual monitor commands.
* src/qemu/qemu_monitor_json.h (qemuMonitorJSONMigrate): Likewise.
* src/qemu/qemu_monitor_text.c (qemuMonitorTextMigrateToHost)
(qemuMonitorTextMigrateToCommand, qemuMonitorTextMigrateToFile)
(qemuMonitorTextMigrateToUnix): Delete.
* src/qemu/qemu_monitor_json.c (qemuMonitorJSONMigrateToHost)
(qemuMonitorJSONMigrateToCommand, qemuMonitorJSONMigrateToFile)
(qemuMonitorJSONMigrateToUnix): Delete.
* src/qemu/qemu_monitor.c (qemuMonitorMigrateToHost)
(qemuMonitorMigrateToCommand, qemuMonitorMigrateToFile)
(qemuMonitorMigrateToUnix): Consolidate shared code.

Outgoing migration still uses a Unix socket and or exec netcat until
the next patch.

* src/qemu/qemu_migration.c (qemuMigrationPrepareTunnel):
Replace Unix socket with simpler pipe.
Suggested by Paolo Bonzini.

Commit 7f193757 renamed libvirt-guests.init from .in to .sh, which
made it slip past sc_TAB_in_indentation.  I nearly reintroduced a
tab, so I'm pushing this to prevent that from happening.

* cfg.mk (sc_TAB_in_indentation): Update rule to include .sh files.
* .dir-locals.el: List spacing preference for .sh files.

As perhaps other hypervisor drivers use different capacity units,
do the checking in qemu driver instead of in conf/domain_conf.c.

This patch changes zerobuf variable from array to VIR_ALLOC_N().
Signed-off-by: NMinoru Usui <usui@mxm.nes.nec.co.jp>

* tools/libvirt-guests.init.sh (start, stop, gueststatus): Avoid
shell globbing, since valid URIs can contain '?'.

At least protect the $uri variable against further expansion by properly
quoting it. While doing that, also quote all other variables to protect
against shell meta characters.
Signed-off-by: NPhilipp Hahn <hahn@univention.de>

Not "Programmable Interrupt Controller" but "Peripheral Component
Interconnect".
Signed-off-by: NPhilipp Hahn <hahn@univention.de>

The newly added call to qemuAuditNetDevice in qemuPhysIfaceConnect was
assuming that res_ifname (the name of the macvtap device) was always
valid, but this isn't the case. If openMacvtapTap fails, it always
returns NULL, which would result in a segv.

Since the audit log only needs a record of devices that are actually
sent to qemu, and a failure to open the macvtap device means that no
device will be sent to qemu, we can solve this problem by only doing
the audit if openMacvtapTap is successful (in which case res_ifname is
guaranteed valid).

in case of incorrect option parsing.

Normally dnsmasq will send a default route (the address of the host in
the network definition) to any client requesting an address via
DHCP. On an isolated network this makes no sense, as we have iptables
to prevent any traffic going out via that interface, so anything sent
that way would be dropped anyway.

This extra/unusable default route becomes problematic if you have
setup a guest with multiple network interfaces, with one connected to
an isolated network and another that provides connectivity to the
outside (example - one interface directly connecting to a physical
interface via macvtap, with a second connected to an isolated network
so that the host and guest can communicate (macvtap doesn't support
guest<->host communication without an external switch that supports
vepa, or reflecting all traffic back)). In this case, if the guest
chooses the default route of the isolated network, the guest will not
be able to get network traffic beyond the host.

To prevent dnsmasq from sending a default route, you can tell it to
send 0 bytes of data for the default route option (option number 3)
with --dhcp-option=3 (normally the data to send for the option would
follow the option number; no extra data means "don't send this option").

I have checked on RHEL5 (a good representative of the oldest supported
libvirt platforms) and its version of dnsmasq (2.45) does support
--dhcp-option, so this shouldn't create any compatibility problems.

This partially reverts (and fixes that part in a different way) commit
e4384459, which replaced
``/usr/bin/python'' with ``/usr/bin/env python'' in all examples or
scripts used during build to generate other files.

However, python bindings module is compiled and linked against a
specific python discovered or explicitly provided in configure phase.
Thus libvirt.py, which is generated and installed into the system,
should use the same python binary for which the module has been built.

The hunk in Makefile.am replaces $(srcdir) with $(PYTHON), which might
seem wrong but it is not. generator.py didn't use any of its command
line arguments so passing $(srcdir) to it was redundant.

Otherwise connection of hypervisor driver will be leaked when
one shutdown the guest in console. e.g.

[root@localhost]# init 0
......
init: Re-executing /sbin/init
Halting system...
Power down.

error: Failed to disconnect from the hypervisor, 1 leaked reference(s)

As pointed on CVE-2011-1146, some API forgot to check the read-only
status of the connection for entry point which modify the state
of the system or may lead to a remote execution using user data.
The entry points concerned are:
  - virConnectDomainXMLToNative
  - virNodeDeviceDettach
  - virNodeDeviceReAttach
  - virNodeDeviceReset
  - virDomainRevertToSnapshot
  - virDomainSnapshotDelete

* src/libvirt.c: fix the above set of entry points to error on read-only
                 connections

By default, all dnsmasq processes share the same leases file. libvirt
also uses the --dhcp-lease-max option to control the maximum number of
leases allowed. The problem is that libvirt puts in a number equal to
the number of addresses in the range for the one network handled by a
single instance of dnsmasq, but dnsmasq checks the total number of
leases in the file (which could potentially contain many more).

The solution is to tell each instance of dnsmasq to create and use its
own leases file. (/var/lib/libvirt/network/<net-name>.leases).

This file is created by dnsmasq when it starts, but not deleted when
it exists. This is fine when the network is just being stopped, but if
the leases file was left around when a network was undefined, we could
end up with an ever-increasing number of dead files - instead, we
explicitly unlink the leases file when a network is undefined.

Note that Ubuntu carries a patch against an older version of libvirt for this:

hhttps://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/713071
ttp://bazaar.launchpad.net/~serge-hallyn/ubuntu/maverick/libvirt/bugall/revision/109

I was certain I'd also seen discussion of this on libvir-list or
libvirt-users, but couldn't find it.

The previous commit put a large portion of networkBuildDnsmasqArgv
inside an if { } block. This readjusts the indentation.

This fixes a regression introduced in commit ad48df, and reported on
the libvirt-users list:

  https://www.redhat.com/archives/libvirt-users/2011-March/msg00018.html

The problem in that commit was that we began searching a list of ip
address definitions (rather than just having one) to look for a dhcp
range or static host; when we didn't find any, our pointer (ipdef) was
left at NULL, and when ipdef was NULL, we returned without starting up
dnsmasq.

Previously dnsmasq was started even without any dhcp ranges or static
entries, because it's still useful for DNS services.

Another problem I noticed while investigating was that, if there are
IPv6 addresses, but no IPv4 addresses of any kind, we would jump out
at an ever higher level in the call chain.

This patch does the following:

1) networkBuildDnsmasqArgv() = all uses of ipdef are protected from
   NULL dereference. (this patch doesn't change indentation, to make
   review easier. The next patch will change just the
   indentation). ipdef is intended to point to the first IPv4 address
   with DHCP info (or the first IPv4 address if none of them have any
   dhcp info).

2) networkStartDhcpDaemon() = if the loop looking for an ipdef with
   DHCP info comes up empty, we then grab the first IPv4 def from the
   list. Also, instead of returning if there are no IPv4 defs, we just
   return if there are no IP defs at all (either v4 or v6). This way a
   network that is IPv6-only will still get dnsmasq listening for DNS
   queries.

3) in networkStartNetworkDaemon() - we will startup dhcp not just if there
   are any IPv4 addresses, but also if there are any IPv6 addresses.

VIR_DOMAIN_MEMORY_PARAM_UNLIMITED uses INT64_MAX but stdint.h
was not and should not be included. Therefore, libvirt.h was
not self-contained.

Instead of including stdint.h specify the value directly.

awk splits the line on consecutive spaces, which breaks getting the name
of a domain whose name contains spaces. Use sed instead to strip the
"Name:" prefix from the line
Signed-off-by: NPhilipp Hahn <hahn@univention.de>

The Relax-NG schema for domains regarding <hostdev> doesn't match what's
implemented in src/conf/domain_conf.c#virDomainHostdevDefFormat(): The
implementation only requires @type, but the schema currently either
required none or all three attributes (@mode, @type, and @managed) to be
defined together, because they are declared in the same
<optional)-section. (@managed is currently even undocumented on
<http://libvirt.org/formatdomain.html#elementsUSB>).

Thus the following minimal <hostdev>-example fails to validate:
<domain type='test'>
        <name>N</name>
        <memory>4096</memory>
        <bootloader>/bin/false</bootloader>
        <os>
                <type arch='x86_64' machine='xenpv'>linux</type>
        </os>
        <devices>
                <hostdev type='pci'>
                        <source>
                                <address bus='0x06' slot='0x00' function='0x0'/>
                        </source>
                </hostdev>
        </devices>
</domain>

The schema is changed to match the current implementation:
1. @mode is optional (which defaults to 'subsystem')
2. @type is required
3. @managed is optional (which defaults to 'no')

The documentation is updated to mention @managed.
Signed-off-by: NPhilipp Hahn <hahn@univention.de>

* src/qemu/qemu_command.c (qemuBuildCommandLine): Pass two
separate arguments, and fix indentation.

* docs/formatdomain.html.in: Fix typo in last patch.
Reported by Matthias Bolte.

Currently a single storage volume with a broken backing file will disable the
whole storage pool. This can happen when the backing file is on some
unavailable network storage or if the backing volume is deleted, while the
storage volumes using it remain.
Since the storage pool can not be re-activated, re-creating the missing
or deleting the now useless volumes using libvirt only is not possible.

Fixing this is a little bit tricky:
1. virStorageBackendProbeTarget() only detects the missing backing file,
   if the backing file format is not explicitly specified. If the
   backing file is created using
	   kvm-img create -f qcow2 -o backing_fmt=qcow2,backing_file=... ...
   no error is detected at this stage.
   The new return code -3 signals that the backing file could not be
   opened.
2. The backingStore.format must be >= 0, since values < 0 would break
   virStorageVolTargetDefFormat() when dumping the XML data such as
       <format type='...'/>
   Because of this the format is faked as VIR_STORAGE_FILE_RAW.
3. virStorageBackendUpdateVolTargetInfo() always opens the backing file
   and thus always detects a missing backing file.
   Since it "only" updates the capacity, allocation, owner, group, mode
   and SELinux label, just ignore errors at this stage, print an error
   message and continue.
4. Using vol-dump on a broken volume still doesn't work, but at least
   vol-destroy and pool-refresh do work now.

To reproduce:
  dir=$(mktemp -d)
  virsh pool-create-as tmp dir '' '' '' '' "$dir"
  virsh vol-create-as --format qcow2 tmp back 1G
  virsh vol-create-as --format qcow2 --backing-vol-format qcow2 --backing-vol back tmp cow 1G
  virsh vol-delete --pool tmp back
  virsh pool-refresh tmp
After the last step, the pool will be gone (because it was not persistent). As
long as the now broken image stays in the directory, you will not be able to
re-create or re-start the pool.
Signed-off-by: NPhilipp Hahn <hahn@univention.de>

This patchs adds documentation about the 802.1Qbg related parameters
of the virtualport element in a 'direct' interface definition.
Signed-off-by: NGerhard Stenzel <gerhard.stenzel@de.ibm.com>

Remote protocol implementation of virDomainSetBlkioParameters and virDomainGetBlkioParameters.
Signed-off-by: NGui Jianfeng <guijianfeng@cn.fujitsu.com>

Adding blkiotune command to virsh tool
Signed-off-by: NGui Jianfeng <guijianfeng@cn.fujitsu.com>

Implement domainSetBlkioParameters and domainGetBlkioParameters for QEmu
Signed-off-by: NGui Jianfeng <guijianfeng@cn.fujitsu.com>

Implements virDomainSetBlkioParameters and virDomainGetBlkioParameters and initialization
Signed-off-by: NGui Jianfeng <guijianfeng@cn.fujitsu.com>

Add virDomainSetBlkioParameters virDomainGetBlkioParameters
Signed-off-by: NGui Jianfeng <guijianfeng@cn.fujitsu.com>

This patch adds the new options (--live and --config)  to "virsh setmem" command.
The behavior of above options is the same as that of "virsh setvcpus" and so on.
That is, when the --config option is specified, a modification is effective for
the persistent domain. Moreover we can modify the memory size of inactive domains
as well as that of active domains.
Signed-off-by: NTaku Izumi <izumi.taku@jp.fujitsu.com>

This patch implements the remote protocol to address the new API.
Signed-off-by: NTaku Izumi <izumi.taku@jp.fujitsu.com>

This patch implements the code to address the new API
in the qemu driver.
Signed-off-by: NTaku Izumi <izumi.taku@jp.fujitsu.com>

This patch introduces a new libvirt API (virDomainSetMemoryFlags) and
a flag (virDomainMemoryModFlags).
Signed-off-by: NTaku Izumi <izumi.taku@jp.fujitsu.com>

Opening raw network devices with the intent of passing those fds to
qemu is worth an audit point.  This makes a multi-part audit: first,
we audit the device(s) that libvirt opens on behalf of the MAC address
of a to-be-created interface (which can independently succeed or
fail), then we audit whether qemu actually started the network device
with the same MAC (so searching backwards for successful audits with
the same MAC will show which fd(s) qemu is actually using).  Note that
it is possible for the fd to be successfully opened but no attempt
made to pass the fd to qemu (for example, because intermediate
nwfilter operations failed) - no interface start audit will occur in
that case; so the audit for a successful opened fd does not imply
rights given to qemu unless there is a followup audit about the
attempt to start a new interface.

Likewise, when a network device is hot-unplugged, there is only one
audit message about the MAC being discontinued; again, searching back
to the earlier device open audits will show which fds that qemu quits
using (and yes, I checked via /proc/<qemu-pid>/fd that qemu _does_
close out the fds associated with an interface on hot-unplug).  The
code would require much more refactoring to be able to definitively
state which device(s) were discontinued at that point, since we
currently don't record anywhere in the XML whether /dev/vhost-net was
opened for a given interface.

* src/qemu/qemu_audit.h (qemuAuditNetDevice): New prototype.
* src/qemu/qemu_audit.c (qemuAuditNetDevice): New function.
* src/qemu/qemu_command.h (qemuNetworkIfaceConnect)
(qemuPhysIfaceConnect, qemuOpenVhostNet): Adjust prototype.
* src/qemu/qemu_command.c (qemuNetworkIfaceConnect)
(qemuPhysIfaceConnect, qemuOpenVhostNet): Add audit points and
adjust parameters.
(qemuBuildCommandLine): Adjust caller.
* src/qemu/qemu_hotplug.c (qemuDomainAttachNetDevice): Likewise.

Since libvirt always passes /dev/net/tun to qemu via fd, we should
never trigger the cases where qemu tries to directly open the
device.  Therefore, it is safer to deny the cgroup device ACL.

* src/qemu/qemu_cgroup.c (defaultDeviceACL): Remove /dev/net/tun.
* src/qemu/qemu.conf (cgroup_device_acl): Reflect this change.

* src/qemu/qemu_hotplug.c (qemuDomainAttachNetDevice): Honor vhost
designations, similar to qemu_command code paths.
* src/qemu/qemu_command.h (qemuOpenVhostNet): New prototype.
* src/qemu/qemu_command.c (qemuOpenVhostNet): Export.