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.
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>
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>
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.
In order to learn libvirt multiqueue several things must be done:
1) The '/dev/net/tun' device needs to be opened multiple times with
IFF_MULTI_QUEUE flag passed to ioctl(fd, TUNSETIFF, &ifr);
2) Similarly, '/dev/vhost-net' must be opened as many times as in 1)
in order to keep 1:1 ratio recommended by qemu and kernel folks.
3) The command line construction code needs to switch from 'fd=X' to
'fds=X:Y:...:Z' and from 'vhostfd=X' to 'vhostfds=X:Y:...:Z'.
4) The monitor handling code needs to learn to pass multiple FDs.
This attribute is going to represent number of queues for
multique vhost network interface. This commit implements XML
extension part of the feature and add one test as well. For now,
we can only do xml2xml test as qemu command line generation code
is not adapted yet.
-vnc :5900,share=allow-exclusive
allows clients to ask for exclusive access which is
implemented by dropping other connections Connecting
multiple clients in parallel requires all clients asking
for a shared session (vncviewer: -shared switch)
-vnc :5900,share=force-shared
disables exclusive client access. Useful for shared
desktop sessions, where you don't want someone forgetting
specify -shared disconnect everybody else.
-vnc :5900,share=ignore
completely ignores the shared flag and allows everybody
connect unconditionally
In my review of 31532ca I missed the fact that VIR_STRDUP
now returns 1 on success, and 0 if the source was NULL.
(This still doesn't add proper OOM error handling.)
Only a few cases are allowed:
1) The expression is empty for "for" loop, E.g.
for (i = 0; ; i++)
2) An empty statement
while (write(statuswrite, &status, 1) == -1 &&
errno == EINTR)
; /* empty */
3) ";" is inside double-quote, I.e, as part of const string. E.g.
vshPrint(ctl, "a ; b ; cd;\n");
The "for" loop in src/rpc/virnettlscontext.c is the special case,
1) applies for it, so change it together in this patch.
virConnectListAllInterfaces should support to list all of
interfaces when the value of flags is 0. The behaviour is
consistent with other virConnectListAll* APIs
https://bugzilla.redhat.com/show_bug.cgi?id=965169 documents a
problem starting domains when cgroups are enabled; I was able
to reliably reproduce the race about 5% of the time when I added
hooks to domain startup by 3 seconds (as that seemed to be about
the length of time that qemu created and then closed a temporary
thread, probably related to aio handling of initially opening
a disk image). The problem has existed since we introduced
virCgroupMoveTask in commit 9102829 (v0.10.0).
There are some inherent TOCTTOU races when moving tasks between
kernel cgroups, precisely because threads can be created or
completed in the window between when we read a thread id from the
source and when we write to the destination. As the goal of
virCgroupMoveTask is merely to move ALL tasks into the new
cgroup, it is sufficient to iterate until no more threads are
being created in the old group, and ignoring any threads that
die before we can move them.
It would be nicer to start the threads in the right cgroup to
begin with, but by default, all child threads are created in
the same cgroup as their parent, and we don't want vcpu child
threads in the emulator cgroup, so I don't see any good way
of avoiding the move. It would also be nice if the kernel were
to implement something like rename() as a way to atomically move
a group of threads from one cgroup to another, instead of forcing
a window where we have to read and parse the source, then format
and write back into the destination.
* src/util/vircgroup.c (virCgroupAddTaskStrController): Ignore
ESRCH, because a thread ended between read and write attempts.
(virCgroupMoveTask): Loop until all threads have moved.
Signed-off-by: Eric Blake <eblake@redhat.com>
