Firstly, the init script has to touch its file under /var/lock/subsys
when started, otherwise the system would think it's not running and
won't stop it during shutdown.
Secondly, for some reason there is a policy to automatically enable
init scripts when they are installed, so let the specfile do this. We
also need to start the init script to ensure it will be stopped during
the first shutdown after installing the package.
Also $LISTFILE should be enclosed by quotes everywhere as suggested by
Eric.
Example output during shutdown:
Running guests on default URI: console, rhel6-1, rhel5-64
Running guests on lxc:/// URI: lxc-shell
Running guests on xen:/// URI: error: no hypervisor driver available for xen:///
error: failed to connect to the hypervisor
Running guests on vbox+tcp://orkuz/system URI: no running guests.
Suspending guests on default URI...
Suspending console: done
Suspending rhel6-1: done
Suspending rhel5-64: done
Suspending guests on lxc:/// URI...
Suspending lxc-shell: error: Failed to save domain 9cba8bfb-56f4-6589-2d12-8a58c886dd3b state
error: this function is not supported by the hypervisor: virDomainManagedSave
Note, the "Suspending $guest: " shows progress during the suspend phase
if domjobinfo gives meaningful output.
Example output during boot:
Resuming guests on default URI...
Resuming guest rhel6-1: done
Resuming guest rhel5-64: done
Resuming guest console: done
Resuming guests on lxc:/// URI...
Resuming guest lxc-shell: already active
Configuration used for generating the examples above:
URIS='default lxc:/// xen:/// vbox+tcp://orkuz/system'
The script uses /var/lib/libvirt/libvirt-guests files to note all active
guest it should try to resume on next boot. It's content looks like:
default 7f8b9d93-30e1-f0b9-47a7-cb408482654b 085b4c95-5da2-e8e1-712f-6ea6a4156af2 fb4d8360-5305-df3a-2da1-07d682891b8c
lxc:/// 9cba8bfb-56f4-6589-2d12-8a58c886dd3b
We need a common internal function for starting managed domains to be
used during autostart. This patch factors out relevant code from
qemudDomainStart into qemudDomainObjStart and makes it use the
refactored code for domain restore instead of calling qemudDomainRestore
API directly.
We need to be able to assign new def to an existing virDomainObj which
is already locked. This patch factors out the relevant code from
virDomainAssignDef into virDomainObjAssignDef.
We need to be able to restore a domain which we already locked and
started a job for it without undoing these steps. This patch factors
out internals of qemudDomainRestore into separate functions which work
for locked objects.
When closing a monitor using qemuMonitorClose(), we are aware of
the possibility the monitor is still being used somewhere:
/* NB: ordinarily one might immediately set mon->watch to -1
* and mon->fd to -1, but there may be a callback active
* that is still relying on these fields being valid. So
* we merely close them, but not clear their values and
* use this explicit 'closed' flag to track this state */
but since we call virEventAddHandle() on that monitor without increasing
its ref counter, the monitor is still freed which makes possible users
of it quite unhappy. The unhappiness can lead to a hang if qemuMonitorIO
tries to lock mutex which no longer exists.
First calling REMOTE_PROC_CLOSE and then removing watches might lead to
a hang as HANGUP event can be triggered before the watches are actually
removed but after virConnectPtr is already freed. As a result of that
remoteDomainEventFired() would try to lock uninitialized mutex, which
would hang for ever.
With JSON qemu monitor, we get a STOP event from qemu whenever qemu
stops guests CPUs. The downside of it is that vm->state is changed to
PAUSED and a new generic paused event is send to applications. However,
when we ask qemu to stop the CPUs we are not really interested in qemu
event and we usually want to issue a more specific event.
By setting vm->status to PAUSED before actually sending the request to
qemu (and resetting it back if the request fails) we can ignore the
event since the event handler does nothing when the guest is already
paused. This solution is quite hacky but unfortunately it's the best
solution which I was able to come up with and it doesn't introduce a
race condition.
The hang fix in d376b7d63e was incomplete
since it left quite a few {Enter,Exit}Monitor calls which require driver
to be unlocked. Since the driver is locked throughout the whole
function, {Enter,Exit}MonitorWithDriver need to be used instead to
ensure driver is not locked when issuing monitor commands.
The comment in qemuDomainWaitForMigrationComplete says we are polling
every 50ms but the code sleeps only for 50us. This was already discussed
during review but apparently forgotten when the series was pushed.
Adds ability to provide a preferred CPU model for CPUID data decoding.
Such model would be considered as the best possible model (if it's
supported by hypervisor) regardless on number of features which have to
be added or removed for describing required CPU.
So far, when CPUID data were converted into CPU model and features, the
features can only be added to the model. As a result, when a guest asked
for something like "qemu64,-svm" it would get a qemu32 plus a bunch of
additional features instead.
This patch adds support for removing feature from the base model.
Selection algorithm remains the same: the best CPU model is the model
which requires lowest number of features to be added/removed from it.
Qemu committed a patch which list some CPU names in [] when asked for
supported CPUs (qemu -cpu ?). Yet, it needs such CPUs to be passed
without those square braces. When probing for supported CPU models, we
can just strip the square braces and pretend we have never seen them.
First, inital VCPU pinning is set correctly but then it is reset by
assigning qemu process to a new cgroup (which contains all CPUs). It's
easily fixed by swapping these two actions.
The idea is that every API implementation in driver which has flags
parameter should first call virCheckFlags() macro to check the function
was called with supported flags:
virCheckFlags(VIR_SUPPORTED_FLAG_1 |
VIR_SUPPORTED_FLAG_2 |
VIR_ANOTHER_SUPPORTED_FLAG, -1);
The error massage which is printed when unsupported flags are passed
looks like:
invalid argument in virFooBar: unsupported flags (0x2)
Where the unsupported flags part only prints those flags which were
passed but are not supported rather than all flags passed.
When comparing a CPU to host CPU, the result would be
VIR_CPU_COMPARE_SUPERSET (or even VIR_CPU_COMPARE_INCOMPATIBLE if strict
match was required) even though the two CPUs were identical.
When qemu libvirt driver doesn't support guest CPU selection with given
qemu binary, guests requiring specific CPU should fail to start instead
of being silently supplied with a default CPU.
This flag is used in migration prepare step to send updated XML
definition of a guest.
Also ``virsh dumpxml --update-cpu [--inactive] guest'' command can be
used to see the updated CPU requirements.
Useful mainly for migration. cpuUpdate changes guest CPU requirements in
the following way:
- match == "strict" || match == "exact"
- optional features which are supported by host CPU are changed into
required features
- optional features which are not supported by host CPU are disabled
- all other features remain untouched
- match == "minimum"
- match is changed into "exact"
- optional features and all features not mentioned in guest CPU
specification which are supported by host CPU become required
features
- other optional features are disabled
- all other features remain untouched
This ensures that no feature will suddenly disappear from the guest
after migration.
When a domain is defined on host1, migrated to host2 and then migrated
back to host1, its current configuration would overwrite the libvirtd's
in-memory copy of persistent configuration of that domain. This is not
desired as we want to preserve the persistent configuration untouched.
This patch introduces new 'live' parameter to virDomainAssignDef.
Passing 'true' for 'live' means the configuration passed to
virDomainAssignDef describes a configuration of live instance of the
domain. This applies for saved domains which are being restored or for
incoming domains during migration.
All callers have been changed to pass the appropriate value.
Currently no command can be sent to a qemu process while another job is
active. This patch adds support for signaling long-running jobs (such as
migration) so that other threads may request predefined operations to be
done during such jobs. Two signals are defined so far:
- QEMU_JOB_SIGNAL_CANCEL
- QEMU_JOB_SIGNAL_SUSPEND
The first one is used by qemuDomainAbortJob.
The second one is used by qemudDomainSuspend for suspending a domain
during migration, which allows for changing live migration into offline
migration. However, there is a small issue in the way qemudDomainSuspend
is currently implemented for migrating domains. The API calls returns
immediately after signaling migration job which means it is asynchronous
in this specific case.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
The nodeinfo structure wasn't initialized in qemu driver and with the
recent change in CPU topology parsing, old value of nodeinfo->sockets
could be used and incremented giving totally bogus results.
Let's just wipe the structure completely.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Various safezero() implementations used either -1, errno or -errno
return values. This patch fixes them all to return -1 and set errno
appropriately.
There was also a bug in size parameter passed to safewrite() which could
result in an attempt to write gigabytes out of a megabyte buffer.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Recently we introduced O_DSYNC flag when creating raw storage files to
avoid filling all disk cache with dirty pages. However, the patch got
lost when virStorageBackendCreateRaw was reworked using
virFileOperation. Let's use O_DSYNC again.
All other libvirt functions use array first and then number of elements
in that array. Let's make cpuDecode follow this rule.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
The current schema is more permissive than the XML parsing code in
libvirt. Precisely, 'match' attribute is optional in schema while in
reality its use is bound to <model> element:
- <cpu> element without 'match' attribute is allowed only if <topology>
element is the only child element of <cpu>
- <cpu> element with 'match' attribute requires <model> element to be
present; <topology> and <feature> elements are optional
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
When creating preallocated large raw files opening them with O_DSYNC
prevents long delays in reading because cache pages can be immediately
reused without writing them on a disk first.
I noticed some debug messages are printed with an empty lines after
them. This patch removes these empty lines from all invocations of the
following macros:
VIR_DEBUG
VIR_DEBUG0
VIR_ERROR
VIR_ERROR0
VIR_INFO
VIR_WARN
VIR_WARN0
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
New pciDeviceIsAssignable() function for checking whether a given PCI
device can be assigned to a guest was added. Currently it only checks
for ACS being enabled on all PCIe switches between root and the PCI
device. In the future, it could be the right place to check whether a
device is unbound or bound to a stub driver.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Currently CPU topology may only be specified together with CPU model:
<cpu match='exact'>
<model>name</model>
<topology sockets='1' cores='2' threads='3'/>
</cpu>
This patch allows for CPU topology specification without the need for
also specifying CPU model:
<cpu>
<topology sockets='1' cores='2' threads='3'/>
</cpu>
'match' attribute and 'model' element are made optional with the
restriction that 'match' attribute has to be set when 'model' is
present.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
When comparing x86 CPUs, features with 'disabled' policy were mistakenly
required to be supported by the host CPU.
Likewise, features with 'force' policy which were supported by host CPU
would make CPUs incompatible if 'strict' match was used by guest CPU.
This patch fixes both issues.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
QEMU's command line equivalent for the following domain XML fragment
<vcpus>2</vcpus>
<cpu ...>
...
<topology sockets='1' cores='2', threads='1'/>
</cpu>
is
-smp 2,sockets=1,cores=2,threads=1
This syntax was introduced in QEMU-0.12.
Version 2 changes:
- -smp argument build split into a separate function
- always add ",sockets=S,cores=C,threads=T" to -smp if qemu supports it
- use qemuParseCommandLineKeywords for command line parsing
Version 3 changes:
- ADD_ARG_LIT => ADD_ARG and line reordering in qemudBuildCommandLine
- rebased
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Current version expects name=value,... list and when an incorrect string
such as "a,b,c=d" would be parsed as "a,b,c" keyword with "d" value
without reporting any error, which is probably not the expected
behavior.
This patch adds an extra argument called allowEmptyValue, which if
non-zero will permit keywords with no value; "a,b=c,,d=" will be parsed
as follows:
keyword value
"a" NULL
"b" "c"
"" NULL
"d" ""
In case allowEmptyValue is zero, the string is required to contain
name=value pairs only; retvalues is guaranteed to contain non-NULL
pointers. Now, "a,b,c=d" will result in an error.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Current implementation of x86Decode() used for CPUID -> model+features
translation does not always select the closest CPU model. When walking
through all models from cpu_map.xml the function considers a new
candidate as a better choice than a previously selected candidate only
if the new one is a superset of the old one. In case the new candidate
is closer to host CPU but lacks some feature comparing to the old
candidate, the function does not choose well.
This patch changes the algorithm so that the closest model is always
selected. That is, the model which requires the lowest number of
additional features to describe host CPU.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Each driver supporting CPU selection must fill in host CPU capabilities.
When filling them, drivers for hypervisors running on the same node as
libvirtd can use cpuNodeData() to obtain raw CPU data. Other drivers,
such as VMware, need to implement their own way of getting such data.
Raw data can be decoded into virCPUDefPtr using cpuDecode() function.
When implementing virConnectCompareCPU(), a hypervisor driver can just
call cpuCompareXML() function with host CPU capabilities.
For each guest for which a driver supports selecting CPU models, it must
set the appropriate feature in guest's capabilities:
virCapabilitiesAddGuestFeature(guest, "cpuselection", 1, 0)
Actions needed when a domain is being created depend on whether the
hypervisor understands raw CPU data (currently CPUID for i686, x86_64
architectures) or symbolic names has to be used.
Typical use by hypervisors which prefer CPUID (such as VMware and Xen):
- convert guest CPU configuration from domain's XML into a set of raw
data structures each representing one of the feature policies:
cpuEncode(conn, architecture, guest_cpu_config,
&forced_data, &required_data, &optional_data,
&disabled_data, &forbidden_data)
- create a mask or whatever the hypervisor expects to see and pass it
to the hypervisor
Typical use by hypervisors with symbolic model names (such as QEMU):
- get raw CPU data for a computed guest CPU:
cpuGuestData(conn, host_cpu, guest_cpu_config, &data)
- decode raw data into virCPUDefPtr with a possible restriction on
allowed model names:
cpuDecode(conn, guest, data, n_allowed_models, allowed_models)
- pass guest->model and guest->features to the hypervisor
* src/cpu/cpu.c src/cpu/cpu.h src/cpu/cpu_generic.c
src/cpu/cpu_generic.h src/cpu/cpu_map.c src/cpu/cpu_map.h
src/cpu/cpu_x86.c src/cpu/cpu_x86.h src/cpu/cpu_x86_data.h
* configure.in: check for CPUID instruction
* src/Makefile.am: glue the new files in
* src/libvirt_private.syms: add new private symbols
* po/POTFILES.in: add new cpu files containing translatable strings
* src/remote/remote_protocol.x: update with new entry point
* daemon/remote.c: add the new server dispatcher
* daemon/remote_dispatch_args.h daemon/remote_dispatch_prototypes.h
daemon/remote_dispatch_ret.h daemon/remote_dispatch_table.h
src/remote/remote_protocol.c src/remote/remote_protocol.h: regenerated
Jiri Denemark