==26726==    by 0x673CD67: __vasprintf_chk (vasprintf_chk.c:80)
==26726==    by 0x5673605: UnknownInlinedFun (stdio2.h:210)
==26726==    by 0x5673605: virVasprintfInternal (virstring.c:476)
==26726==    by 0x56736EE: virAsprintfInternal (virstring.c:497)
==26726==    by 0x5680C37: virGetUserRuntimeDirectory (virutil.c:866)
==26726==    by 0x5783A89: virNetSocketNewConnectUNIX (virnetsocket.c:572)
==26726==    by 0x57751AF: virNetClientNewUNIX (virnetclient.c:344)
==26726==    by 0x57689B3: doRemoteOpen (remote_driver.c:895)
==26726==    by 0x5769F8E: remoteConnectOpen (remote_driver.c:1195)
==26726==    by 0x57092DF: do_open (libvirt.c:1189)
==26726==    by 0x570A7BF: virConnectOpenAuth (libvirt.c:1341)

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

There is a possibility that we jump onto error label with @lockpath
still initialized to NULL. Here, the @lockpath should be unlink()-ed,
but passing there a NULL is not a good idea. Don't do that. In fact,
we should call unlink() only if we created the lock file successfully.
Reported-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

Even though we have a mutex mechanism so that two clients don't spawn
two daemons, it's not strong enough. It can happen that while one
client is spawning the daemon, the other one fails to connect.
Basically two possible errors can happen:

  error: Failed to connect socket to '/home/mprivozn/.cache/libvirt/libvirt-sock': Connection refused

or:

  error: Failed to connect socket to '/home/mprivozn/.cache/libvirt/libvirt-sock': No such file or directory

The problem in both cases is, the daemon is only starting up, while we
are trying to connect (and fail). We should postpone the connecting
phase until the daemon is started (by the other thread that is
spawning it). In order to do that, create a file lock 'libvirt-lock'
in the directory where session daemon would create its socket. So even
when called from multiple processes, spawning a daemon will serialize
on the file lock. So only the first to come will spawn the daemon.
Tested-by: NRichard W. M. Jones <rjones@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

While this thread is cleaning up the client and connection objects:
 #2  virFileReadAll (path=0x7f28780012b0 "/proc/1319/stat", maxlen=maxlen@entry=1024, buf=buf@entry=0x7f289c60fc40) at util/virfile.c:1287
 #3  0x00007f28adbb1539 in virProcessGetStartTime (pid=<optimized out>, timestamp=timestamp@entry=0x7f289c60fc98) at util/virprocess.c:838
 #4  0x00007f28adb91981 in virIdentityGetSystem () at util/viridentity.c:151
 #5  0x00007f28ae73f17c in remoteClientFreeFunc (data=<optimized out>) at remote.c:1131
 #6  0x00007f28adcb7f33 in virNetServerClientDispose (obj=0x7f28aecad180) at rpc/virnetserverclient.c:858
 #7  0x00007f28adba8eeb in virObjectUnref (anyobj=<optimized out>) at util/virobject.c:265
 #8  0x00007f28ae74ad05 in virNetServerHandleJob (jobOpaque=<optimized out>, opaque=0x7f28aec93ff0) at rpc/virnetserver.c:205
 #9  0x00007f28adbbef4e in virThreadPoolWorker (opaque=opaque@entry=0x7f28aec88030) at util/virthreadpool.c:145

