Building with gnutls 3.2.0 (such as shipped with current cygwin) fails
with:
rpc/virnettlscontext.c: In function 'virNetTLSSessionGetKeySize':
rpc/virnettlscontext.c:1358:5: error: implicit declaration of function 'gnutls_cipher_get_key_size' [-Wimplicit-function-declaration]
Yeah, it's stupid that gnutls broke API by moving their declaration
into a new header without including that header from the old one,
but it's easy enough to work around, all without breaking on gnutls
1.4.1 (hello RHEL 5) that lacked the new header.
* configure.ac (gnutls): Check for <gnutls/crypto.h>.
* src/rpc/virnettlscontext.c (includes): Include additional header.
Signed-off-by: Eric Blake <eblake@redhat.com>
And error out if the casted value is not same with the original
one, which prevents the bug on platform(s) where uid_t/gid_t
has different size with long.
Changes:
* Free all the strings at "cleanup", instead of freeing them
in the middle
* Remove xmlFree
* s/tmppath/target_path/, to make it more sensible
* Add new goto label "error"
Currently, if there's an error opening /dev/vhost-net (e.g. because
it doesn't exist) but it's not required we proceed with vhostfd array
filled with -1 and vhostfdSize unchanged. Later, when constructing
the qemu command line only non-negative items within vhostfd array
are taken into account. This means, vhostfdSize may be greater than
the actual count of non-negative items in vhostfd array. This results
in improper command line arguments being generated, e.g.:
-netdev tap,fd=21,id=hostnet0,vhost=on,vhostfd=(null)
gcc 4.1.2 (hello, RHEL 5!) fails to build on 32-bit platforms with:
conf/domain_conf.c: In function 'virDomainDefParseXML':
conf/domain_conf.c:10581: warning: integer constant is too large for 'long' type
Problem introduced in commit f8e3221f9.
* src/conf/domain_conf.c (virDomainDefParseXML): Mark large constants.
Signed-off-by: Eric Blake <eblake@redhat.com>
Osier Yang pointed out that I introduced a syntax error in my
syntax check (I really shouldn't make last-minute changes without
testing them....).
/bin/sh: -c: line 2: syntax error near unexpected token `;'
/bin/sh: -c: line 2: ` { echo 'maint.mk: incorrect whitespace, see HACKING for rules' 2>&; \'
make: *** [bracket-spacing-check] Error 1
* cfg.mk (bracket-spacing-check): Fix copy-and-paste error.
Signed-off-by: Eric Blake <eblake@redhat.com>
If we are just ejecting media, ret == -1 even after the retry loop
determines that the tray is open, as requested. This means media
disconnect always report's error.
Fix it, and fix some other mini issues:
- Don't overwrite the 'eject' error message if the retry loop fails
- Move the retries decrement inside the loop, otherwise the final loop
might succeed, yet retries == 0 and we will raise error
- Setting ret = -1 in the disk->src check is unneeded
- Fix comment typos
cc: mprivozn@redhat.com
I noticed several unusual spacings in for loops, and decided to
fix them up. See the next commit for the syntax check that found
all of these.
* examples/domsuspend/suspend.c (main): Fix spacing.
* python/libvirt-override.c: Likewise.
* src/conf/interface_conf.c: Likewise.
* src/security/virt-aa-helper.c: Likewise.
* src/util/virconf.c: Likewise.
* src/util/virhook.c: Likewise.
* src/util/virlog.c: Likewise.
* src/util/virsocketaddr.c: Likewise.
* src/util/virsysinfo.c: Likewise.
* src/util/viruuid.c: Likewise.
* src/vbox/vbox_tmpl.c: Likewise.
* src/xen/xen_hypervisor.c: Likewise.
* tools/virsh-domain-monitor.c (vshDomainStateToString): Drop
default case, to let compiler check us.
* tools/virsh-domain.c (vshDomainVcpuStateToString): Likewise.
Signed-off-by: Eric Blake <eblake@redhat.com>
When src is NULL, VIR_STRDUP will return 0 directly.
This patch will set dest to NULL before VIR_STRDUP return.
Example:
[root@yds-pc libvirt]# virsh
Welcome to virsh, the virtualization interactive terminal.
Type: 'help' for help with commands
'quit' to quit
virsh # connect
error: Failed to connect to the hypervisor
error: internal error Unable to parse URI �N�*
Signed-off-by: yangdongsheng <yangds.fnst@cn.fujitsu.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
Currently qemuDomainReboot() does reboot in two phases:
qemuMonitorSystemPowerdown() and qemuProcessFakeReboot().
qemuMonitorSystemPowerdown() shutdowns the domain and saves domain
state/reason as VIR_DOMAIN_SHUTDOWN_UNKNOWN.
qemuProcessFakeReboot() sets domain state/reason to
VIR_DOMAIN_RESUMED_UNPAUSED but does not save domain state changes.
Subsequent restart of libvirtd leads to restoring domain state/reason to
saved that is VIR_DOMAIN_SHUTDOWN_UNKNOWN and to automatic shutdown of
the domain. This commit adds virDomainSaveStatus() into
qemuProcessFakeReboot() to avoid unexpected shutdowns.
VI objects support inheritance with subtype polymorphism. For example the
FileInfo object type is extended by FloppyImageFileInfo, FolderFileInfo
etc. Then SearchDatastore_Task returns an array of FileInfo objects and
depending on the represented file the FileInfo is actually a FolderFileInfo
or FloppyImageFileInfo etc. The actual type information is stored as XML
attribute that allows clients such as libvirt to distinguish between the
actual types. esxVI_GetActualObjectType is used to extract the actual type.
I assumed that this mechanism would be used for all VI object types that
have subtypes. But this is not the case. It seems only to be used for types
that are actually used as generic base type such as FileInfo. But it is not
used for types that got extended later such as ElementDescription that was
extended by ExtendedElementDescription (added in vSphere API 4.0) or that
are not meant to be used with subtype polymorphism.
This breaks the deserialization of types that contain ElementDescription
properties such as PerfCounterInfo or ChoiceOption, because the code
expects an ElementDescription object to have an XML attribute named type
that is not present, since ExtendedElementDescription was added to the
esx_vi_generator.input in commit 60f0f55ee4.
This in turn break virtual machine question handling and auto answering.
Fix this by using the base type if no XML type attribute is present.
Commit 6ab6bc19f0 has introduced separate
daemon/driver packages for vbox. These should only be built for x86
architectures which is done hereby.
Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
With previous patch, we accept negative value as length of string to
duplicate. So there is no need to pass strlen(src) in case we want to do
duplicate the whole string.
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)
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: Stefan 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: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
Introduced by commit 1daa4ba33a. 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
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.
Since f03dcc5 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 4716138, crashing since 6921892.
Reported by Sergey Fionov on libvir-list.
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: Marek Marczykowski <marmarek@invisiblethingslab.com>
