If use of virtlogd is enabled, then use it for backing the
character device log files too. This avoids the possibility
of a guest denial of service by writing too much data to
the log file.

The virtlogd daemon currently opens all files for append, but
in some cases the user may wish to discard existing data. Define
a new flag to indicate that logfiles should be truncated when
opening.

The functions for handling FD passing when building command line
arguments need to be used by many different bits of code, so need
to be at the start of the source file
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The act of formatting a chardev backend value may need to
append command line arguments for passing FDs. If we append
the -chardev arg before formatting the value, then the
resulting arguments will end up interspersed
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Honour the <log file='...'/> element in chardevs to output
data to a file. This requires QEMU >= 2.6
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Extend the chardev source XML so that there is a new optional
<log/> element, which is applicable to all character device
backend types. For example, to log output of a TCP backed
serial port

    <serial type='tcp'>
      <source mode='connect' host='127.0.0.1' service='9999'/>
      <protocol type='raw'/>
      <log file='/var/log/libvirt/qemu/demo-serial0.log' append='on'/>
      <target port='0'/>
    </serial>

Not all hypervisors will support use of logfiles.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Not all callers of virLogManagerDomainOpenLogFile will
care about getting the current inode/offset, so we should
allow those parameters to be NULL
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

After adding support for offline vcpu pinning the code that removes the
pinning for cpu cold-unplug was forgotten. This fixes up commit 02ae21de

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

Memory returned from virStringSplit shall be freed with
virStringFreeList rather than VIR_FREE. Introduced in commit 511e7c5b.

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

Cpus are indexed starting from '0' so the check was invalid.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1316384
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1316420

Now that the function was extracted we can get rid of some temp
variables. Additionally formatting of the bitmap string for the event
code should be checked.

The function was now beyond maintainability.

NFS with root-squash is the only reason we need to do setuid/setgid
crazyness in virFileRemove, so limit that behavior to the NFS case.

Break these checks out into their own function, and clearly document
each one. This shouldn't change behavior

Allow pinning for inactive vcpus. The pinning mask will be automatically
applied as we would apply the default mask in case of a cpu hotplug.

Setting the scheduler settings for a vcpu has the same semantics.

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

Introduce VIR_DOMAIN_DEF_FEATURE_OFFLINE_VCPUPIN domain feature flag
whcih will allow to skip ignoring of the pinning information for
hypervisor drivers which will want to implement forward-pinning of
vcpus.

Introduce a helper to check supported device and domain config and move
the memory hotplug checks to it.

The advantage of this approach is that by default all new features are
considered unsupported by all hypervisors unless specifically changed
rather than the previous approach where every hypervisor would need to
declare that a given feature is unsupported.

To avoid having to forbid new features added to domain XML in post parse
callbacks for individual hypervisor drivers the feature flag mechanism
will allow to add a central check that will be disabled for the drivers
that will add support.

As a first example flag, the 'hasWideSCSIBus' is converted to the new
bitmap.

The API documentation states that the function is returning pinning for
all vCPUs, so we can actually do so if the user passes a large enough
array.

The implementation of the inner guts of the function is similar for all
drivers, so we can add a helper and not have to reimplement it three
times.

The API docs state that the API queries pinning info for all vCPUs and
thus we should allocate the bitmap even for the inactive ones.

The API will currently return bitmap only for the active vCPUs but that
will change in the future.

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The VIR_DOMAIN_EVENT_ID_JOB_COMPLETED event will be triggered once a job
(such as migration) finishes and it will contain statistics for the job
as one would get by calling virDomainGetJobStats. Thanks to this event
it is now possible to get statistics of a completed migration of a
transient domain on the source host.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

We would happily report and free statistics of a completed migration
even before it actually completed (on the source host while migration is
in the Finish phase).
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Computing a total downtime during a migration requires us to store a
time stamp when guest CPUs get stopped. The value (and all other
statistics) is then transferred to the destination to compute the
downtime. Because the stopped time stamp is stored by a STOP event
handler while the statistics which will be sent over to the destination
are copied synchronously within qemuMigrationWaitForCompletion.

Depending on the timing of STOP and MIGRATION events, we may end up
copying (and transferring) statistics without the stopped time stamp
set. Let's make sure we always use the correct time stamp.

https://bugzilla.redhat.com/show_bug.cgi?id=1282744Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

With a very old QEMU which doesn't support events we need to explicitly
call qemuMigrationSetOffline at the end of migration to update our
internal state. On the other hand, if we talk to QEMU using QMP, we
should just wait for the STOP event and let the event handler update the
state and trigger a libvirt event.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

We should not overwrite all migration statistics on the source with the
numbers sent by the destination since the source may have an updated
view in some cases (such as post-copy migration). It's safer to update
just the timing info we need to get from the destination and be prepared
for the future. And we should only do all this after a successful
migration.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Statistics for a completed migration only make sense if the migration
was successful. Let's not store them in priv->job.completed until we
are sure it was a success.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

NULL checks are performed implicitly in the rest of the module,
including other allocations in the very same function.

The comment claimed that virPCIDeviceReattach() does not reattach
a device to the host driver; except it actually does, so the
comment is just confusing and we're better off removing it.

Replace the term "loop" with the more generic "step". This allows us
to be more flexible and eg. have a step that consists in a single
function call.

Don't include the number of steps in the first comment of the
function, so that we can add or remove steps without having to worry
about keeping that comment in sync.

For the same reason, remove the summary contained in that comment.

Clean up some weird vertical spacing while we're at it.

Instead of considering each single step its own test case, create
high level test cases that reproduce a certain scenario.

Always call CHECK_LIST_COUNT() to check the size of both the active
and inactive devices list.

virPCIDeviceListCount()'s return type is size_t, so variables that
store its return value should be of that type.

The 'actualCount' variable, formerly just 'count', is only used
internally by the macro, so it's better to move its declaration
inside the macro as well: this way, it doesn't have to be declared
by every single user.

The new name is less generic to make clashes less likely.

Change the extremely generic count1 and count2 to the more
descriptive active_count and inactive_count.

When checking the number of devices added to a device list, use the
nhostdevs variable instead of its value, so that the test can keep
working even if more hostdevs are added.

If the stars are in the right position and you're building with
VBox >= 4.2.0 it will happen that compiler thinks an array
allocated on the stack may be unbounded:

In file included from vbox/vbox_V4_2.c:13:0:
vbox/vbox_tmpl.c: In function '_virtualboxCreateMachine':
vbox/vbox_tmpl.c:2811:1: error: stack usage might be unbounded [-Werror=stack-usage=]
 _virtualboxCreateMachine(vboxGlobalData *data, virDomainDefPtr def, IMachine **machine, char *uuidstr ATTRIBUTE_UNUSED)
 ^

Well, given how the variable is declared, I had some hard time
seeing it is actually bounded. Surprisingly compiler does not
complain because of -Wframe-larger-than. This is because
variable length arrays do not count into that warning.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NJohn Ferlan <jferlan@redhat.com>