It may shorten the code a bit as the following pattern:

  VIR_STRNDUP(dst, src, cond ? n : strlen(src))

is used on several places among our code. However, we can
move the strlen into virStrndup and thus write just:

  VIR_STRNDUP(dst, src, cond ? n : -1)

s/VIR_ERR_INTERNAL_ERROR/VIR_ERR_XML_ERROR/.

Trivial, but it allows the "error message" to have more spaces.

And improve the error message

Any string returned from virXPathString should be freed.

It's for parsing "login" attribute of "auth".

Ignore strings with an escaped double quote too.

This removes the need for special handling of quotes in the
semicolon check.

Remove error reporting when calling the virNWFilterDHCPSnoopEnd
function with an interface for which no thread is snooping traffic.

Document the usage of this function.
Signed-off-by: NStefan Berger <stefanb@linux.vnet.ibm.com>

Function qemuDomainSetBlockIoTune() was checking QEMU capabilities
even when !(flags & VIR_DOMAIN_AFFECT_LIVE) and the domain was
shutoff, resulting in the following problem:

 virsh # domstate asdf; blkdeviotune asdf vda --write-bytes-sec 100
 shut off

 error: Unable to change block I/O throttle
 error: unsupported configuration: block I/O throttling not supported with this QEMU binary

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

Currently, the controllers argument to virCgroupDetect acts both as
a result filter and a required controller specification, which is
a bit overloaded. If both functionalities are needed, it would be
better to have them seperated into a filter and a requirement mask.
The only situation where it is used today is to ensure that only
CPU related controllers are used for the VCPU directories. But here
we clearly do not want to enforce the existence of cpu, cpuacct and
specifically not cpuset at the same time.
This commit changes the semantics of controllers to "filter only".
Should a required mask ever be needed, more work will have to be done.
Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>

Introduced by commit 1daa4ba3. vshCommandOptStringReq returns
0 on *success* or the option is not required && not present, both
are right result. Error out when returning 0 is not correct.
the caller, it doesn't have to check wether it

This commit is separate due to unusual paradigm compared to the
most source files.

Within whole vircgroup.c we 'return -errno', e.g. 'return -ENOMEM'.
However, in this specific function virCgroupAddTaskStrController
we weren't returning -ENOMEM but -1 despite fact that later in
the function we are returning one of errno values indeed.

Commit '18b14012' refactored the Xen code resulting in a Coverity
warning about possible NULL reference if the path where the XM driver
takes puts the def on it's list.  Moved/duplicated the virGetDomain()
call to pacify the possible NULL deref.

Only /dev/random and /dev/hwrng are accepted, list them explicitly.

Since f03dcc5d we use [::] as the listening address both on qemu
command line in -incoming and in nbd-server-start QMP command.
However the latter requires just :: without the braces.

Don't free the stream on error if we've successfully added it
to the hash table, since it will be freed by virChrdevHashEntryFree
callback.

Preserve the error message before calling virStreamFree, since it
resets the error.

Introduced by 47161382, crashing since 69218922.

Reported by Sergey Fionov on libvir-list.

Previously, we were freeing verr fields instead of rerr which we've
allocated just a line above.

In bf1fe848 I've introduced 'newName' variable to substitute the old
'const char *name' as previously we had an ugly code there:

  name = strdup(name);

However, some parts of the function were not updated, so they were still
calling VIR_FREE(name) instead of VIR_FREE(newName).

There is possibility to jump to 'cleanup' label without tapfd variable
being initialized. In the label, VIR_FORCE_CLOSE(tapfd) is called which
can have fatal consequences.

The same issue as (already fixed) in virDomainCreate -
REMOTE_PROC_DOMAIN_CREATE_WITH_FLAGS doesn't return new domain ID, only
-1 on error or 0 on success.

Besides this one fix it is more general problem - local domain object
ID can desynchronize with the real one, for example in case of another
client creates/destroys domain in the meantime. Perhaps virDomainGetID
should be called remotely (with all performance implications...)? Or
some event-based notification used?
Signed-off-by: NMarek Marczykowski <marmarek@invisiblethingslab.com>

Commit 16251193 forgot to include "virstring.h". Pushed under
build-breaker rule.

Don't print 'OPTION' if there's no options. Just behaves as DESCRIPTION
does.
This mostly affects 'interface' command group.
Signed-off-by: NZhang Xiaohe <zhangxh@cn.fujitsu.com>
Reported-by: NLi Yang <liyang.fnst@cn.fujitsu.com>
Signed-off-by: NEric Blake <eblake@redhat.com>

For future work we need _virDomainEventGraphicsAddress and
_virDomainEventGraphicsSubjectIdentity members to be char * not const
char *. We are strdup()-ing them anyway, so they should have been char *
anyway (from const correctness POV). However, we don't want users to
change passed values, so we need to make the callback's argument const.

Although this is an API change (not ABI though), real callers won't be
impacted. Why?
 1. these callback members are read-only, so it is less likely that
someone is trying to assign into the struct members.
 2. The only way to register a virConnectDomainEventGraphicsCallback is
to cast it through a call to virConnectDomainEventRegisterAny.  That is,
even if the user's callback function leaves out the const, we never use
the typedef as the direct type of any API parameter.  Since they are
already casting their function pointer into a munged type before
registering it, their code will continue to compile.

In my previous patches I enabled the IFF_MULTI_QUEUE flag every
time the user requested multiqueue TAP device. However, this
works only at runtime. During build time the flag may be
undeclared.