If we exceed a fixed limit in RPC code we get a horrible message
like this, if the parameter type is a 'string', because we forgot
to initialize the error message type field:

  $ virsh snapshot-list ostack1
  error: too many remote undefineds: 1329 > 1024

It would also be useful to know which RPC call and field was
exceeded. So this patch makes us report:

  $ virsh snapshot-list ostack1
  error: too many remote undefineds: 1329 > 1024,
  in parameter 'names' for 'virDomainSnapshotListNames'
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Now, not all APIs are going to support sparse streams. To some it
makes no sense at all, e.g. virDomainOpenConsole() or
virDomainOpenChannel(). To others, we will need a special flag to
indicate that client wants to enable sparse streams. Instead of
having to write RPC dispatchers by hand we can just annotate in
our .x files that a certain flag to certain RPC call enables this
feature. For instance:

     /**
      * @generate: both
      * @ReadStream: 1
      * @sparseflag: VIR_SPARSE_STREAM
      * @acl: storage_vol:data_read
      */
     REMOTE_PROC_DOMAIN_SOME_API = XXX,

Therefore, whenever client calls virDomainSomeAPI(..,
VIR_SPARSE_STREAM); daemon will mark that down and send stream
skips when possible.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Add a new argument to daemonCreateClientStream in order to allow for
future expansion to mark that a specific stream can be used to skip
data, such as the case with sparsely populated files. The new flag will
be the eventual decision point between client/server to decide whether
both ends can support and want to use sparse streams.

A new bool 'allowSkip' is added to both _virNetClientStream and
daemonClientStream in order to perform the tracking.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Add a virStreamPtr pointer to the _virNetClientStream
in order to reverse track the parent stream.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Since it's rather tedious to write the dispatchers for functions that
return an array of typed parameters (which are rather common) let's add
some rpcgen code to generate them.

Now that libvirt-admin supports another client-side object and provided that
we want to generate as many both client-side and server-side RPC dispatchers,
support for this needs to be added to gendispatch.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

The adminDispatchConnectListServers() function is generated by
our great perl script. However, it has a tiny flaw: if
adminConnectListServers() it calls fails, the control jumps onto
cleanup label where we try to free any list of servers built so
far. However, in the loop @i is unsigned (size_t) while @nresults
is signed (int). Currently, it does no harm because of the check
for @result being non-NULL. But if that ever changes in the
future, this bug will be hard to chase.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

All other places use VIR_ERR_RPC except this one, let's be consistent,
shall we?
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Until now, the script assumed that snapshot name is 'snap', but that's
going to change.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Let's call it modern_ret_as_list as opposed to single_ret_as_list.  The
latter was able to return list of things.  However the new, more modern,
version came and it is used since listAllDomains till nowadays in
ListServers.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

We were using parentheses for grouping admin|remote even though we didn't
need to capture what's in it.  That caused some changes to be greater
than needed and, to be honest, some confusion as well.  Let's use it as
it should be used.  It'll also make future changes more consistent.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Commit 8cd1d546 consolidates both daemon and remote driver typed param
serialization functions. The consolidation now enforces client to use
VIR_TYPED_PARAM_STRING_OKAY flag to properly serialize string parameters, which
server has used for quite some time now. And this caused an issue, since the
commit had not adjusted client remote calls appropriately, thus causing a
failure in blkiotune, numatune and migration APIs (as per Xen CI tests). This
patch adjusts both remote_driver.c and gendispatch.pl to properly address this
issue.

http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg01012.htmlSigned-off-by: NJoao Martins <joao.m.martins@oracle.com>
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Same as for deserializer, this method might get handy for admin one day.
The major reason for this patch is to stay consistent with idea, i.e.
when deserializer can be shared, why not serializer as well. The only
problem to be solved was that the daemon side serializer uses a code
snippet which handles sparse arrays returned by some APIs as well as
removes any string parameters that can't be returned to older clients.
This patch makes of the new virTypedParameterRemote datatype introduced
by one of the pvious patches.

Since the method is static to remote_driver, it can't even be used by our
daemon. Other than that, it would be useful to be able to use it with admin as
well. This patch uses the new virTypedParameterRemote datatype introduced in
one of previous patches.

