The shared network driver is stateful and inside the daemon so
there is no need to use the networkPrivateData field to get the
driver handle. Just access the global driver handle directly.

Many places already directly accessed the global driver handle
in any case, so the code could never work without relying on
this.

The shared storage driver is stateful and inside the daemon so
there is no need to use the storagePrivateData field to get the
driver handle. Just access the global driver handle directly.

Since the secondary drivers are only active when the primary
driver is also the Test driver, there is no need to use the
different type specific privateData fields.

Since the secondary drivers are only active when the primary
driver is also the Parallels driver, there is no need to use the
different type specific privateData fields. The object that was
being stored in the storagePrivateData can easily be kept in the
parallelsConn struct instead.

For inexplicable reasons the phyp driver defined two separate
structs for holding its private data. One it keeps in privateData
and the other it keeps in networkPrivateData. It uses them both
from all API driver methods. Merge the two separate structs
into one to remove this horrible abuse.

The phyp_driver.h file has various declarations that are only
ever used from phyp_driver.c, so they should be in the .c file
only.

Since the secondary drivers are only active when the primary
driver is also the Hyper-V driver, there is no need to use the
different type specific privateData fields.

Since the secondary drivers are only active when the primary
driver is also the ESX driver, there is no need to use the
different type specific privateData fields.

Since the secondary drivers are only active when the primary
driver is also the remote driver, there is no need to use the
different type specific privateData fields.

The remote driver has had a long term hack to deal with the fact
that the old Xen driver worked outside libvirtd, but the rest
of the drivers worked inside. So you could have a local hypervisor
driver but everything else go via the remote driver. The Xen driver
long ago moved inside libvirtd, so this hack is no longer needed.
Thus we should open use the remote driver for secondary drivers
if the primary driver is already the remote driver.

As documented in https://bugzilla.redhat.com/show_bug.cgi?id=1161358,
the ACL attribute should be named: interface_macaddr
Signed-off-by: NLuyao Huang <lhuang@redhat.com>
Signed-off-by: NEric Blake <eblake@redhat.com>

This introduces a testcase for PowerPC compat mode cpu specification.
Signed-off-by: NPrerna Saxena <prerna@linux.vnet.ibm.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Add documentation to explain how compat-mode can be invoked with libvirt
running on PowerPC architecture.
It also mentions that this change is available libvirt 1.2.11 onwards.
Signed-off-by: NPrerna Saxena <prerna@linux.vnet.ibm.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

IBM Power processors differ uniquely across generations (such as power6,
power7, power8). Each generation signifies a new PowerISA version
that exhibits features unique to that generation.
The higher 16 bits of PVR for IBM Power processors encode the CPU
generation, while the CPU chip (sub)version is encoded in lower 16 bits.

For all practical purposes of launching a VM, we care about the
generation which the vCPU will belong to, and not specifically the chip
version. This patch updates the libvirt PVR check to reflect this
relationship. It allows libvirt to select the right CPU generation
in case the exact match for a a specific CPU is not found.
Hence, there will no longer be a need to add each PowerPC CPU model to
cpu_map.xml; just adding entry for the matching ISA generation will
suffice.

It also contains changes to cpu_map.xml since processor generations
as understood by QEMU compat mode go as "power6", "power7" or "power8"
[Reference : QEMU commit 8dfa3a5e85 ]
Signed-off-by: NPrerna Saxena <prerna@linux.vnet.ibm.com>
Signed-off-by: NPradipta Kr. Banerjee <bpradip@in.ibm.com>
Signed-off-by: NAnton Blanchard <anton@samba.org>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

PowerISA allows processors to run VMs in binary compatibility ("compat")
mode supporting an older version of ISA. QEMU has recently added support to
explicitly denote a VM running in compatibility mode through commit 6d9412ea
& 8dfa3a5e85. Now, a "compat" mode VM can be run by invoking this qemu
commandline on a POWER8 host:  -cpu host,compat=power7.

This patch allows libvirt to exploit cpu mode 'host-model' to describe this
new mode for PowerKVM guests. For example, when a user wants to request a
power7 vm to run in compatibility mode on a Power8 host, this can be
described in XML as follows :

  <cpu mode='host-model'>
    <model>power7</model>
  </cpu>