In stack frame #6 the client->identity object got unref'd, but the code
that removes the event callbacks in frame #5 did not run yet as we are
trying to obtain the system identity (frames #4, #3, #2).

In other thead:
 #0  virObjectUnref (anyobj=anyobj@entry=0x7f288c162c60) at util/virobject.c:264
        klass = 0xdeadbeef
        obj = 0x7f288c162c60
 #1  0x00007f28ae71c709 in remoteRelayDomainEventCheckACL (client=<optimized out>, conn=<optimized out>, dom=dom@entry=0x7f28aecaafc0) at remote.c:164
 #2  0x00007f28ae71fc83 in remoteRelayDomainEventTrayChange (conn=<optimized out>, dom=0x7f28aecaafc0, ... ) at remote.c:717
 #3  0x00007f28adc04e53 in virDomainEventDispatchDefaultFunc (conn=0x7f287c0009a0, event=0x7f28aecab1a0, ...) at conf/domain_event.c:1455
 #4  0x00007f28adc03831 in virObjectEventStateDispatchCallbacks (callbacks=<optimized out>, ....) at conf/object_event.c:724
 #5  virObjectEventStateQueueDispatch (callbacks=0x7f288c083730, queue=0x7fff51f90030, state=0x7f288c18da20) at conf/object_event.c:738
 #6  virObjectEventStateFlush (state=0x7f288c18da20) at conf/object_event.c:816
 #7  virObjectEventTimer (timer=<optimized out>, opaque=0x7f288c18da20) at conf/object_event.c:562
 #8  0x00007f28adb859cd in virEventPollDispatchTimeouts () at util/vireventpoll.c:459

Frame #0 is unrefing an invalid identity object while frame #2 hints
that the client is still dispatching the event.

For untrimmed backtrace see the bugzilla attachment.

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

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.

As of bba93d40 all of our RPC objects are derived from
virObjectLockable. However, during rewrite some errors sneaked
in. For instance, the dispose functions to virNetClient and
virNetServerClient objects were not only freeing allocated
memory, but unlocking themselves. This is wrong. Object should
never disappear while locked.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

Whenever client socket was marked as closed for some reason, it could've
been changed when really closing the connection.  With this patch the
proper reason is kept since the first time it's marked as closed.
Signed-off-by: NMartin Kletzander <mkletzan@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>

getsockopt(sock->fd, SOL_SOCKET, SO_PEERCRED, ...) sets the pid to 0
when the process that opens the connection is in another container.
Signed-off-by: NGiuseppe Scrivano <gscrivan@redhat.com>

Signed-off-by: NMartin Kletzander <mkletzan@redhat.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.

C guarantees that static variables are zero-initialized.  Some older
compilers (and also gcc -fno-zero-initialized-in-bss) create larger
binaries if you explicitly zero-initialize a static variable.

* src/conf/nwfilter_conf.c: Fix initialization.
* src/cpu/cpu_x86.c: Likewise.
* src/interface/interface_backend_netcf.c: Likewise.
* src/locking/lock_daemon.c: Likewise.
* src/locking/lock_driver_lockd.c: Likewise.
* src/locking/lock_driver_sanlock.c: Likewise.
* src/network/bridge_driver.c: Likewise.
* src/node_device/node_device_udev.c: Likewise.
* src/nwfilter/nwfilter_learnipaddr.c: Likewise.
* src/rpc/virnetserver.c: Likewise.
* src/security/security_selinux.c
(virSecuritySELinuxGenSecurityLabel): Likewise.
Signed-off-by: NEric Blake <eblake@redhat.com>

We have these configuration knobs, like max_clients and
max_anonymous_clients. They limit the number of clients
connected.  Whenever the limit is reached, the daemon stops
accepting new ones and resumes if one of the connected clients
disconnects. If that's the case, a debug message is printed into
the logs. And when the daemon starts over to accept new clients
too. However, the problem is the messages have debug priority.
This may be unfortunate, because if the daemon stops accepting
new clients all of a sudden, and users don't have debug logs
enabled they have no idea what's going on. Raise the messages
level to INFO at least.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Update virNetServerClientCreateIdentity and virIdentityGetSystem
to use the new typesafe APIs for setting identity attributes
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

This way it behaves more like the daemon itself does (acquiring a
pidfile, deleting the socket before binding, etc.).

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=927369
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1138604Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Just remove useless "else".  Best viewed with '-w'.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

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

I'm about to add a syntax check that enforces our documented
HACKING style of always using matching {} on if-else statements.

This patch focuses on all remaining problems, where there weren't
enough issues to warrant splitting it further.

* src/remote/remote_driver.c (doRemoteOpen): Correct use of {}.
* src/security/virt-aa-helper.c (vah_add_path, valid_path, main):
Likewise.
* src/rpc/virnetsocket.c (virNetSocketNewConnectLibSSH2):
Likewise.
* src/esx/esx_vi_types.c (esxVI_Type_FromString): Likewise.
* src/uml/uml_driver.c (umlDomainDetachDevice): Likewise.
* src/util/viralloc.c (virShrinkN): Likewise.
* src/util/virbuffer.c (virBufferURIEncodeString): Likewise.
* src/util/virdbus.c (virDBusCall): Likewise.
* src/util/virnetdev.c (virNetDevValidateConfig): Likewise.
* src/util/virnetdevvportprofile.c
(virNetDevVPortProfileGetNthParent): Likewise.
* src/util/virpci.c (virPCIDeviceIterDevices)
(virPCIDeviceWaitForCleanup)
(virPCIDeviceIsBehindSwitchLackingACS): Likewise.
* src/util/virsocketaddr.c (virSocketAddrGetNumNetmaskBits):
Likewise.
* src/util/viruri.c (virURIParseParams): Likewise.
* daemon/stream.c (daemonStreamHandleAbort): Likewise.
* tests/testutils.c (virtTestResult): Likewise.
* tests/cputest.c (cpuTestBaseline): Likewise.
* tools/virsh-domain.c (cmdDomPMSuspend): Likewise.
* tools/virsh-host.c (cmdNodeSuspend): Likewise.
* src/esx/esx_vi_generator.py (Type.generate_typefromstring):
Tweak generated code.
Signed-off-by: NEric Blake <eblake@redhat.com>

When FIPS mode is on, gnutls_dh_params_generate2 will fail if 1024 is
specified as the prime's number of bits, a bigger value works in both
cases.
Signed-off-by: NGiuseppe Scrivano <gscrivan@redhat.com>

Since 1b807f92, connecting with virsh to an already running session
libvirtd fails with:
$ virsh list --all
error: failed to connect to the hypervisor
error: no valid connection
error: Failed to connect socket to
'/run/user/1000/libvirt/libvirt-sock': Transport endpoint is already
connected

This is caused by a logic error in virNetSocketNewConnectUnix: even if
the connection to the daemon socket succeeded, we still try to spawn the
daemon and then connect to it.
This commit changes the logic to not try to spawn libvirtd if we
successfully connected to its socket.

Most of this commit is whitespace changes, use of -w is recommended to
look at it.

Coverity complained about the following:

(3) Event ptr_arith:
   Performing pointer arithmetic on "cur_fd" in expression "cur_fd++".
130             return virNetServerServiceNewFD(*cur_fd++,

The complaint is that pointer arithmetic taking place instead of the
expected auto increment of the variable...  Adding some well placed
parentheses ensures our order of operation.

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>

Since '1b807f92' - Coverity complains that in the error paths of
both virFork() and virProcessWait() that the 'passfd' will not be closed.
Added the VIR_FORCE_CLOSE(passfd) and initialized it to -1.

Also noted that variable 'buf' was never really used - so I removed it

This eliminates the need for active waiting.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=927369Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

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

It's just a wrapper around NewFD and NewUNIX that selects the right
option and increments the number of used FDs.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

And add a syntax-check for '){$'.  It's not perfect, but better than
nothing.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Replace:
if (virBufferError(&buf)) {
    virBufferFreeAndReset(&buf);
    virReportOOMError();
    ...
}

with:
if (virBufferCheckError(&buf) < 0)
    ...

This should not be a functional change (unless some callers
misused the virBuffer APIs - a different error would be reported
then)

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

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

With parallel boot, network addresses might not yet be assigned [1],
but binding to wildcard addresses should work.

For non-wildcard addresses, ADDRCONFIG is still used. Document this
in libvirtd.conf.

[1] http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/

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>

SO_REUSEADDR on Windows is actually akin to SO_REUSEPORT
on Linux/BSD. ie it allows 2 apps to listen to the same
port at once. Thus we must not set it on Win32 platforms

See http://msdn.microsoft.com/en-us/library/windows/desktop/ms740621.aspxSigned-off-by: NDaniel P. Berrange <berrange@redhat.com>

Fix minor typos in source comments
Signed-off-by: NEric Blake <eblake@redhat.com>