We will need some convenient helper functions for managing sysfs-entries
for fibre channel-backed devices. Let's implement them and make them
available in the private API.
Signed-off-by: NBjoern Walk <bwalk@linux.vnet.ibm.com>

Now that the node_device driver is aware of CCW devices, let's hook up
virsh so that we can filter them properly.
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com>
Signed-off-by: NBjoern Walk <bwalk@linux.vnet.ibm.com>

Make CCW devices available to the node_device driver. The devices are
already seen by udev so let's implement necessary code for detecting
them properly.

Topologically, CCW devices are similar to PCI devices, e.g.:

    +- ccw_0_0_1a2b
        |
        +- scsi_host0
            |
            +- scsi_target0_0_0
                |
                +- scsi_0_0_0_0
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Signed-off-by: NBjoern Walk <bwalk@linux.vnet.ibm.com>

Unlock @obj in case of an error too.
Reviewed-by: NBjoern Walk <bwalk@linux.vnet.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Signed-off-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com>

Since the switch statement is already using the deref'd @cap variable
and the VIR_NODE_DEV_CAP_NET case uses it, the SCSI_HOST and PCI_DEV
cases may as well use it too.
Suggested-by: NBjoern Walk <bwalk@linux.vnet.ibm.com>
Signed-off-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com>

QEMU will likely report the details of it shutting down, particularly
whether the shutdown was initiated by the guest or host.  We should
forward that information along, at least for shutdown events.  Reset
has that as well, however that is not a lifecycle event and would add
extra constants that might not be used.  It can be added later on.

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

The number of records that virConnectGetAllDomainStats can return per
domain is currently limited to 4096.  This is quite low -- for
example, a single guest with ~320 disks will hit this limit.  This
increases the limit to make it much larger.  Note that
VIR_NET_MESSAGE_MAX still protects the total message size in the case
where there are many domains and many disks per domain.

I tested this using a guest with 500 disks with no issues.
Signed-off-by: NRichard W.M. Jones <rjones@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1440683

When increasing the buffer size up to VIR_NET_MESSAGE_MAX, we
currently quadruple it each time.  This unfortunately means that we
cannot allow certain buffer sizes -- for example the current
VIR_NET_MESSAGE_MAX == 33554432 can never be "hit" since ‘newlen’
jumps from 16MB to 64MB.

Instead of quadrupling, double it each time.

Thanks: Daniel Berrange.
Signed-off-by: NRichard W.M. Jones <rjones@redhat.com>

Commit 4337bc57 introduced code that would in certain error paths
unref the last reference of a pointer, but return it.

Clear the pointers before returning them.

@tmp is leaked after the second call to virVHBAGetConfig within
virVHBAIsVportCapable code block because it wasn't freed after making the
first call to the function.
Signed-off-by: NYi Wang <wang.yi59@zte.com.cn>
Signed-off-by: NErik Skultety <eskultet@redhat.com>

The @ipv6_host allocated in virAsprintf may be lost when virAsprintf
addrstr failed.
Signed-off-by: NYi Wang <wang.yi59@zte.com.cn>
Signed-off-by: NErik Skultety <eskultet@redhat.com>

There is a VIR_FREE after a return statement. That code section is never
executed and for this reason the "tty" variable is not being freed. This
commit rearranges the logic.
Signed-off-by: NJulio Faracco <jcfaracco@gmail.com>

This commit fixes an acl missing variable. The virt-acl.m4 inside the
macro directory does not contain the variable 'with_acl'. So, it is
being set as an empty string "with_acl=''". This is causing a missing
option during the configuration, even if you have acl libs installed.
Signed-off-by: NJulio Faracco <jcfaracco@gmail.com>

This option turns on extended interrupt mode,
which allows more than 255 vCPUs.

https://bugzilla.redhat.com/show_bug.cgi?id=1451282Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Add an attribute to control extended interrupt mode.

https://bugzilla.redhat.com/show_bug.cgi?id=1451282Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

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

Due to how the processing for authentication using polkit works, the
virshConnect code must first "attempt" an virConnectOpenAuth and then
check for a "special" return error code VIR_ERR_AUTH_UNAVAILABLE in
order to attempt to "retry" the authentication after performing a creation
of a pkttyagent to handle the challenge/response for the client.

However, if pkttyagent creation is not possible for the authentication
being attempted (such as perhaps a "qemu+ssh://someuser@localhost/system"),
then the same failure pattern would be returned and another attempt to
create a pkttyagent would be done. This would continue "forever" until
someone forced quit (e.g. ctrl-c) from virsh as the 'authfail' was not
incremented when creating the pkttyagent.

So add a 'agentCreated' boolean to track if we've attempted to create the
agent at least once and force a failure if that creation returned the same
error pattern.

This resolves a possible never ending loop and will generate an error:

error: failed to connect to the hypervisor
error: authentication unavailable: no polkit agent available to authenticate action 'org.libvirt.unix.manage'

NB: If the authentication was for a sufficiently privileged client, such as
qemu+ssh://root@localhost/system, then the remoteDispatchAuthList "allows"
the authentication to use libvirt since @callerUid would be 0.

'param' contains the correct element from 'params'.

If the group name would not be the first parameter libvirtd would crash.

