Split the virDBusMethodCall method into a couple of new methods
virDBusCall, virDBusCreateMethod and virDBusCreateMethodV.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

virLogParseDefaultPriority's successful return value is the same as
virLogSetDefaultPriority's successful return value. So it should be 0
rather than the parsed log level.
Signed-off-by: NZhou Yimin <zhouyimin@huawei.com>

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

When attaching a new device, we need to check if its boot order
configuration is compatible with current domain definition.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The offset of virDomainDeviceInfo structure within a device definition
varies with device type and some types do not contain the info structure
at all. This new API makes it easier to access the info structure from a
generic virDomainDeviceDef structure.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

When checking compatibility of a device with a domain definition, we
should know what we're going to do with the device. Because we may need
to check for different things when we're attaching a new device versus
detaching an existing device.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

A device needs to be checked for compatibility with the domain
definition it corresponds to. Specifically, for VIR_DOMAIN_AFFECT_CONFIG
case we should check against persistent def rather than active def.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

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

When qemu dies early after connecting to its monitor but before we
actually try to read something from the monitor, we would just fail
domain start with useless message:

    "An error occurred, but the cause is unknown"

This is because the real error gets reported in a monitor EOF handler
executing within libvirt's event loop.

The fix is to take any error set in qemuMonitor structure and propagate
it into the thread-local error when qemuMonitorClose is called and no
thread-local error is set.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

When listening for a subset of monitor events, it can be tedious
to register for each event name in series; nicer is to register
for multiple events in one go.  Implement a flag to use regex
interpretation of the event filter.

While at it, prove how much I hate the shift key, by adding a
way to filter for 'shutdown' instead of 'SHUTDOWN'. :)

* include/libvirt/libvirt-qemu.h
(virConnectDomainQemuMonitorEventRegisterFlags): New enum.
* src/libvirt-qemu.c (virConnectDomainQemuMonitorEventRegister):
Document flags.
* tools/virsh-domain.c (cmdQemuMonitorEvent): Expose them.
* tools/virsh.pod (qemu-monitor-event): Document this.
* src/conf/domain_event.c
(virDomainQemuMonitorEventStateRegisterID): Add flags.
(virDomainQemuMonitorEventFilter): Handle regex, and optimize
client side.
(virDomainQemuMonitorEventCleanup): Clean up regex.
Signed-off-by: NEric Blake <eblake@redhat.com>

Filtering monitor events by name requires tracking the name for
the duration of the filtering.  In order to free the name, I
found it easiest to just piggyback on the user's freecb function,
which gets called when the event is deregistered.

For events without a name filter, we have the design of multiple
client registrations sharing a common server registration, because
the server side uses the same callback function and we reject
duplicate use of the same function.  But with events in the mix,
we want to be able to allow the same function pointer to be used
with more than one event name.  The solution is to tweak the
duplicate detection code to only act when there is no additional
filtering; if name filtering is in use, there is exactly one
client registration per server registration.  Yes, this means
that there is no longer a bound on the number of server
registrations possible, so a malicious client could repeatedly
register for the same name event to exhaust server memory.  On
the other hand, we already restricted monitor events to require
write access (compared to normal events only needing read access),
and separated it into the intentionally unsupported
libvirt-qemu.so, with documentation that using this function is
for debug purposes only; so it is not a security risk worth
worrying about a client trying to abuse multiple registrations.

* src/conf/domain_event.c (virDomainQemuMonitorEventData): New
struct.
(virDomainQemuMonitorEventFilter)
(virDomainQemuMonitorEventCleanup): New functions.
(virDomainQemuMonitorEventDispatchFunc)
(virDomainQemuMonitorEventStateRegisterID): Use new struct.
* src/conf/object_event.c (virObjectEventCallbackListCount)
(virObjectEventCallbackListAddID)
(virObjectEventCallbackListRemoveID)
(virObjectEventCallbackListMarkDeleteID): Drop duplicate detection
when filtering is in effect.
Signed-off-by: NEric Blake <eblake@redhat.com>

Wire up all the pieces to send arbitrary qemu events to a
client using libvirt-qemu.so.  If the extra bookkeeping of
generating event objects even when no one is listening turns
out to be noticeable, we can try to further optimize things
by adding a counter for how many connections are using events,
and only dump events when the counter is non-zero; but for
now, I didn't think it was worth the code complexity.

* src/qemu/qemu_driver.c
(qemuConnectDomainQemuMonitorEventRegister)
(qemuConnectDomainQemuMonitorEventDeregister): New functions.
* src/qemu/qemu_monitor.h (qemuMonitorEmitEvent): New prototype.
(qemuMonitorDomainEventCallback): New typedef.
* src/qemu/qemu_monitor_json.c (qemuMonitorJSONIOProcessEvent):
Report events.
* src/qemu/qemu_monitor.c (qemuMonitorEmitEvent): New function, to
pass events through.
* src/qemu/qemu_process.c (qemuProcessHandleEvent): Likewise.
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>

Create qemu monitor events as a distinct class to normal domain
events, because they will be filtered differently.  For ease of
review, the logic for filtering by event name is saved for a later
patch.

