Now that the virAuthGet*Path API's generate all the error messages
we can remove them from the callers. This means that we will no
longer overwrite the error from the API.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NMarcos Paulo de Souza <marcos.souza.org@gmail.com>

Now that the virAuthGet*Path API's generate all the error messages
we can remove them from the callers. This means that we will no
longer overwrite the error from the API.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NMarcos Paulo de Souza <marcos.souza.org@gmail.com>

Now that the virAuthGet*Path API's generate all the error messages
we can remove them from the callers. This means that we will no
longer overwrite the error from the API.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NMarcos Paulo de Souza <marcos.souza.org@gmail.com>

Rather than forcing the caller to generate an error, let's
generate the Username or Password error message failure if
the auth->cb fails. This is the last error path that needs
a specific message for various callers.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NMarcos Paulo de Souza <marcos.souza.org@gmail.com>

If we never find the valid credtype in the list, then we'd return
NULL without an error signaled forcing the caller to generate one
that will probably be incorrect. Let's be specific.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NMarcos Paulo de Souza <marcos.souza.org@gmail.com>

Now that the virAuthGet*Path helpers make the checks, we can remove
them from here.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NMarcos Paulo de Souza <marcos.souza.org@gmail.com>

Before trying to call @auth->cb, let's ensure it exists.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NMarcos Paulo de Souza <marcos.souza.org@gmail.com>

Before trying to dereference @auth, let's ensure it's valid.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NMarcos Paulo de Souza <marcos.souza.org@gmail.com>

The virSecretGetSecretString() helper looks up a secret for given
pool and returns its value in @secret_value and its length in
@secret_value_size. However, the trailing '\0' is not included in
either of the variables. This is because usually the value of the
secret is passed to some encoder (usually base64 encoder) where
the trailing zero must not be accounted for.

However, in two places we actually want the string as we don't
process it any further.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

As advertised in the previous commit, we need the list of
accessed files to also contain action that caused the $path to
appear on the list. Not only this enables us to fine tune our
white list rules it also helps us to see why $path is reported.
For instance:

  /run/user/1000/libvirt/libvirt-sock: connect: qemuxml2argvtest: QEMU XML-2-ARGV net-vhostuser-multiq
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

The check-file-access.pl script is used to match access list
generated by virtestmock against whitelisted rules stored in
file_access_whitelist.txt. So far the rules are in form:

  $path: $progname: $testname

This is not sufficient because the rule does not take into
account 'action' that caused $path to appear in the list of
accessed files. After this commit the rule can be in new form:

  $path: $action: $progname: $testname

where $action is one from ("open", "fopen", "access", "stat",
"lstat", "connect"). This way the white list can be fine tuned to
allow say access() but not connect().
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

So far we are setting only fake secret and storage drivers.
Therefore if the code wants to call a public NWFilter API (like
qemuBuildInterfaceCommandLine() and qemuBuildNetCommandLine() are
doing) the virGetConnectNWFilter() function will try to actually
spawn session daemon because there's no connection object set to
handle NWFilter driver.

Even though I haven't experienced the same problem with the rest
of the drivers (interface, network and node dev), the reasoning
above can be applied to them as well.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Update for the release of qemu 3.0.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NBing Niu <bing.niu@intel.com>

Semantically, there is no difference between an uninitialized worker
pool and an initialized worker pool with zero workers. Let's allow the
worker pool to be initialized for max_workers=0 as well then which
makes the API more symmetric and simplifies code. Validity of the
worker pool is delegated to virThreadPoolGetMaxWorkers instead.

This patch fixes segmentation faults in
virNetServerGetThreadPoolParameters and
virNetServerSetThreadPoolParameters for the case when no worker pool
is actually initialized (max_workers=0).
Signed-off-by: NMarc Hartmayer <mhartmay@linux.ibm.com>

Since they are done inside virAuthGetPassword and virAuthGetUsername
when needed. Also, only auth is checked, but auth->cb, which that could
lead to a crash if the callback is NULL.
Signed-off-by: NMarcos Paulo de Souza <marcos.souza.org@gmail.com>

Since they are done inside virAuthGetPassword and virAuthGetUsername
when needed.
Signed-off-by: NMarcos Paulo de Souza <marcos.souza.org@gmail.com>

Since they are done inside virAuthGetPassword and virAuthGetUsername
when needed.
Signed-off-by: NMarcos Paulo de Souza <marcos.souza.org@gmail.com>

Since they are done inside virAuthGetPassword and virAuthGetUsername
when needed.
Signed-off-by: NMarcos Paulo de Souza <marcos.souza.org@gmail.com>

Instead of adding the same check for every drivers, execute the checks
in virAuthGetUsername and virAuthGetPassword. These funtions are called
when user is not set in the URI.
Signed-off-by: NMarcos Paulo de Souza <marcos.souza.org@gmail.com>

Currently iohelper's error log is recorded in virFileWrapperFdClose.
However, if something goes wrong the caller might not even get to
calling virFileWrapperFdClose and call virFileWrapperFdFree
directly. Therefore the error reporting should happen there.
Signed-off-by: Nxinhua.Cao <caoxinhua@huawei.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This proves libvirt can now handle high socket_id and
core_id values correctly and ensures we won't introduce
regressions in this area.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

