Follows the pattern used in the libxl driver for managing multiple,
simultaneous jobs within the driver.
Signed-off-by: NKaterina Koukiou <k.koukiou@gmail.com>

If the stats for a block device can't be acquired from qemu we've
fallen back to loading them from the file on the disk in libvirt.

If qemu is not cooperating due to being stuck on an inaccessible NFS
share we would then attempt to read the files and get stuck too with
the VM object locked. All other APIs would eventually get stuck waiting
on the VM lock.

Avoid this problem by skipping the block stats if the VM is online but
the monitor did not provide any stats.

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

Extract the fallback path that reloads the stats from disk into a
separate function.

'abbreviated' was true if 'stats' were NULL

Some Intel processor families (e.g. the Intel Xeon processor E5 v3
family) introduced some RDT (Resource Director Technology) features
to monitor or control shared resource. Among these features, MBM
(Memory Bandwidth Monitoring), which is build on the CMT (Cache
Monitoring Technology) infrastructure, provides OS/VMM a way to
monitor bandwidth from one level of cache to another.

With current perf framework, this patch adds support to perf event
for MBM.
Signed-off-by: NQiaowei Ren <qiaowei.ren@intel.com>

Split out parsing of most of the <os> subelements into a separate
function.

vz puts uuids into curly braces. Simply introduce new contstant to reflect this
and get rid of magic +2 in code.
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

Peer to peer migration is implemented just as in managed case. Basically
it is copy paste from managed case but with all the branches that are not
applied to vz removed.
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

The newest version of migration protocol - version 3 with parameters is implemented.
Supported flags is VIR_MIGRATE_PAUSED only. Supported parameters are
VIR_MIGRATE_PARAM_URI and VIR_MIGRATE_PARAM_DEST_NAME. VIR_MIGRATE_PARAM_DEST_XML
is in VZ_MIGRATION_PARAMETERS for technical onyl reasons.
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>

Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

This session uuid acts as authN token for different multihost vz operations one
of which is migration. Unfortunately we can't get it from server at any time
thus we need to save it at login.
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

Finally wire-up virAdmServer{Get,Set}ClientLimits APIs into virt-admin client.
Update the virt-admin's man page accordingly.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Opposite operation to virAdmServerGetClientLimits. Understandably though,
setting values for current number of clients connected or still waiting
for authentication does not make sense, since changes to these values are event
dependent, i.e. a client connects - counter is increased. Thus only the limits
to maximum clients connected and waiting for authentication can be set. Should
a request for other controls to be set arrive (provided such a setting will
be first introduced to the config), the set of configuration controls can be
later expanded (thanks to typed params). This patch also introduces a
constraint that the maximum number of clients waiting for authentication has to
be less than the overall maximum number of clients connected and any attempt to
violate this constraint will be denied.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Enable retrieval of the number of maximum clients connected to all sockets
combined, as well as the number of maximum clients waiting for authentication,
in order to be successfully connected. These are the attributes configurable
through libvirtd.conf, however, it could be handy to not only know values for
these limits, but also the values for the current number of clients
connected and number of clients currently waiting for authentication which are
changing dynamically. This API does both, retrieves the limits as well as the
current dynamic values.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

In order for typed params validation to pass on daemon side, we should
encourage users to use our exported constants with typed params to diminish
to avoid any potential problems related to argument validity.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Add some trivial getters for client related attributes to virnetserver before
any admin method can be introduced.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

QEMU needs access to the /dev/dri/render* device for
virgl to work.

