Again stolen from qemu_driver.c, but dropping all the unneeded bits.
This aims to copy all the current qemu validation checks since that's
the most commonly used real driver, but some of the checks are
completely artificial in the test driver.

This only supports creation of internal snapshots for initial
simplicity.

The user can pass it as a <test:domainsnapshot> subelement of a <domain>.

Makes things more readable IMO

This resolves:

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

Note that a similar problem was reported in:

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

but the fix only worked for <interface type='hostdev'>, *not* for
<interface type='network'> where the network itself was a pool of
hostdevs.

The symptom in both cases was this error message:

   internal error: Unable to determine device index for network device

In both cases the cause was lack of proper handling for netdevs
(<interface>) of type='hostdev' when scanning the netdev list looking
for alias names in qemuAssignDeviceNetAlias() - those that aren't
type='hostdev' have an alias of the form "net%d", while those that are
hostdev use "hostdev%d". This special handling was completely lacking
prior to the fix for Bug 827519 which was:

When searching for the highest alias index, libvirt looks at the alias
for each netdev and if it is type='hostdev' it ignores the entry. If
the type is not hostdev, then it expects the "net%d" form; if it
doesn't find that, it fails and logs the above error message.

That fix works except in the case of <interface type='network'> where
the network uses hostdev (i.e. the network is a pool of VFs to be
assigned to the guests via PCI passthrough). In this case, the check
for type='hostdev' would fail because it was done as:

     def->net[i]->type == VIR_DOMAIN_NET_TYPE_HOSTDEV

(which compares what was written in the config) when it actually
should have been:

    virDomainNetGetActualType(def->net[i]) == VIR_DOMAIN_NET_TYPE_HOSTDEV

(which compares the type of netdev that was actually allocated from
the network at runtime).

Of course the latter wouldn't be of any use if the netdevs of
type='network' hadn't already acquired their actual network connection
yet, but manual examination of the code showed that this is never the
case.

While looking through qemu_command.c, two other places were found to
directly compare the net[i]->type field rather than getting actualType:

* qemuAssignDeviceAliases() - in this case, the incorrect comparison
  would cause us to create a "net%d" alias for a netdev with
  type='network' but actualType='hostdev'. This alias would be
  subsequently overwritten by the proper "hostdev%d" form, so
  everything would operate properly, but a string would be
  leaked. This patch also fixes this problem.

* qemuAssignDevicePCISlots() - would defer assigning a PCI address to
  a netdev if it was type='hostdev', but not for type='network +
  actualType='hostdev'. In this case, the actual device usually hasn't
  been acquired yet anyway, and even in the case that it has, there is
  no practical difference between assigning a PCI address while
  traversing the netdev list or while traversing the hostdev
  list. Because changing it would be an effective NOP (but potentially
  cause some unexpected regression), this usage was left unchanged.

The XML parser reserves 'vnet' as a prefix for automatically
generated NIC device names. Switch the veth device creation
to use this prefix, so it does not have to worry about clashes
with user specified names in the XML.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The veth device creation code run in two steps, first it looks
for two free veth device names, then it runs ip link to create
the veth pair. There is an obvious race between finding free
names and creating them, when guests are started in parallel.

Rewrite the code to loop and re-try creation if it fails, to
deal with the race condition.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

If veth device allocation has a fatal error, the veths
array may contain NULL device names. Avoid calling the
virNetDevVethDelete function on such names.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The kernel automatically destroys veth devices when cleaning
up the container network namespace. During normal shutdown, it
is thus likely that the attempt to run 'ip link del vethN'
will fail. If it fails, check if the device exists, and avoid
reporting an error if it has gone. This switches to use the
virCommand APIs instead of virRun too.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

During container cleanup there is a race where the kernel may
have destroyed the veth device before we try to set it offline.
This causes log error messages. Given that we're about to
delete the device entirely, setting it offline is pointless.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

After successful @cmd construction the memory where @keys points to is
part of @cmd. Avoid double freeing it.

When querying for kvm, we try to find 'enabled' field. Hence the error
message should report we haven't found 'enabled' and not 'running'
(which is not even in the reply). Probably a typo or copy-paste error.

The qemuDomainChangeNet() is called when 'virsh update-device' is
invoked on a NIC. Currently, we fail to update the QoS even though
we have routines for that.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

So far the virNetDevBandwidthEqual() expected both ->in and ->out items
to be allocated for both @a and @b compared. This is not necessary true
for all our code. For instance, running 'update-device' twice over a NIC
with the very same XML results in SIGSEGV-ing in this function.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This is just stolen from qemu_driver.c with tweaks to fit the
test driver.

Also add a <test:hasmanagedsave> element to set this data when starting
the connection.

Similar to the runstate commit, allow a boolean <test:transient/>
element for setting domain persistence at driver startup.

We can dereference graphics[0] even if guest has no graphics device
configured. I screwed this up in a216e648

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

On selinux driver initialization failure (missing/incorrectly
formatted contexts file), selabel_handle was closed twice.