Signed-off-by: NPrerna Saxena <prerna@linux.vnet.ibm.com>
Signed-off-by: NLi Zhang <zhlcindy@linux.vnet.ibm.com>
Signed-off-by: NPradipta Kr. Banerjee <bpradip@in.ibm.com>
Acked-by: NMichal Privoznik <mprivozn@redhat.com>

This adds support for PowerPC Little Endian architecture.,
and allows libvirt to spawn VMs based on 'ppc64le' architecture.
Signed-off-by: NPradipta Kr. Banerjee <bpradip@in.ibm.com>
Signed-off-by: NPrerna Saxena <prerna@linux.vnet.ibm.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Pushed as trivial and pre-ACK'd here:

https://www.redhat.com/archives/libvir-list/2014-November/msg00180.htmlSigned-off-by: NMartin Kletzander <mkletzan@redhat.com>

Since libvirt.h was split into several files, it is impossible to
compile anything against a VPATH-built libvirt. In VPATH, only libvirt.h
is in build/include/libvirt while all other libvirt-*.h files are in
source/include/libvirt.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

One of the latest patches (9a8fc3ef) introduced call of
geteuid(). However, not all systems have the function
implemented, e.g. mingw. Therefore, we fail to build on those
system. The fix consist of including virutil.h which defines
geteuid in needed. Sigh.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

As of b6d4dad1 (1.2.5) libvirt keeps track if domain disks have been
frozen. However, this falls into that set of information which don't
survive domain restart. Therefore, we need to clear the flag upon some
state transitions. Moreover, once we clear the flag we must update the
status file too.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Extending the iothread disk support from pci to pci and ccw.
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
Reviewed-by: NChristian Borntraeger <borntraeger@de.ibm.com>

Finding the right type of disk should check for virtio as bus and
pci as device address type.
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>

When run net-dhcp-leases in quiet mode, cannot get
any output.

 # virsh -q net-dhcp-leases default
Signed-off-by: NLuyao Huang <lhuang@redhat.com>

When start a network fail, libvirt still call virNetworkEventLifecycleNew
to send a event.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>

When compiled without full numa support, the stub function for
virNumaNodeIsAvailable() just checks whether specified node is in range
<0, max); where max is maximum NUMA node available on the host.  But
because the maximum node number is the highest usabe number (and not the
count of nodes), the check is incorrect as it should check whether the
specified node is in range <0, max> instead.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

This is a reaction to Michal's fix [1] for non-NUMA systems that also
splits out conf/ out of util/ because libvirt_util shouldn't require
libvirt_conf if it is the other way around.  This particular use case
worked, but we're trying to avoid it as mentioned [2], many times.

The only functions from virnuma.c that needed numatune_conf were
virDomainNumatuneNodesetIsAvailable() and virNumaSetupMemoryPolicy().
The first one should be in numatune_conf as it works with
virDomainNumatune, the second one just needs nodeset and mode, both of
which can be passed without the need of numatune_conf.

Apart from fixing that, this patch also fixes recently added
code (between commits d2460f85^..5c851562) that doesn't support
non-contiguous nodesets.  It uses new function
virNumaNodesetIsAvailable(), which doesn't need a stub as it doesn't use
any libnuma functions, to check if every specified nodeset is available.

[1] https://www.redhat.com/archives/libvir-list/2014-November/msg00118.html
[2] http://www.redhat.com/archives/libvir-list/2011-June/msg01040.htmlSigned-off-by: NMartin Kletzander <mkletzan@redhat.com>

When using git-status during configure phase, three additional files are
shown as untracked.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Patch 43b67f2e disallowed network tuning only with qemu driver, however
this patch moved the check for root privileges into
virNetDevBandwidthSet function, so the call should now
fail in all possible cases. A mock function was created so that the test
suite doesn't fail because of unsufficient privileges.