While in most cases the values are going to be much
smaller than our arbitrary 4096 limit, there is really
no guarantee that would be the case: in fact, a few
aarch64 servers have been spotted in the wild with
core_id as high as 6216.

Take advantage of virBitmap's ability to automatically
alter its size at runtime to accomodate such values.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

The latter are no longer used by libvirt, and the former
never were; moreover, both have a corresponding *_list
file which we can manipulate very conveniently using our
bitmap APIs, so dropping them makes sure in the future
developers will look into that rather than trying to
parse the kernel binary bitmaps.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

We already have a function which parses
thread_siblings_list for a CPU and returns the
corresponding bitmap, and a bunch of utility functions
that perform operations on bitmaps such as counting
the number of set bits: use those to implement the
function instead of having an additional ad-hoc parser
for thread_siblings.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

Some of the data dumps didn't include them; luckily,
we're not actually missing any information since we
can recreate them by looking at the corresponding
thread_sibilings files.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

Added by mistake with commit a0fdd2f6.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

Unused since commit c67e04e2.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

Most distributions we build RPMs on don't ship a
recent enough version of libiscsi, so we can't enable
the driver unconditionally. Add an explicit dependency
on the runtime package while at it.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Commit 34a6962c added a BuildRequires for the
iscsi-direct backend, but we need the headers rather
than the runtime package to be available in order to
link against the library.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

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

Commit id d45bee44 updated the pool-define-as qualifier descriptions
to add some new fields, but neglected to modify the command item list
in order to add those fields as well.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Caused by commit f7d0663d. The problem is missing libnl library on
these platforms, so the VIR_DEFINE_AUTOPTR_FUNC has to be compiled in
conditionally.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

name match functions to be the vir prefix and interface name followed by ObjMatch

    ex. for virNetworkObjListExport, the match function is named
        virNetworkObjMatch
Signed-off-by: NAnya Harter <aharter@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

name functions to be the name of the export function followed by Callback

    ex. for virInterfaceObjListExport, the callback function is named
        virInterfaceObjListExportCallback
Signed-off-by: NAnya Harter <aharter@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

name structs to be the name of the Export function followed by Data
also tweak definitions to follow standard struct definition pattern

    ex. for virInterfaceObjListExport, the struct is defined as follows:

        typedef struct _virInterfaceObjListExportData virInterfaceObjListExportData;
        typedef virInterfaceObjListExportData *virInterfaceObjListExportDataPtr;
        struct _virInterfaceObjListExportData {...};
Signed-off-by: NAnya Harter <aharter@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

When building libvirt with libcurl debug enabled (with
ESX_VI__CURL__ENABLE_DEBUG_OUTPUT set), the message bellow pops up:

make[3]: Entering directory '/mnt/data/gitroot/libvirt/src'
  CC       esx/libvirt_driver_esx_la-esx_vi.lo
esx/esx_vi.c: In function 'esxVI_CURL_Debug':
esx/esx_vi.c:191:5: error: enumeration value 'CURLINFO_SSL_DATA_IN' not handled in switch [-Werror=switch-enum]
     switch (type) {
     ^~~~~~
esx/esx_vi.c:191:5: error: enumeration value 'CURLINFO_SSL_DATA_OUT' not handled in switch [-Werror=switch-enum]
esx/esx_vi.c:191:5: error: enumeration value 'CURLINFO_END' not handled in switch [-Werror=switch-enum]

Our build requires at least libcurl 7.18.0, which is pretty stable since
it was release in 2008. Fix this problem by handling the mentioned enums
in the code.
Signed-off-by: NMarcos Paulo de Souza <marcos.souza.org@gmail.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Add new XML section to report host's memory bandwidth allocation
capability. The format as below example:

 <host>
 .....
   <memory_bandwidth>
     <node id='0' cpus='0-19'>
       <control granularity='10' min ='10' maxAllocs='8'/>
     </node>
   </memory_bandwidth>
</host>

granularity   ---- granularity of memory bandwidth, unit percentage.
min           ---- minimum memory bandwidth allowed, unit percentage.
maxAllocs     ---- maximum memory bandwidth allocation group supported.
Signed-off-by: NBing Niu <bing.niu@intel.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Add return value check to virResctrlAllocForeachCache in
virDomainCachetuneDefFormat. The virResctrlAllocForeachCache does have
return value, so need check return value to make sure function executed
without error.
Signed-off-by: NBing Niu <bing.niu@intel.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Introduce a new section memorytune to support memory bandwidth allocation.
This is consistent with existing cachetune. As the example:
below:
  <cputune>
    ......
    <memorytune vcpus='0'>
      <node id='0' bandwidth='30'/>
    </memorytune>
  </cputune>

vpus      --- vpus subjected to this memory bandwidth.
id        --- on which node memory bandwidth to be set.
bandwidth --- the memory bandwidth percent to set.
Signed-off-by: NBing Niu <bing.niu@intel.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Factor out vcpus virDomainResctrlDef update from
virDomainCachetuneDefParse and introduce virDomainResctrlAppend.
virDomainResctrlAppend will format vcpus string and append a new
virDomainResctrlDef to virDomainDefPtr. So that this logic can
be reusable.
Signed-off-by: NBing Niu <bing.niu@intel.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>