Introduced by 6159710c.

This should resolve:

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

libvirt previously recognized NFS, GFS2, OCFS2, and AFS filesystems as
"shared", and thus eligible for exceptions to certain rules/actions
about chowning image files before handing them off to a guest. This
patch widens the definition of "shared filesystem" to include SMB and
CIFS filesystems (aka "Windows file sharing"); both of these use the
same protocol, but different drivers so there are different magic
numbers for each.

This basically covers the talking-to-monitor part of
virQEMUCapsInitQMP.  The patch itself has no real value,
but it creates an entity to be tested in the next patches.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

We forgot to do cleanup when lxcContainerMountFSTmpfs
failed to bind fs as read-only.
Signed-off-by: NChen Hanxiao <chenhanxiao@cn.fujitsu.com>
Signed-off-by: NEric Blake <eblake@redhat.com>

The libvirtd server pushes data out to clients. It does not
know what protocol version the client might have, so must be
conservative and use the old payload limits. ie send no more
than 256kb of data per packet.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The problem is described by [0] but its effect on libvirt is that
starting a container with a full distro running systemd after having
stopped it simply fails.

The container cleanup now calls the machined Terminate function to make
sure that everything is in order for the next run.

 [0]: https://bugs.freedesktop.org/show_bug.cgi?id=68370

mmap's offset must be aligned to page size or mapping will fail.
mmap-based safezero is only used if posix_fallocate isn't available.
Signed-off-by: NOskari Saarenmaa <os@ohmu.fi>

Fixed the retrieval of the AdapterId from the AdapterName of the
hostdev source so it does return an error instead of leaving the
adapter_id uninitialized.
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>

The change in ef29de14 that introduced
better error logging from qemu introduced a warning from coverity about
unused return value from lseek. Silence this warning and fix typo in the
corresponding error message.

Reported by: John Ferlan

Add support for VMware Fusion in the existing VMware driver.  Connect
via the URI vmwarefusion:///session

Currently the VMware version check code only supports two types of
VMware backends, Workstation and Player. But in the near future we will
have an additional one so we need to support more. Additionally, we
discover and cache the path to the vmrun binary so we should use that
path when using the corresponding binary from the VMware VIX SDK.

Another case missed by commits 716c7bb1 and 6973e02b.

* src/Makefile.am (VIR_NET_RPC_GENERATED): Drop $(srcdir).
(libvirt_net_rpc_la_SOURCES): List generated files more compactly.
Signed-off-by: NEric Blake <eblake@redhat.com>

When running 'make dist' on a system without policykit, we currently
fail. This is because $(srcdir)/access/org.libvirt.api.policy is in
EXTRA_DIST, however, the rule to generate the file is conditional
whether we build with polkit or not.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

On some systems (linux, cygwin and gnukfreebsd) rpcgen generates files
which when compiling produces this warning:

remote/remote_protocol.c: In function 'xdr_remote_node_get_cpu_stats_ret':
remote/remote_protocol.c:530: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]

Hence, on those systems we need to post-process the files by the
rpc/genprotocol.pl perl script. At the beginning of the script the OS is
detected via $^O perl variable. From my latest build on FreeBSD I see we
need to fix the code there too. On FreeBSD the variable contains
'freebsd' string:

http://perldoc.perl.org/perlport.html#PLATFORMSSigned-off-by: NMichal Privoznik <mprivozn@redhat.com>

The debug message said there was a timeout of 0 pending for -1 ms which
made me think this is where a hang was coming from but according to the
function comments this case means that there is no timeout pending so
make the debug message say that instead of saying there's a -1 ms
timeout.

While BSDs don't support process creation timestamp information via
PEERCRED for Unix sockets, we need to actually initialize the value
because it is used by the libvirt code.

Ensure that the socket credentials we got back on BSD are valid before
using them.

https://bugzilla.redhat.com/show_bug.cgi?id=1011330 (case A)

While activeScsiHostdevs and webSocketPorts were allocated in
qemuStateInitialize, they were not freed in qemuStateCleanup.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

https://bugzilla.redhat.com/show_bug.cgi?id=1011330 (case D)

qemuProcessStart created two references to virQEMUDriverConfigPtr before
calling fork():

    cfg = virQEMUDriverGetConfig(driver);
    ...
    hookData.cfg = virObjectRef(cfg);

However, the child only unreferenced hookData.cfg and the parent only
removed the cfg reference. That said, we don't need to increment the
reference counter when assigning cfg to hookData. Both the child and the
parent will correctly remove the reference on cfg (the child will do
that through hookData).
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Removed superfluous/wrong srcdir prefix.
Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>

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

Commit 6d7d0b18 (in 1.1.2) added bounds
checking to virDomainGetJobStats. But even at that time the API was able
to return 20 parameters while the limit was set to 16.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

s/becuase/because/
Signed-off-by: NChen Hanxiao <chenhanxiao@cn.fujitsu.com>