Since there was a valid note to patch 43b67f2e about the best spot to
check for bandwidth set call while having libvirt daemon run in session
mode, this patch reverts previous changes dealing with bandwith
(also reverts adding variable @cfg in qemuDomainGetNumaParameters which
 does not have any use at the moment, but getting and unreferencing
 driver's config) in qemu_driver.c and qemu_command.c. There will be
another patch in the series which introduces the fix itself.

==404== 232 bytes in 1 blocks are definitely lost in loss record 669 of 758
==404==    at 0x4C2B934: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==404==    by 0x52A2BF3: virAlloc (viralloc.c:144)
==404==    by 0x1D49AD70: qemuMigrationCookieAddStatistics (qemu_migration.c:554)
==404==    by 0x1D49AD70: qemuMigrationBakeCookie (qemu_migration.c:1228)
==404==    by 0x1D4A43B8: qemuMigrationFinish (qemu_migration.c:5002)
==404==    by 0x1D4C9339: qemuDomainMigrateFinish3Params (qemu_driver.c:11526)

Introduced by commit 5d6fb963

Bandwidth options in blockcommit, blockcopy, blockjob and blockpull
are parsed by vshCommandOptULWrap() and should be shown as a number
type option.

And a typo is fixed.
Signed-off-by: NHao Liu <hliu@redhat.com>

As of 90286418 the function is introduced. However, it's missing
an entry in the libvirt_private.syms so it can't be mocked.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Well, in fact only add comments to mark ifdef,
else and endif sections.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Commit 28f8dfdc (v1.0.0) introduced a security hole: in at least
the qemu implementation of virDomainGetXMLDesc, the use of the
flag VIR_DOMAIN_XML_MIGRATABLE (which is usable from a read-only
connection) triggers the implicit use of VIR_DOMAIN_XML_SECURE
prior to calling qemuDomainFormatXML.  However, the use of
VIR_DOMAIN_XML_SECURE is supposed to be restricted to read-write
clients only.  This patch treats the migratable flag as requiring
the same permissions, rather than analyzing what might break if
migratable xml no longer includes secret information.

Fortunately, the information leak is low-risk: all that is gated
by the VIR_DOMAIN_XML_SECURE flag is the VNC connection password;
but VNC passwords are already weak (FIPS forbids their use, and
on a non-FIPS machine, anyone stupid enough to trust a max-8-byte
password sent in plaintext over the network deserves what they
get).  SPICE offers better security than VNC, and all other
secrets are properly protected by use of virSecret associations
rather than direct output in domain XML.

* src/remote/remote_protocol.x (REMOTE_PROC_DOMAIN_GET_XML_DESC):
Tighten rules on use of migratable flag.
* src/libvirt-domain.c (virDomainGetXMLDesc): Likewise.
Signed-off-by: NEric Blake <eblake@redhat.com>

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

Users might want to update startupPolicy via the
virDomainUpdateDeviceFlags API too. This patch
implements the feature on config layer.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The remote call actually doesn't free the arguments array so we leak
memory in case a domain list is specified. As the remote domain list
array consists only of stolen pointers from the actual domain objects
it's sufficient just to free the array.

Valgrind message:
==1081452== 64 bytes in 1 blocks are definitely lost in loss record 632 of 726
==1081452==    at 0x4C296D0: calloc (vg_replace_malloc.c:618)
==1081452==    by 0x4EA5CB4: virAllocN (viralloc.c:191)
==1081452==    by 0x505D21E: remoteConnectGetAllDomainStats (remote_driver.c:7785)
==1081452==    by 0x50081AA: virDomainListGetStats (libvirt-domain.c:11080)
==1081452==    by 0x155249: cmdDomstats (virsh-domain-monitor.c:2147)
==1081452==    by 0x12FB73: vshCommandRun (virsh.c:1935)
==1081452==    by 0x133FEB: main (virsh.c:3719)

Domain memory elements such as max_balloon and cur_balloon are
implemented as 'unsigned long long', whereas the 'memory' element
in NUMA cells is implemented as 'unsigned int'.

Use the same data type (unsigned long long) for 'memory' element
in NUMA cells.
Signed-off-by: NPrerna Saxena <prerna@linux.vnet.ibm.com>

A domain without a console quietly dies soon after start,
because we try to set /dev/null as a controlling TTY
2014-10-30 15:10:59.705+0000: 1: error : lxcContainerSetupFDs:283 :
ioctl(TIOCSCTTY) failed: Inappropriate ioctl for device

Report an error early instead of trying to start it.

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

It fails after 30 seconds with this error:
error : virDBusCall:1429 : error from service: CanSuspend:
Did not receive a reply. Possible causes include: the remote
application did not send a reply, the message bus security
policy blocked the reply, the reply timeout expired, or the
network connection was broken.

Only probe for the power mgmt capabilities when driver is non-NULL.
This speeds up domain startup by 30 seconds.

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

Coverity found out the very obvious problem in the code.  That is that
virPidFileReleasePath() was called only if
virPidFileAcquirePath() returned 0.  But virPidFileAcquirePath() doesn't
return only 0 on success, but the FD that needs to be closed.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>