Currently, the deserializer is hardcoded into remote_driver which makes
it impossible for admin to use it. One way to achieve a shared implementation
(besides moving the code to another module) would be pass @ret_params_val as a
void pointer as opposed to the remote_typed_param pointer and add a new extra
argument specifying which of those two protocols is being used and typecast
the pointer at the function entry. An example from remote_protocol:

struct remote_typed_param_value {
        int type;
        union {
                int i;
                u_int ui;
                int64_t l;
                uint64_t ul;
                double d;
                int b;
                remote_nonnull_string s;
        } remote_typed_param_value_u;
};
typedef struct remote_typed_param_value remote_typed_param_value;

struct remote_typed_param {
        remote_nonnull_string field;
        remote_typed_param_value value;
};

That would leave us with a bunch of if-then-elses that needed to be used across
the method. This patch takes the other approach using the new datatype
introduced in one of earlier commits.

In our generator for some code we put empty lines in the output
to separate blocks of code. However, in some cases we put couple
of spaces on the empty line too. It's not bug, it just isn't
nice.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Commmit df8192aa introduced admin related rename and some minor
(caused by automated approach, aka sed) and some more severe isues along with
it. First reason to revert is the inconsistency with libvirt library.
Although we deal with the daemon directly rather than with a specific
hypervisor, we still do have a connection. That being said, contributors might
get under the impression that AdmDaemonNew would spawn/start a new daemon
(since it's admin API, why not...), or AdmDaemonClose would do the exact
opposite or they might expect DaemonIsAlive report overall status of the daemon
which definitely isn't the case.
The second reason to revert this patch is renaming virt-admin client. The
client tool does not necessarily have to reflect the names of the API's it's
using in his internals. An example would be 's/vshAdmConnect/vshAdmDaemon'
where noone can be certain of what the latter function really does. The former
is quite expressive about some connection magic it performs, but the latter does
not say anything, especially when vshAdmReconnect and vshAdmDisconnect were
left untouched.

virAdmConnect was named after virConnect, but after some discussions,
most of the APIs called will be working with remote daemon and starting
them virAdmDaemon will make more sense.  Only possibly controversal name
is CloseCallback (de)registration, and connecting to the daemon (which
will still be Open/Close), but even this makes sense if one thinks about
the daemon being opened and closed, e.g. as file, etc.

This way all the APIs working with the daemon will start with
virAdmDaemon prefix, they will accept virAdmDaemonPtr as first parameter
and that will better suit with other namings as well (virDomain*,
virAdmServer*, etc.).

Because in virt-admin, the connection name does not refer to a struct
that would have a connect in its name, also adjust 'connname' in
clients.  And because it is not used anywhere in the vsh code, move it
from there into each client.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Introduce a new API to get libvirt version. It is worth noting, that
libvirt-admin and libvirt share the same version number. Unfortunately,
our existing API isn't generic enough to be used with virAdmConnectPtr
as well. Also this patch wires up this API to the virt-admin client
as a generic cmdVersion command.

Since this is just a new option for gendispatch, it looks more like a
cleanup.  The only differences handled by it are connect pointers,
private pointers and API naming customs.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

We don't allow it in normal code, why would it need to be in the
generated one.  IT also splits the line in perl code so it's readable.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

While it returns info about multiple threads, the version
without the plural is easier to read.

Since all APIs are also RPC calls, we automatically get all APIs covered
with thread jobs.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Implement the remote plumbing.

Implement the remote plumbing for virDomainGetIOThreadsInfo
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Modify the various virXXXFree calls to only call virObjectUnref. Calling
the public API will reset the last error thus clearing out a pending error.

Add daemon and driver code to (de-)serialize virDomainFSInfo.
Signed-off-by: NTomoki Sekiyama <tomoki.sekiyama@hds.com>

Since the secondary drivers are only active when the primary
driver is also the remote driver, there is no need to use the
different type specific privateData fields.

I noticed a line 'int nparams = 0;;' in remote_dispatch.h, and
tracked down where it was generated.  While at it, I found a
couple of other double semicolons.  Additionally, I noticed that
commit df0b57a9 left a stale reference to the file name
remote_dispatch_bodies.h.

* src/conf/numatune_conf.c (virDomainNumatuneNodeParseXML): Drop
empty statement.
* tests/virdbustest.c (testMessageStruct, testMessageSimple):
Likewise.
* src/rpc/gendispatch.pl (remote_dispatch_bodies.h): Likewise, and
update stale comments.
Signed-off-by: NEric Blake <eblake@redhat.com>

Implement RPC calls for virNetworkGetDHCPLeases, virNetworkGetDHCPLeasesForMAC

daemon/remote.c
   * Define remoteSerializeNetworkDHCPLeases,
            remoteDispatchNetworkGetDHCPLeases
   * Define remoteDispatchNetworkGetDHCPLeasesForMAC
   * Define helper function remoteSerializeDHCPLease

src/remote/remote_driver.c
   * Define remoteNetworkGetDHCPLeases
   * Define remoteNetworkGetDHCPLeasesForMAC
   * Define helper function remoteSerializeDHCPLease

src/remote/remote_protocol.x
   * New RPC procedure: REMOTE_PROC_NETWORK_GET_DHCP_LEASES
   * Define structs remote_network_dhcp_leases, remote_network_get_dhcp_leases_args,
                    remote_network_get_dhcp_leases_ret
   * New RPC procedure: REMOTE_PROC_NETWORK_GET_DHCP_LEASES_FOR_MAC
   * Define structs remote_network_dhcp_leases_for_mac, remote_network_get_dhcp_leases_for_mac_args,
                    remote_network_get_dhcp_leases_for_mac_ret

src/remote_protocol-structs
   * New structs added

src/rpc/gendispatch.pl
   * Add exception (s/Dhcp/DHCP) for auto-generating names of the remote functions
     in daemon/remote_dispatch.h

New rules are added in fixup_name in gendispatch.pl to keep the name
FSFreeze and FSThaw. This adds a new ACL permission 'fs_freeze',
which is also applied to VIR_DOMAIN_SNAPSHOT_CREATE_QUIESCE flag.
Signed-off-by: NTomoki Sekiyama <tomoki.sekiyama@hds.com>
Acked-by: NDaniel P. Berrange <berrange@redhat.com>
Signed-off-by: NEric Blake <eblake@redhat.com>

These are the first async events in the qemu protocol, so this
patch looks rather big compared to most RPC additions.  However,
a large majority of this patch is just mechanical copy-and-paste
from recently-added network events.  It didn't help that this
is also the first virConnect rather than virDomain prefix
associated with a qemu-specific API.

* src/remote/qemu_protocol.x (qemu_*_domain_monitor_event_*): New
structs and RPC messages.
* src/rpc/gendispatch.pl: Adjust naming conventions.
* daemon/libvirtd.h (daemonClientPrivate): Track qemu events.
* daemon/remote.c (remoteClientFreeFunc): Likewise.
(remoteRelayDomainQemuMonitorEvent)
(qemuDispatchConnectDomainMonitorEventRegister)
(qemuDispatchConnectDomainMonitorEventDeregister): New functions.
* src/remote/remote_driver.c (qemuEvents): Handle qemu events.
(doRemoteOpen): Register for events.
(remoteNetworkBuildEventLifecycle)
(remoteConnectDomainQemuMonitorEventRegister)
(remoteConnectDomainQemuMonitorEventDeregister): New functions.
* src/qemu_protocol-structs: Regenerate.
Signed-off-by: NEric Blake <eblake@redhat.com>

The gendispatch.pl script puts comments at the top of files
it creates, saying that it auto-generated them. Also include
the name of the source data file which it reads when doing
the auto-generation.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

So that app developers / admins know what access control checks
are performed for each API, this patch extends the API docs
generator to include details of the ACLs for each.

The gendispatch.pl script is extended so that it generates
a simple XML describing ACL rules, eg.

  <aclinfo>
    ...
    <api name='virConnectNumOfDomains'>
      <check object='connect' perm='search_domains'/>
      <filter object='domain' perm='getattr'/>
    </api>
    <api name='virDomainAttachDeviceFlags'>
      <check object='domain' perm='write'/>
      <check object='domain' perm='save' flags='!VIR_DOMAIN_AFFECT_CONFIG|VIR_DOMAIN_AFFECT_LIVE'/>
      <check object='domain' perm='save' flags='VIR_DOMAIN_AFFECT_CONFIG'/>
    </api>
    ...
  </aclinfo>

The newapi.xsl template loads the XML files containing the ACL
rules and generates a short block of HTML for each API describing
the parameter checks and return value filters (if any).
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Convert the type of loop iterators named 'i', 'j', k',
'ii', 'jj', 'kk', to be 'size_t' instead of 'int' or
'unsigned int', also santizing 'ii', 'jj', 'kk' to use
the normal 'i', 'j', 'k' naming
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Change the ACL filter functions to use a 'bool' return
type instead of a tri-state 'int' return type. The callers
of these functions don't want to distinguish 'auth failed'
from other errors.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Extend the 'gendispatch.pl' script to be able to generate
three new types of file.

- 'aclheader' - defines signatures of helper APIs for
  doing authorization checks. There is one helper API
  for each API requiring an auth check. Any @acl
  annotations result in a method being generated with
  a suffix of 'EnsureACL'. If the ACL check requires
  examination of flags, an extra 'flags' param will be
  present. Some examples

  extern int virConnectBaselineCPUEnsureACL(void);
  extern int virConnectDomainEventDeregisterEnsureACL(virDomainDefPtr domain);
  extern int virDomainAttachDeviceFlagsEnsureACL(virDomainDefPtr domain, unsigned int flags);

  Any @aclfilter annotations resuilt in a method being
  generated with a suffix of 'CheckACL'.

  extern int virConnectListAllDomainsCheckACL(virDomainDefPtr domain);

  These are used for filtering individual objects from APIs
  which return a list of objects

- 'aclbody' - defines the actual implementation of the
  methods described above. This calls into the access
  manager APIs. A complex example:

    /* Returns: -1 on error (denied==error), 0 on allowed */
    int virDomainAttachDeviceFlagsEnsureACL(virConnectPtr conn,
                                            virDomainDefPtr domain,
                                            unsigned int flags)
    {
        virAccessManagerPtr mgr;
        int rv;

        if (!(mgr = virAccessManagerGetDefault()))
            return -1;

        if ((rv = virAccessManagerCheckDomain(mgr,
                                              conn->driver->name,
                                              domain,
                                              VIR_ACCESS_PERM_DOMAIN_WRITE)) <= 0) {
            virObjectUnref(mgr);
            if (rv == 0)
                virReportError(VIR_ERR_ACCESS_DENIED, NULL);
            return -1;
        }
        if (((flags & (VIR_DOMAIN_AFFECT_CONFIG|VIR_DOMAIN_AFFECT_LIVE)) == 0) &&
            (rv = virAccessManagerCheckDomain(mgr,
                                              conn->driver->name,
                                              domain,
                                              VIR_ACCESS_PERM_DOMAIN_SAVE)) <= 0) {
            virObjectUnref(mgr);
            if (rv == 0)
                virReportError(VIR_ERR_ACCESS_DENIED, NULL);
            return -1;
        }
        if (((flags & (VIR_DOMAIN_AFFECT_CONFIG)) == (VIR_DOMAIN_AFFECT_CONFIG)) &&
            (rv = virAccessManagerCheckDomain(mgr,
                                              conn->driver->name,
                                              domain,
                                              VIR_ACCESS_PERM_DOMAIN_SAVE)) <= 0) {
            virObjectUnref(mgr);
            if (rv == 0)
                virReportError(VIR_ERR_ACCESS_DENIED, NULL);
            return -1;
        }
        virObjectUnref(mgr);
        return 0;
    }

- 'aclsyms' - generates a linker script to export the
   APIs to drivers. Some examples

  virConnectBaselineCPUEnsureACL;
  virConnectCompareCPUEnsureACL;
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>