Allow access to all /dev/dri/* devices for domains with
<video>
  <model type='virtio' heads='1' primary='yes'>
    <acceleration accel3d='yes'/>
  </model>
</video>

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

All qemu versions we support have QEMU_CAPS_DEVICE, so checking
for it is redundant. Remove the usage.

The code diff isn't clear, but all that code is just inindented
with no other change.

Test cases that hit qemuDomainAssignAddresses but don't have
infrastructure for specifying qemuCaps values see lots of
churn, since now PCI addresses are in the XML output.

Upcoming patches are going to make the disk portion of these
test cases fail. In order to make it work, we would need to
extend the qemuargv2xml test infrastructure to handle qemuCaps.
This is worthwhile to do at some point but isn't critical.

Instead just drop the offending portion, which isn't even the
target of the test cases anyways

hotplug APIs with the AFFECT_CONFIG flag are essentially replicating
'insert <device> into XML document, and redefine XML'. Thinking of
it this way, it's natural that we call virDomainDefPostParse after
manually editing the XML here.

Not only does doing so allow us to drop a bunch of open coded calls
to qemuDomainAssignAddresses, but it also means we are going through
the standard channels for XML validation and potentially catching
errors in user submitted XML.

This wires up qemuDomainAssignAddresses into the new
virDomainDefAssignAddressesCallback, so it's always triggered
via virDomainDefPostParse. We are essentially doing this already
with open coded calls sprinkled about.

qemu argv parse output changes slightly since previously it wasn't
hitting qemuDomainAssignAddresses.

This will be called at the end of virDomainDefPostParse to
allow hypervisor drivers to fill in device addresses.

This reverts commit 1ccc7fbf.

We cannot check ports if autoport is set because we set ports to 0 while
parsing device XML.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1336134Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Let's use introduced domain snapshots infrastructure instead.
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

This solution does not keep snapshots cache because vz sdk lacks good support
for snapshot related events.

Libvirt and vz sdk has different approach to snapshot ids. vz sdk always
auto generate them while libvirt has ability to specify id by user.
Thus I have no other choice rather than simply ignore ids set by user
or generated by libvirt.
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>

No longer necessary to have it, so remove it.

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

Instead of disabling auto-login of all scsi targets (even those
that do not "belong" to libvirt), use iscsiadm's "--op nonpersistent"
during discovery of iSCSI targets (e.g. "iscsiadm --mode discovery
--type sendtargets") in order to avoid the node database being altered
which led to the need for the "large hammer" approach taken by
commit id '3c12b654'.

This commit removes the virISCSITargetAutologin adjustment (eg. the setting
of node.startup to "manual"). The iscsiadm command has supported this mode
of operation as of commit id 'ad873767' to open-iscsi.

Utilize the exit status parameter for virCommandRunRegex in order to
check the return error from the 'iscsiadm --mode session' command.
Without this enabled, if there are no sessions running then virCommandRun
would have displayed an error such as:

    2016-05-13 15:17:15.165+0000: 10920: error : virCommandWait:2553 :
               internal error: Child process (iscsiadm --mode session)
               unexpected exit status 21: iscsiadm: No active sessions.

It is possible that for certain paths (when probe is true) we only care
whether it's running or not to make certain decisions.  Spitting out
the error for those paths is unnecessary.

If we do have a situation where probe = false and there's an error,
then display the error from iscsiadm if it's there.

Rather than have virCommandRun just spit out the error, allow callers
to decide to pass the exitstatus so the caller can make intelligent
decisions based on the error.

The only case where the hardware capabilities influence the result
is when no <gic/> element was provided.

The test programs now ensure both that the correct GIC version is
picked in that case, and that hardware capabilities are not taken
into account when the user has already picked a GIC version.

Now that we choose the GIC version based on hardware features when
no <gic/> element has been provided, we need a way to fake the GIC
capabilities of the host.

Update the qemuxml2argv and qemuxml2xml tests to allow this.

For use in the test suite.

When the <gic/> element in not present in the domain XML, use the
domain capabilities to figure out what GIC version is usable and
choose that one automatically.

This allows guests to be created on hardware that only supports
GIC v3 without having to update virt-manager and similar tools.

Keep using the default GIC version if the <gic/> element has been
added to the domain XML but no version has been specified, as not
to break existing guests.

This utility function extracts some of the logic from
virQEMUCapsFillDomainFeatureGICCaps() so that it can be used
in a different context.

The INPLACE variants of the VIR_APPEND macros cannot fail and they are
inherently quiet.

It was just a useless wrapper around VIR_APPEND_ELEMENT*.

Signed-off-by: NChunyan Liu <cyliu@suse.com>

According to current xl.cfg docs and xl codes, it uses type=vif
instead of type=netfront.

Currently after domxml-to-native, libvirt xml model=netfront will be
converted to xl type=netfront. This has no problem before, xen codes
for a long time just check type=ioemu, if not, set type to _VIF.

Since libxl uses parse_nic_config to avoid duplicate codes, it
compares 'type=vif' and 'type=ioemu' for valid parameters, others
are considered as invalid, thus we have problem with type=netfront
in xl config file.
 #xl create sles12gm-hvm.orig
 Parsing config from sles12gm-hvm.orig
 Invalid parameter `type'.

Correct the conversion in libvirt, so that it matchs libxl codes
and also xl.cfg.
Signed-off-by: NChunyan Liu <cyliu@suse.com>

Unify XEN_CONFIG_FORMAT_x and LIBXL_CONFIG_FORMAT_x to
XEN_CONFIG_FORMAT_x, and move to xen_common.h.
Signed-off-by: NChunyan Liu <cyliu@suse.com>

Trivially return 1, since bhyve is considered a local connection that
should not be vulnerable to eavesdropping.