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

This is necessary to be able to get statistics for venet0 or
"host-routed" adapter, which has -1 index and thus, its statistics
is shown as "net.nic4294967295".
Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>

Commit 815d98ac started auto-adding one hub if there are more USB devices
than available USB ports.

This was a strange choice, since there might be even more devices.
Before USB address allocation was implemented in libvirt, QEMU
automatically added a new USB hub if the old one was full.

Adjust the logic to try adding as many hubs as will be needed
to plug in all the specified devices.

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

For reusing in qemu_domain_address.c.

As bhyve for a long time didn't have a notion of the explicit SATA
controller and created a controller for each drive, the bhyve driver
in libvirt acted in a similar way and didn't care about the SATA
controllers and assigned PCI addresses to drives directly, as
the generated command will look like this anyway:

 2:0,ahci-hd,somedisk.img

This no longer makes sense because:

 1. After commit c07d1c1c it's not possible to assign
    PCI addresses to disks
 2. Bhyve now supports multiple disk drives for a controller,
    so it's going away from 1:1 controller:disk mapping, so
    the controller object starts to make more sense now

So, this patch does the following:

 - Assign PCI address to SATA controllers (previously we didn't do this)
 - Assign disk addresses instead of PCI addresses for disks. Now, when
   building a bhyve command, we take PCI address not from the disk
   itself but from its controller
 - Assign addresses at XML parsing time using the
   assignAddressesCallback. This is done mainly for being able to
   verify address allocation via xml2xml tests
 - Adjust existing bhyvexml2{xml,argv} tests to chase the new
   address allocation

This patch is largely based on work of Fabian Freyer.

Add virBhyveDriverCreateXMLConf, a simple wrapper around
virDomainXMLOptionNew that makes it easier to pass bhyveConnPtr
as a private data for parser. It will be used later for device
address allocation at parsing time.

Update consumers to use it instead of direct calls to
virDomainXMLOptionNew.

As we now have proper callbacks connected for the tests, update
test files accordingly to include the automatically generated
PCI root controller.

Introduce a BHYVE_CAP_AHCI32SLOT capability that shows
if 32 devices per SATA controller are supported, and
a bhyveProbeCapsAHCI32Slot function that probes it.

Because this is invalid xml for containers. This patch almost
reverts 7eda8369, but still skips converting vz sdk bootorder
for containers to libvirt bootorder because we use boot order
in containers for quite different purpurse.

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

Add recently created modules to the download page list.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

==12618== 110 bytes in 10 blocks are definitely lost in loss record 269 of 295
==12618==    at 0x4C2AE5F: malloc (vg_replace_malloc.c:297)
==12618==    by 0x1CFC6DD7: vasprintf (vasprintf.c:73)
==12618==    by 0x1912B2FC: virVasprintfInternal (virstring.c:551)
==12618==    by 0x1912B411: virAsprintfInternal (virstring.c:572)
==12618==    by 0x50B1FF: qemuAliasChardevFromDevAlias (qemu_alias.c:638)
==12618==    by 0x518CCE: qemuBuildChrChardevStr (qemu_command.c:4973)
==12618==    by 0x522DA0: qemuBuildShmemBackendChrStr (qemu_command.c:8674)
==12618==    by 0x523209: qemuBuildShmemCommandLine (qemu_command.c:8789)
==12618==    by 0x526135: qemuBuildCommandLine (qemu_command.c:9843)
==12618==    by 0x48B4BA: qemuProcessCreatePretendCmd (qemu_process.c:5897)
==12618==    by 0x4378C9: testCompareXMLToArgv (qemuxml2argvtest.c:498)
==12618==    by 0x44D5A6: virTestRun (testutils.c:180)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

For example when both total_bytes_sec and total_bytes_sec_max are set,
but the former gets cleaned due to new call setting, let's say,
read_bytes_sec, we end up with this weird message for the command:

 $ virsh blkdeviotune fedora vda --read-bytes-sec 3000
 error: Unable to change block I/O throttle
 error: unsupported configuration: value 'total_bytes_sec_max' cannot be set if 'total_bytes_sec' is not set

So let's make it more descriptive.  This is how it looks after the change:

 $ virsh blkdeviotune fedora vda --read-bytes-sec 3000
 error: Unable to change block I/O throttle
 error: unsupported configuration: cannot reset 'total_bytes_sec' when 'total_bytes_sec_max' is set

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

All options started with underscores, but we switched them to dashes
later on, making the style consistent.  The latest addition, however,
did not respect that, so let's change that as well.  It is tempting to
just change the name instead of adding alias, especially since nobody
ever used it, which we know thanks to the fact that it didn't work.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Function vshCommandOptStringReq() returns -1 on error and 0 on
success.  The code, however, used the 'group_name' variable only if it
returned 1 (never).
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Well, just two.  One indentation and the usage of 'ret'.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

We were setting it based on whether it was supported and that lead to
setting it to NULL, which our JSON code caught.  However it ended up
producing the following results:

 $ virsh blkdeviotune fedora vda --total-bytes-sec-max 2000
 error: Unable to change block I/O throttle
 error: internal error: argument key 'group' must not have null value
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

The input and output were the same, but the output file did not
correspond to what libvirt would output.

The 'fs' backend m4 code was copied, but one of the condition were not
changed which resulted into:

configure:    Gluster: yes
configure:        ZFS: yes
configure: Virtuozzo storage: check

Make the code turn on the virtuozzo driver automatically if the tools
are found.

The issue is that if this graphics definition is provided:

  <graphics type='vnc' port='0'/>

it's parsed as:

  <graphics type='vnc' autoport='no'>
    <listen type='address'/>
  </graphics>

but if the resulting XML is parsed again the output is:

  <graphics type='vnc' port='-1' autoport='yes'>
    <listen type='address'/>
  </graphics>

and this should not happen.  The XML have to always remain the same
after it was already parsed by libvirt.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1383039Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

If the passwd attribute is set to empty string it disables VNC/SPICE
access to the guest.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>

As LIBVIRT_DEBUG=4 logs only error messages and there
are no levels above it, adjusting the description in
the man page accordingly.
Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>

Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>

Currently, on every --enable perf_event command,
a new event->fd is created and counting of perf
event counter starts from zero and previous
event->fd is lost. This patch prevents this
behaviour.
Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>

This commit is similar to commit 0977ada8.The virsh manpage
lists options --uuid and --name as mutually exclusive if
option --details is specified when actually the option
--details is mutually exclusive and can't go with options
--uuid and/or --name. This patch rewords the virsh manpage
to state the correct meaning.
Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>

Needed storage_util.h - missed while merging '5f07c3c0' with
commit id '479a2f16'.
Signed-off-by: NOlga Krishtal <okrishtal@virtuozzo.com>

Commit id '5f07c3c0' broke the freebsd build in the libvirt CI test
environment because the UMOUNT was not defined unless WITH_STORAGE_FS
is defined.

So remove the virStorageBackendUmountLocal from storage_util.c,h and
restore the code back in the storage_backend_fs.c and _vstorage.c
modules.

Signed-off-by: NOlga Krishtal <okrishtal@virtuozzo.com>

Added create/define/etc pool operations for vstorage backend.

Used the common/local pool API's from storage_util for operations
that are not specific to vstorage. In particular Refresh and Delete
Pool operations as well as all the Volume operations.
Signed-off-by: NOlga Krishtal <okrishtal@virtuozzo.com>

Added general definitions for vstorage pool backend including
the build options to add --with-storage-vstorage checking.
In order to use vstorage as a backend for a storage pool
vstorage tools (vstorage and vstorage-mount) need to be installed.
Signed-off-by: NOlga Krishtal <okrishtal@virtuozzo.com>

Move all the volume functions to storage_util to create local/common helpers
using the same naming syntax as the existing upload, download, and wipe
virStorageBackend*Local API's.

In the process of doing so, found more API's that can now become local
to storage_util. In order to distinguish between local/external - I
changed the names of the now local only ones from "virStorageBackend..."
to just "storageBackend..."
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>