Introduced in c53bd25b.

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

Disclose the content of the 'test-suite.log' file (if available) in
case of failures inside Travis-CI. This is needed to understand what
happened and to provide hints about the proper fix (if applicable).

The checks are scattered all over the place. Move them into a
single function.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Many vendor id's and product id's have leading zeros.  We should show
them in the logs.
Signed-off-by: NChen Hanxiao <chenhanxiao@gmail.com>
Reviewed-by: NLaine Stump <laine@laine.org>

The @meminfo allocated in qemuMonitorGetMemoryDeviceInfo() may be
lost when qemuDomainObjExitMonitor() failed.
Signed-off-by: NYi Wang <wang.yi59@zte.com.cn>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

Testing found an inventive way to cause an error at shutdown by providing the
parent name for the fc host creation using the "same name" as the HBA. Since
the code thus assumed the parent host name provided was the parent HBA and
just extracted out the host number and sent that along to the vport_destroy
this avoided checks made for equality.

So just add the equality check to that path to resolve.

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

While most of the APIs are okay with 16M messages, the bulk stats API
can run into the limit in big configurations. Before we devise a new
plan for this, bump this limit slightly to accomodate some more configs.

If the first console is just a copy of the first serial device we
don't need to iterate over the same device twice in order to perform
actions like security labeling, cgroup configuring, etc.

Currently only security SELinux manager was aware of this fact.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

No need begin job for asynchronous operation.
Signed-off-by: NKonstantin Neumoin <kneumoin@virtuozzo.com>

Put domain access after acquiring job condition, otherwise
another job can change it meanwhile.
Signed-off-by: NKonstantin Neumoin <kneumoin@virtuozzo.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

We have to use waitDomainJob instead of waitJob, because of it
unlock the domain until job has finished, so domain will be available
for other clients.
Signed-off-by: NKonstantin Neumoin <kneumoin@virtuozzo.com>

Setting the 'group_name' for a disk would falsely trigger a error path
as in commit 4b57f765 we did not properly check the return value of
VIR_STRDUP.

Attempting to start a domain with USB hostdevs but no USB controllers
fails with the rather cryptic error

libxl: error: libxl_qmp.c:287:qmp_handle_error_response: received an
error message from QMP server: Bus 'xenusb-0.0' not found

This can be fixed by creating default USB controllers. When no USB
controllers are defined, create the number of 8 port controllers
necessary to accommodate the number of defined USB devices.

Note that USB controllers are already created as needed in the
domainAttachDevice code path. E.g. a USB controller will be created,
if necessary, when attaching a USB device with
'virsh attach-device dom usbdev.xml'.

Otherwise the private data entry would be kept across instances of the
same VM even if it's not configured to do so.

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

priv and qemuCaps variables are not used anymore.
Signed-off-by: NKothapally Madhu Pavan <kmp@linux.vnet.ibm.com>

This reverts commit 2841e675.

It turns out that adding the host_mtu field to the PCI capabilities in
the guest bumps the length of PCI capabilities beyond the 32 byte
boundary, so the virtio-net device gets 64 bytes of ioport space
instead of 32, which offsets the address of all the other following
devices. Migration doesn't work very well when the location and length
of PCI capabilities of devices is changed between source and
destination.

This means that we need to make sure that the absence/presence of
host_mtu on the qemu commandline always matches between source and
destination, which means that we need to make setting of host_mtu an
opt-in thing (it can't happen automatically when the bridge being used
has a non-default MTU, which is what commit 2841e675 implemented).

I do want to re-implement this feature with an <mtu auto='on'/>
setting, but probably won't backport that to any stable branches, so
I'm first reverting the original commit, and that revert can be pushed
to the few releases that have been made since the original (3.1.0 -
3.3.0)

Resolves: https://bugzilla.redhat.com/1449346

If a VNC listen address is not specified in domXML, libxl
will default to 127.0.0.1, but this is never reflected in the domXML.
In the case of spice, a missing listen address resulted in listening
on all interfaces, i.e. '0.0.0.0'. If not specified, set the listen
address in virDomainGraphicsDef struct to the libxl default when
creating the frame buffer device. Additionally, set default spice
listen address to 127.0.0.1.

Use a macro instead of hardcoding "127.0.0.1" throughout the
sources.

The current README file contents has almost no useful info, and that
which does exist is very outdated.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

There's a slight problem with the current function. Assume we are
currently in a data section and we have say 42 bytes until next
section. Therefore, just before (handler) is called to fill up
the buffer with data, @want is changed to 42 to match the amount
of data left in the current section. However, after hole is
processed, we are back in data section but with incredibly small
@want size. Nobody will ever reset it back. This results in
incredible data fragmentation.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Commit 6fb5dd4f removed docs/archnetwork.html.in, but
left behind a pointer to it in docs/formatnetwork.html.in.

Update it so that it points to the wiki, which contains
more detailed and recent information anyway.

To every virDirOpen we must have VIR_DIR_CLOSE otherwise FD is
leaked.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Only set releaseaddr to true after the address has been
reserved successfully.

https://bugzilla.redhat.com/show_bug.cgi?id=1452581Reviewed-by: NJohn Ferlan <jferlan@redhat.com>