The VM does not need read permission for its own VNC socket to create(),
bind(), accept() connections or to receive(), send(), etc. on connections.

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

Remove all the plumbing needed for the different qcow-create/kvm-img
non-raw file creation.

We can drop the error messages because CreateQemuImg will thrown an
error for us but with slightly less fidelity (unable to find qemu-img),
which I think is acceptable given the unlikeliness of that error in
practice.

This an ubuntu/debian packaging convention. At one point it may have
been an actually different binary, but at least as of ubuntu precise
(the oldest supported ubuntu distro, released april 2012) kvm-img is
just a symlink to qemu-img for back compat.

I think it's safe to drop support for it

qcow-create was a crippled qemu-img impl that shipped with xen. I
think supporting this was only relevant for really old distros
that didn't have a proper qemu package, like early RHEL5. I think
it's fair to drop support

virsh vol-clone is expected to clone a volume within a single
pool; it doesn't work for cloning across pools. Clarify the docs

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

VIR_ERR_NO_SUPPORT maps to the error string

    this function is not supported by the connection driver

and is largely only used for when a driver doesn't have any
implementation for a public API. So its usage with invalid
net-update requests is a bit out of place. Instead use
VIR_ERR_OPERATION_UNSUPPORTED which maps to:

    Operation not supported

And is what qemu's hotplug routines use in similar scenarios

do_open and winsock_init don't follow the naming pattern of other
functions in this file. Rename them to match

This reverts commit 1e9808d3.

We shouldn't advertise libvirtd.socket activation, since currently
it means VM/network/... autostart won't work as expected.

We tried to find a middle ground by installing the config file without
an [Install] section, since systemd won't allow .socket to be enabled
without one... or at least it did do that; presently on f24 it allows
activating the socket quite happily. This also caused user confusion[1]

Just remove the socket file. I've filed a new RFE to track coming up
with a solution to the autostart problem[2], we can point users at that
if there's more confusion:

[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1279348
[2]: https://bugzilla.redhat.com/show_bug.cgi?id=1326136

Commit 3a773c43 introduced the testCompareNetXML2XMLResult
enumeration; however, in one instance the result variable was
assigned a value from the very similar testCompareDocXML2XMLResult
enumeration, leading to a build error.

  networkxml2xmltest.c:33:42: error:
    implicit conversion from enumeration type 'testCompareDomXML2XMLResult'
    to different enumeration type 'testCompareNetXML2XMLResult'
    [-Werror,-Wenum-conversion]

  testCompareNetXML2XMLResult result = TEST_COMPARE_DOM_XML2XML_RESULT_SUCCESS;
                              ~~~~~~   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Use the proper value (TEST_COMPARE_NET_XML2XML_RESULT_SUCCESS) instead.

Implement support for saving GIC capabilities in the cache and
read them back.

Take the GIC capabilities stored in a virQEMUCaps instance and
update a virDomainCaps instance appropriately.

Add information about GIC capabilities to virDomainCaps and update
the formatter to include them in the XML output.

We need to expose GIC capabilities in the domain capabilities
XML: update the schema to validate documents that contain the
new information.

QEMU introduced the query-gic-capabilities QMP command
with commit 4468d4e0f383: use the command, if available,
to probe available GIC capabilities.

The information obtained is stored in a virQEMUCaps
instance, and will be later used to fill in a
virDomainCaps instance.

The struct contains a single boolean field, 'supported':
the meaning of this field is too generic to be limited to
devices only, and in fact it's already being used for
other things like loaders and OSs.

Instead of trying to come up with a more generic name just
get rid of the struct altogether.

It's a fairly common error that a user tries to connect to a URI
like qemu://system or qemu://session (missing a slash). This errors
like:

$ virsh --connect qemu://session
error: failed to connect to the hypervisor
error: Unable to resolve address 'session' service '16514': No address associated with hostname

If you already know that the standard qemu URI has 3 slashes, that
error will make it obvious enough. But new user's may not get it.
There's even a RHEL support page explicitly mentioning it!:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Virtualization_Deployment_and_Administration_Guide/sect-Troubleshooting-Common_libvirt_errors_and_troubleshooting.html

Catch this error early in libvirt.c virConnectOpen for qemu (and vbox
which has similar rules

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

libvirt handles empty source as NULL, while vz sdk as
"" thus we need a bit of conversion.
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

Current implementation does not detect all incompatible configurations.
For example if we have in vzsdk bootorder "cdrom1, cdrom0" (that is
"hdb, hda" in case of ide cdroms) and cdroms do not have disk
images inserted. In this case boot order check code fails to
distiguish them at all as for both PrlVmDev_GetFriendlyName gives "".
Well the consequences are only missing warnings but as
we just have introduced all the necessary tools to face the problem -
let's fix it.
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

Actually using disk PrlVmDev_GetFriendlyName as id on
detaching volumes is not a problem. We can only detach
hard disks and these can not have empty friendly names.
But upcoming update device functionality for cdroms
can not use disk source as id at all as update operation
typically change this same source value. Thus we will need
to use cdrom bus and cdrom target name as cdrom id. So in attempt
to use same id scheme for all purpuses lets fix hard disk
detach function to use new id.
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

Our intention is to use disk bus and disk target name pair
as disk id instead of name returned by PrlVmDev_GetFriendlyName.
We already have the code that extracts this pair from vzsdk
data. Let's factor it out into a function.
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

Prior to this patch we didn't make any attempt to prevent two entries
in the array of interfaces/PCI devices from pointing to the same
device.

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

This is patterned after similar functionality for domain XML tests,
but tries harder to avoid reading non-existent networkxml2xmlout data
file when parse fails.

We already reject a VM with min_guarantee early in the VM startup
in qemuProcessStartValidate

The common idiom in the driver API implementations is roughly:

- ACL check
- BeginJob (if needed)
- AgentAvailable (if needed)
- !IsActive

A few calls had an extra !IsActive before BeginJob, which doesn't
seem to serve much use. Drop them

It isn't implemented and does not work:

error: internal error: guest failed to start: /usr/lib/libvirt/libvirt_lxc: option '--veth' requires an argument
syntax: /usr/lib/libvirt/libvirt_lxc [OPTIONS] ...

We previously threw an explicit error, but this changed in
22cff52a , which I suspect was
untested for LXC

So in glibc-2.23 sys/sysmacros.h is no longer included from sys/types.h
and we don't build because of the usage of major/minor/makedev macros.
Autoconf already has AC_HEADER_MAJOR macro that check where exactly
these functions/macros are defined, so let's use that.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

It already labels abritrary paths, so it's just the naming that was
wrong.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

While working on the tests for the secret initialization vector, I found
that the existing iSCSI tests were lacking in how they defined the IQN.
Many had IQN's of just 'iqn.1992-01.com.example' for one disk while using
'iqn.1992-01.com.example/1' for the second disk (same for hostdevs - guess
how they were copied/generated).

Typically (and documented this way), IQN's would include be of the form
'iqn.1992-01.com.example:storage/1' indicating an IQN using "storage" for
naming authority specific string and "/1" for the iSCSI LUN.

So modify the input XML's to use the more proper format - this of course
has a ripple effect on the output XML and the args.

Also note that the "%3A" is generated by the virURIFormat/xmlSaveUri
to represent the colon.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

These API already support VIR_DOMAIN_AFFECT_* flags. But the
documentation does not mention it. Eww.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Wire up the server threadpool tunable APIs to virt-admin client. Also, provide
a man page for both commands.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Since threadpool increments the current number of threads according to current
load, i.e. how many jobs are waiting in the queue. The count however, is
constrained by max and min limits of workers. The logic of this new API works
like this:
    1) setting the minimum
        a) When the limit is increased, depending on the current number of
           threads, new threads are possibly spawned if the current number of
           threads is less than the new minimum limit
        b) Decreasing the minimum limit has no possible effect on the current
           number of threads
    2) setting the maximum
        a) Icreasing the maximum limit has no immediate effect on the current
           number of threads, it only allows the threadpool to spawn more
           threads when new jobs, that would otherwise end up queued, arrive.
        b) Decreasing the maximum limit may affect the current number of
           threads, if the current number of threads is less than the new
           maximum limit. Since there may be some ongoing time-consuming jobs
           that would effectively block this API from killing any threads.
           Therefore, this API is asynchronous with best-effort execution,
           i.e. the necessary number of workers will be terminated once they
           finish their previous job, unless other workers had already
           terminated, decreasing the limit to the requested value.
    3) setting priority workers
        - both increase and decrease in count of these workers have an
          immediate impact on the current number of workers, new ones will be
          spawned or some of them get terminated respectively.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

New API to retrieve current server workerpool specs. Since it uses typed
parameters, more specs to retrieve can be further included in the pool of
supported ones.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Before any getter or setter methods can be introduced, first specify a set of
public attributes/flags that these methods will be compatible with.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

In order for the client to see all thread counts and limits, current total
and free worker count getters need to be introduced. Client might also be
interested in the job queue length, so provide a getter for that too. As with
the other getters, preparing for the admin interface, mutual exclusion is used
within all getters.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

So far, the values the affected getters retrieve are static, i.e. there's no
way of changing them during runtime. But admin interface will later enable
not only getting but changing them as well. So to prevent phenomenons like
torn reads or concurrent reads and writes of unaligned values, use mutual
exclusion when getting these values (writes do, understandably, use them
already).
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Otherwise 'Unknown' error will be returned to client.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

When either creating a threadpool, or creating a new thread to accomplish a job
that had been placed into the jobqueue, every time thread-specific data need to
be allocated, threadpool needs to be (re)-allocated and thread count indicators
updated. Make the code clearer to read by compressing these operations into a
more complex one.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Make all relevant changes to admin protocol, in order to achieve $(subj)
Signed-off-by: NErik Skultety <eskultet@redhat.com>