This method just aggregates various client object attributes, like socket
address, connection type (RO/RW), and some TCP/TLS/UNIX identity in an atomic
manner.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

We do have a similar method, serving the same purpose, for TLS, but we lack
one for SASL. So introduce one, in order for other modules to be able to find
out, if a SASL session is active, or better said, that a SASL session exists
at all.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Our socket address format is in a rather non-standard format and that is
because sasl library requires the IP address and service to be delimited by a
semicolon. The string form is a completely internal matter, however once the
admin interfaces to retrieve client identity information are merged, we should
return the socket address string in a common format, e.g. format defined by
URI rfc-3986, i.e. the IP address and service are delimited by a colon and
in case of an IPv6 address, square brackets are added:

Examples:
    127.0.0.1:1234
    [::1]:1234

This patch changes our default format to the one described above, while adding
separate methods to request the non-standard SASL format using semicolon as a
delimiter.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

This patch could easily be squashed with the virAdmClientGetInfo method
introduced later one, but the idea was to split the logic to as many preferably
independent patches as possible. As the subject hints, this patch defines
some public typed params-related macros used within virAdmClientGetInfo
method. The thing is, there's one identity attribute missing in the set --
SELinux context, which libvirt internally supports in virIdentity, but it
doesn't seem to do much (or anything at all), so there's some room to extend
the set in the future.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Just like with server-related APIs, before any of client-based APIs can be
called, a reference to a client-side client object needs to be obtained. For
this purpose, a lookup method should exist. Apart from the client retrieval
logic, a new error code for non-existent client had to be added as well.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

In majority of our functions we have this variable @ret that is
overwritten a lot. In other areas of the code we use 'goto
cleanup;' just so that this wouldn't happen. But here.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Starting from commit 5b479f3b, libvirtd.pod is a source file
rather than a generated file. Update ignore patterns accordingly.

Daemon config parameter switch between reading host uuid
either from smbios or machine-id:

host_uuid_source = "smbios|machine-id"
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

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

This adds a ports= attribute to usb controller XML, like

  <controller type='usb' model='nec-xhci' ports='8'/>

This maps to:

  qemu -device nec-usb-xhci,p2=8,p3=8

Meaning, 8 ports that support both usb2 and usb3 devices. Gerd
suggested to just expose them as one knob.

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

Reports whether we support -device nec-usb-xhci,p3=XXX value,
which has been available since qemu 1.3.0

Rather than reimplement it. This will be needed in upcoming patches

In these functions I'm fixing here, we do call
qemuMonitorJSONCheckError() followed by another check if qemu
reply contains 'return' object. If it wouldn't, the former
CheckError() function would error out and the flow would not even
get to the latter.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Usually, the flow in this area of the code is as follows:

qemuMonitorJSONMakeCommand()
qemuMonitorJSONCommand()
qemuMonitorJSONCheckError()
parseReply()

But in this function, for some reasons, the last two steps were
swapped. This makes no sense.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

In qemuDomainDefAddDefaultDevices we check for a non-NULL
def->os.machine for x86 archs, but not the others.

Moreover, the only caller - qemuDomainDefPostParse
already checks for it and even then it can happen only
if /etc/libvirt contains an XML without a machine type.

Use it everywhere except for virQEMUCapsFillDomainFeatureGICCaps.

It was not indented correctly.

We do not need to propagate the exact return values
and the only possible ones are 0 and -1 anyway.

Remove the temporary variable and use the usual pattern:

if (f() < 0)
    return -1;

This function does not fail and it does not need to return anything.

For all the other machine types, we use a positive condition.

Be more positive and use it for i440fx too.

Do not duplicate the string comparisons by writing them twice.

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

Thing is, for some reasons you can have your domain's RTC to be
in something different than UTC. More weirdly, it's not only time
zone what you can shift it of, but an arbitrary value. So, if
domain is configured that way, libvirt will correctly put it onto
qemu cmd line and moreover track it as this offset changes during
domain's life time (e.g. because guest OS decides the best thing
to do is set new time to RTC). Anyway, they way in which this
tracking is implemented is events. But we've got a problem if
change in guest's RTC occurs and the daemon is not running. The
event is lost and we end up reporting invalid value in domain
XML. Therefore, when the daemon is starting up again and it is
reconnecting to all running domains, re-fetch their RTC so the
correct offset value can be computed.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

Wire-up the public client listing API. Along with this change, a private time
simple conversion method to interpret client's timestamp obtained from server
has been added as well. Format used to for time output is as follows:
YYYY-mm-DD HH:MM:SS+ZZZZ.

Although libvirt exposes methods time-related methods through virtime.h
internally, it utilizes millisecond precision which we don't need in this case,
especially when connection timestamps use precision to seconds only.
This is just a convenience int to string conversion method.

To reflect the new API, man page has been adjusted accordingly.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Finally add public method to retrieve the list of currently connected clients
to a given server.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Although we document 6 types of transport that we support, internally we can
only differentiate between TCP, TLS, and UNIX transports only, since both SSH
and libssh2 transports, due to using netcat, behave in the exactly the same
way as a UNIX socket.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

We have to expose some constants, in order for the client object transport
field to make sense.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

For now, the list copy is done simply by locking the whole server, walking the
original and increasing the refcount on each object. We may want to change
the list to a lockable object (like list of domains) later in the future if
we discover some performance issues related to locking the whole server in
order to walk the whole list of clients, possibly issuing some 'ForEach'
callback.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

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>

Besides ID, the object also stores static data like connection transport and
connection timestamp, since once obtained a list of all clients connected to a
server, from user's perspective, it would be nice to know whether a given
client is remote or local only and when did it connect to the daemon.
Along with the object introduction, all necessary client-side methods necessary
to work with the object are added as well.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Besides ID, libvirt should provide several parameters to help the user
distinguish two clients from each other. One of them is the connection
timestamp. This patch also adds a testcase for proper JSON formatting of the
new attribute too (proper formatting of older clients that did not support
this attribute yet is included in the existing tests) - in order to
testGenerateJSON to work, a mock of time_t time(time_t *timer) needed to be
created.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Admin API needs a way of addressing specific clients. Unlike servers, which we
are happy to address by names both because its name reflects its purpose (to
some extent) and we only have two of them (so far), naming clients doesn't make
any sense, since a) each client is an anonymous, i.e. not recognized after a
disconnect followed by a reconnect, b) we can't predict what kind of requests
it's going to send to daemon, and c) the are loads of them comming and going,
so the only viable option is to use an ID which is of a reasonably wide data
type.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Move the code dealing with init scripts to a separate file
so configure.ac itself can be a little bit smaller.

Most distributions, including RHEL, have switched to systemd,
so we should detect it and act accordingly. This also means
that 'systemd+redhat' should be preferred to legacy 'redhat'.

Our witness for the check is the availability of the systemctl
command on the host.

If we didn't find a match, either because we're cross compiling
or because we're not building on RHEL, we won't install any
init script.

Make sure this is reported correctly in the configure summary.

Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>

This patch adds by default a panic device with model s390 to S390 guests.
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>

If a panic device is being defined without a model in a domain
the default value is always overwritten with model ISA. An ISA
bus does not exist on S390 and therefore specifying a panic device
results in an unsupported configuration.
Since the S390 architecture inherently provides a crash detection
capability the panic device should be defined in the domain xml.

This patch adds an s390 panic device model and prevents setting a
device address on it.
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: NCornelia Huck <cornelia.huck@de.ibm.com>

Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>