* src/conf/domain_event.c (virDomainQemuMonitorEventClass): New
class.
(virDomainEventsOnceInit): Register it.
(virDomainQemuMonitorEventDispose, virDomainQemuMonitorEventNew)
(virDomainQemuMonitorEventDispatchFunc)
(virDomainQemuMonitorEventStateRegisterID): New functions.
* src/conf/domain_event.h (virDomainQemuMonitorEventNew)
(virDomainQemuMonitorEventStateRegisterID): New prototypes.
* src/libvirt_private.syms (conf/domain_conf.h): Export them.

Several times in the past, qemu has implemented a new event,
but libvirt has not yet caught up to reporting that event to
the user applications.  While it is possible to track libvirt
logs to see that an unknown event was received and ignored,
it would be nicer to copy what 'virsh qemu-monitor-command'
does, and expose this information to the end developer as
one of our unsupported qemu-specific commands.

If you find yourself needing to use this API for more than
just development purposes, please ask on the libvirt list
for a supported counterpart event to be added in libvirt.so.

While the supported virConnectDomainEventRegisterAny() API
takes an id which determines the signature of the callback,
this version takes a string filter and always uses the same
signature.  Furthermore, I chose to expose this as a new API
instead of trying to add a new eventID at the top level, in
part because the generic option lacks event name filtering,
and in part because the normal domain event namespace should
not be polluted by a qemu-only event.  I also added a flags
argument; unused for now, but we might decide to use it to
allow a user to request event names by glob or regex instead
of literal match.

This API intentionally requires full write access (while
normal event registration is allowed on read-only clients);
this is in part due to the fact that it should only be used
by debugging situations, and in part because the design of
per-event filtering in later patches ended up allowing for
duplicate registrations that could potentially be abused to
exhaust server memory - requiring write privileges means
that such abuse will not serve as a denial of service attack
against users with higher privileges.

* include/libvirt/libvirt-qemu.h
(virConnectDomainQemuMonitorEventCallback)
(virConnectDomainQemuMonitorEventRegister)
(virConnectDomainQemuMonitorEventDeregister): New prototypes.
* src/libvirt-qemu.c (virConnectDomainQemuMonitorEventRegister)
(virConnectDomainQemuMonitorEventDeregister): New functions.
* src/libvirt_qemu.syms (LIBVIRT_QEMU_1.2.1): Export them.
* src/driver.h (virDrvConnectDomainQemuMonitorEventRegister)
(virDrvConnectDomainQemuMonitorEventDeregister): New callbacks.
Signed-off-by: NEric Blake <eblake@redhat.com>

If we cannot stat/open a file on pool refresh, returning -1 aborts
the refresh and the pool is undefined.

Only treat missing files as fatal unless VolOpenCheckMode is called
with the VIR_STORAGE_VOL_OPEN_ERROR flag. If this flag is missing
(when it's called from virStorageBackendProbeTarget in
virStorageBackendFileSystemRefresh), only emit a warning and return
-2 to let the caller skip over the file.

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

Without this, using /dev/mapper as a directory pool
fails in virStorageBackendUpdateVolTargetInfoFD:
cannot seek to end of file '/dev/mapper/control': Illegal seek

Skip over character devices by default.

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

Remove the 'StorageBackend' from names of the functions and fix
indentation.

virStorageBackendISCSISession only needs the path of the source
device and virStorageBackendISCSIRescanLUNs doesn't need the pool
at all.

This will allow the functions to be moved to src/util.

Create ISCSIConnection{Login,Logout} wrappers for that.

Instead of running the command asynchronously and reading the output
via fgets, let virCommand collect the output and split it with
virStringSplit.

The only storage-specific parameter is the pool object, which
is only used for passing to the callback function.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Per the documentation, is_selinux_enabled() returns -1 on error.
Account for this. Previously when -1 was being returned the condition
would still be true. I was noticing this because on my system that has
selinux disabled I was getting this in the libvirt.log every 5
seconds:

error : virIdentityGetSystem:173 : Unable to lookup SELinux process context: Invalid argument

With this patch applied, I no longer get these messages every 5
seconds. I am submitting this in case its deemed useful for inclusion.
Anyone have any comments on this change? This is a patch off current
master.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

New functionalities:
- connectGetMaxVcpus - on bhyve hardcode this value to 16
- nodeGetFreeMemory - do not use physmem_get on FreeBSD, since
                      it might get wrong value on systems with
                      more than 100GB of RAM
- nodeGetCPUMap - wrapper only for mapping function, currently not
                  supported by FreeBSD
- nodeSet/GetMemoryParameters - wrapper only for future improvements,
                                currently not supported by FreeBSD

The virSocketAddrMask method did not initialize all fields
in the sockaddr_in6 struct. In paticular the 'sin6_scope_id'
field could contain random garbage, which would in turn
affect the result of any later virSocketAddrFormat calls.
This led to ip6tables rules in the FORWARD chain which
matched on random garbage sin6_scope_id. Fortunately these
were ACCEPT rules, so the impact was merely that desired
traffic was blocked, rather than undesired traffic allowed.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Valgrind reported leaking of maxCpus and arch strings from
virXPathString, as well as the leak of the machineMaxCpus array.

Don't use 'str' for the strings we don't want to free, to allow
freeing of 'str' in the cleanup label and free machineMaxCpus
in virCapsReset too.