Commit id 'c4a4603d' added an output <path> to the nodedev xml, but
did not update the schema.

This resulted in the failure of the 'virt-xml-validate' on a file
generated by 'virsh nodedev-dumpxml pci_0000_00_00_0' (for example).

This was found/seen by running autotest on my host.

Signed-off-by: NGao feng <gaofeng@cn.fujitsu.com>

Signed-off-by: NGao feng <gaofeng@cn.fujitsu.com>

mmap can fail on 32-bit systems if we're trying to zero out a lot of data.
Fall back to using block-by-block writing in that case.  While we could map
smaller blocks it's unlikely that this code is used a lot and its easier to
just fall back to one of the existing methods.

Also modified the block-by-block zeroing to not allocate a megabyte of
zeroes if we're writing less than that.
Signed-off-by: NOskari Saarenmaa <os@ohmu.fi>

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.

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Join the worker thread no matter if it is running or zombie already.
With current implementation the thread is joined iff @running is true.
However, when worker executes the last line, @running is set to false.
Hence qemuMonitorTestFree() won't join it (and free resources) even
though we can clearly see worker has run (nobody else sets @running =
false).
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Right now, we are testing qemuMonitorSystemPowerdown instead of
qemuMonitorJSONSystemPowerdown. It makes no harm, as both functions have
the same header and the former is just a wrapper over the latter. But we
should be consistent as we're testing the JSON functions only in here.

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>

And so do qemuMonitorJSONSetMigrationCapability.

Also do qemuMonitorJSONGetBlockIoThrottle.

While the reply can be reused test qemuMonitorJSONGetBlockExtent and
qemuMonitorJSONGetBlockExtent too.

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