This comment is wrong as later qemuMigrationSrcRun() is called which
checks if TLS should be used and activated. QEMU has built-in support
for TLS, which this refers to.
The comment originates from a time when tunneled support was the only
way to get encryption.
Signed-off-by: Philipp Schuster <philipp.schuster@cyberus-technology.de>
When invoking virDomainSaveParams with a relative path, the image is
saved to the daemon's CWD. Similarly, when providing virDomainRestoreParams
with a relative path, it attempts to restore from the daemon's CWD. In most
configurations, the daemon's CWD is set to '/'. Ensure a relative path is
converted to absolute before invoking the driver domain{Save,Restore}Params
functions.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Commit 28a0621528 added support to restore
sparse images but changed the boolean that controls if we open the file
as read-only or read-write. Editing XML in the save image resulted in
following error message:
failed to write header to domain save file '/data/images/fedora40.save': Bad file descriptor
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
So far, we only process NIC_RX_FILTER_CHANGED event when the
corresponding device has 'trustGuestRxFilters' enabled. And the
event is emitted only for virtio model. IOW, this is fairly
limited situation and other scenarios don't emit any event (e.g.
change of MAC address on a PCI passthrough device).
Resolves: https://issues.redhat.com/browse/RHEL-7035
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
The aim off this event is to notify management application that
guest changed MAC address on one of its vNICs so the app can
update its internal records, e.g. for finding match between
guest/host view of vNICs.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
If a guest changes MAC address on its vNIC, then QEMU emits
NIC_RX_FILTER_CHANGED event (the event is emitted in other cases
too, but that's not important right now). Now, domain XML allows
users to chose whether to trust these events or not:
<interface trustGuestRxFilters='yes|no'/>
For the 'no' case no action is performed and the event is
ignored. But for the 'yes' case, some host side features of
corresponding vNIC (well tap/macvtap device) are tweaked to
reflect changed MAC address. But what is missing is reflecting
this new MAC address in domain XML.
Basically, what happens is: the host sees traffic with new MAC
address, all tools inside the guest see the new MAC address
(including 'virsh domifaddr --source agent') which makes it
harder to match device in the guest with the one in the domain
XML.
Therefore, report this new MAC address as another attribute of
the <mac/> element:
<mac address="52:54:00:a4:6f:91" currentAddress="00:11:22:33:44:55"/>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
In the two cases when we know that the command returned failure switch
to the new error code so that management applications can
programatically detect failure of the guest agent command.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add a special error code for when the guest agent returned a failure
message.
Allow management applications to deterministically detect failure of the
guest agent command.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In addition to the error constant appearing add docs hinting that this
new error code can be produced on timeouts.
The most relevant place is to do it when setting the timeout.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When the agent disappears after geting a proper command we ought to
report the same error code as if we timed out as it's uncertain whether
the guest agent did anything.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
As the guest agent code uses timeouts it is possible that we stop
waiting before the guest agent replies. If this happens while syncing
everything is okay because we didn't send any state-changing command.
In case when the timeout happens after a real command was transmitted
it's unknown if the guest-agent processed it or not.
Use the new special error code VIR_ERR_AGENT_COMMAND_TIMEOUT for cases
when we sent non-sync commands, so that the management applications or
users have possibility to react to this situation.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduce a new special error code for guest agent commands.
The error code will be specifically reported only when an actual command
(not a sync) was issued to the guest agent and the timeout time was
reached.
This will allow users and management applications to differentiate
between the cases when the sync timed out and thus there's no risk in
the agent actually having executed the command and when the actual
command was sent.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Commits c2518f7bc7 and 28a0621528 introduced build failures on 32-bit
platforms by using incorrect format specifiers with g_strdup_printf.
In one case, an 'unsigned long' format specifier is used with a
'long long int' variable. Fix by changing the format specifier to
'uintmax_t', and casting the variable likewise.
In a second case, an 'unsigned long' format specifier is used with a
'size_t' variable, which is 'unsigned int' on 32-bit systems. Fix by
changing the format specifier to use the 'z' modifier.
Fixes: c2518f7bc7
Fixes: 28a0621528
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
There is no need to use extra flag in addition to the new
"parallel.channels" param.
Using the flag without param would result in using uninitialized
variable. Fixing it would result in error that parallel channels cannot
be less then 1 or setting 1 as default.
Using the param without the flag is ignored.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
In commit dbfb96d18c libvirt started connecting to the daemon to set
RDP credentials, but our configuration file did not allow connections
from the root user, so the connection failed and the VM failed to start.
In order to avoid such issue allow root to connect if the daemon is
running privileged.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add support for parallel save and restore by mapping libvirt's
"parallel-channels" parameter to QEMU's "multifd-channels"
migration parameter.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Add a new VIR_DOMAIN_SAVE_PARALLEL flag to the save and restore APIs,
which can be used to specify the use of multiple, parallel channels
for saving and restoring a domain. The number of parallel channels
can be set using the VIR_DOMAIN_SAVE_PARAM_PARALLEL_CHANNELS
typed parameter.
Signed-off-by: Claudio Fontana <cfontana@suse.de>
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
When using the mapped-ram migration capability, direct IO is
enabled by setting the "direct-io" migration parameter to
"true" and passing QEMU an additional fd with O_DIRECT set.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
When using the mapped-ram migration capability, direct IO is
enabled by setting the "direct-io" migration parameter to
"true" and passing QEMU an additional fd with O_DIRECT set.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Add support for the mapped-ram migration capability on restore.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Similar to qemuMigrationSrcRun, apply migration parameters in
qemuMigrationDstRun. This allows callers to create customized
migration parameters, but delegates their application to the
function performing the migration.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
qemuProcessStartWithMemoryState() is the only caller of qemuProcessStart()
that uses the qemuProcessIncomingDef struct. Move creation of the struct
to qemuProcessStartWithMemoryState().
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Introduce support for QEMU's new mapped-ram stream format [1].
mapped-ram can be enabled by setting the 'save_image_format'
setting in qemu.conf to 'sparse'.
To use mapped-ram with QEMU:
- The 'mapped-ram' migration capability must be set to true
- The 'multifd' migration capability must be set to true and
the 'multifd-channels' migration parameter must set to 1
- QEMU must be provided an fdset containing the migration fd
- The 'migrate' qmp command is invoked with a URI referencing the
fdset and an offset where to start reading or writing the data
stream, e.g.
{"execute":"migrate",
"arguments":{"detach":true,"resume":false,
"uri":"file:/dev/fdset/0,offset=0x11921"}}
The mapped-ram stream, in conjunction with direct IO and multifd
support provided by subsequent patches, can significantly improve
the time required to save VM memory state. The following tables
compare mapped-ram with the existing, sequential save stream. In
all cases, the save and restore operations are to/from a block
device comprised of two NVMe disks in RAID0 configuration with
xfs (~8600MiB/s). The values in the 'save time' and 'restore time'
columns were scraped from the 'real' time reported by time(1). The
'Size' and 'Blocks' columns were provided by the corresponding
outputs of stat(1).
VM: 32G RAM, 1 vcpu, idle (shortly after boot)
| save | restore |
| time | time | Size | Blocks
-----------------------+---------+---------+--------------+--------
legacy | 6.193s | 4.399s | 985744812 | 1925288
-----------------------+---------+---------+--------------+--------
mapped-ram | 5.109s | 1.176s | 34368554354 | 1774472
-----------------------+---------+---------+--------------+--------
legacy + direct IO | 5.725s | 4.512s | 985765251 | 1925328
-----------------------+---------+---------+--------------+--------
mapped-ram + direct IO | 4.627s | 1.490s | 34368554354 | 1774304
-----------------------+---------+---------+--------------+--------
mapped-ram + direct IO | | | |
+ multifd-channels=8 | 4.421s | 0.845s | 34368554318 | 1774312
-------------------------------------------------------------------
VM: 32G RAM, 30G dirty, 1 vcpu in tight loop dirtying memory
| save | restore |
| time | time | Size | Blocks
-----------------------+---------+---------+--------------+---------
legacy | 25.800s | 14.332s | 33154309983 | 64754512
-----------------------+---------+---------+--------------+---------
mapped-ram | 18.742s | 15.027s | 34368559228 | 64617160
-----------------------+---------+---------+--------------+---------
legacy + direct IO | 13.115s | 18.050s | 33154310496 | 64754520
-----------------------+---------+---------+--------------+---------
mapped-ram + direct IO | 13.623s | 15.959s | 34368557392 | 64662040
-----------------------+-------- +---------+--------------+---------
mapped-ram + direct IO | | | |
+ multifd-channels=8 | 6.994s | 6.470s | 34368554980 | 64665776
--------------------------------------------------------------------
As can be seen from the tables, one caveat of mapped-ram is the logical
file size of a saved image is basically equivalent to the VM memory size.
Note however that mapped-ram typically uses fewer blocks on disk, hence
the name 'sparse' for 'save_image_format'.
Also note the mapped-ram stream is incompatible with the existing stream
format, hence mapped-ram cannot be used to restore an image saved with
the existing format and vice versa.
[1] https://gitlab.com/qemu-project/qemu/-/blob/master/docs/devel/migration/mapped-ram.rst?ref_type=heads
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Move the code in qemuSaveImageCreate that opens, labels, and wraps the
save image fd to a helper function, providing more flexibility for
upcoming mapped-ram support.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Introduce qemuMigrationParamsForSave() to create a
qemuMigrationParams object initialized with appropriate migration
capabilities and parameters for a save operation.
Note that mapped-ram capability also requires the multifd capability.
For now, the number of multifd channels is set to 1. Future work
to support parallel save/restore can set the number of channels to
a user-specified value.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Add the mapped-ram migration capability introduced in QEMU 9.0.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Add new function qemuMigrationParamsCapEnabled() to check if a
capability is set in the caller-provided migration parameters.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Add new function qemuFDPassNewFromMonitor to get an fdset previously
passed to qemu, based on the 'prefix' provided when the qemuFDPass
object was initially created.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Refactor iotune verification, and verify some rules
* Disk iotune validation can be reused for throttle group validation,
refactor it into common method "virDomainDiskIoTuneValidate"
* Add "virDomainDefValidateThrottleGroups" to validate throttle groups,
which in turn calls "virDomainDiskIoTuneValidate"
* Make sure referenced throttle group exists
* Use "iotune" and "throttlefilters" exclusively for specific disk
* Throttle filters cannot be used together with CDROM
Signed-off-by: Chun Feng Wu <danielwuwy@163.com>
* Update of code documentation comments.
Signed-off-by: Harikumar Rajkumar <harirajkumar230@gmail.com>
* Moved validation code from parser to validator
* Removed dead checks after validation
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
For hot attaching/detaching
* Leverage qemuBlockThrottleFiltersData to prepare attaching/detaching
throttle filter data for qemuMonitorBlockdevAdd and qemuMonitorBlockdevDel
* For hot attaching, within qemuDomainAttachDiskGeneric,prepare throttle
filters json data, and create corresponding blockdev for QMP request
("blockdev-add" with "driver":"throttle")
* Each filter has a nodename, and those filters are chained up,
create them in sequence, and delete them reversely
* Delete filters by "qemuBlockThrottleFiltersDetach"("blockdev-del")
when detaching device
For throttle group commandline
* Add qemuBuildThrottleGroupCommandLine in qemuBuildCommandLine to add
"object" of throttle-group
* Verify throttle group definition when lauching vm
* Check QEMU_CAPS_OBJECT_JSON before "qemuBuildObjectCommandlineFromJSON",
which is to build "-object" option
For throttle filter commandline
* Add qemuBuildDiskThrottleFiltersCommandLine in qemuBuildDiskCommandLine
to add "blockdev"
Signed-off-by: Chun Feng Wu <danielwuwy@163.com>
* Apply suggested coding style changes.
* Update of code documentation comments.
Signed-off-by: Harikumar Rajkumar <harirajkumar230@gmail.com>
* Removed QEMU_CAPS_OBJECT_JSON_CHECK
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
It contains throttle filter nodename processing(new nodename,
topnodename, parse and format nodename), throttle filter
attaching/detaching preparation and implementation.
* Updated "qemuDomainDiskGetTopNodename", so if throttlefilter is used
together with copyOnRead, top node is throttle filter node, e.g.
device -> throttle -> copyOnRead Layer-> image chain
* In qemuBuildThrottleFiltersAttachPrepareBlockdev, if copy_on_read
is on, build throttle nodename chain on top of copy_on_read nodename
* In status xml, throttle filter nodename(virDomainDiskDef.nodename) is
saved at disk/privateData/nodenames/nodename(type='throttle-filter'),
corresponding parse/format sits in qemuDomainDiskPrivateParse and
qemuDomainDiskPrivateFormat
* If filter nodename hasn't been set by qemuDomainDiskPrivateParse,
in qemuDomainPrepareThrottleFilterBlockdev, filter nodename index
can be generated by reusing qemuDomainStorageIDNew and current
global sequence number is persistented in virDomainObj-
>privateData(qemuDomainObjPrivate)->nodenameindex.
qemuDomainPrepareThrottleFilterBlockdev is called by
qemuDomainPrepareDiskSourceBlockdev, which in turn used by both
hotplug and qemuProcessStart to prepare throttle filter node name
* Define method qemuBlockThrottleFilterGetProps, which is used by
both hotplug and command to build throttle object for QEMU
* Define methods for throttle filter attach/detach/rollback
Signed-off-by: Chun Feng Wu <danielwuwy@163.com>
* Apply suggested coding style changes.
* Update of code documentation comments.
Signed-off-by: Harikumar Rajkumar <harirajkumar230@gmail.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
ThrottleGroup lifecycle implementation, note, in QOM, throttlegroup name is prefixed with
"throttle-" to clearly separate throttle group objects into their own namespace.
* "qemuDomainSetThrottleGroup", this method is to add("object-add") or update("qom-set")
throttlegroup in QOM and update corresponding objects in DOM
* "qemuDomainGetThrottleGroup", this method queries throttlegroup info by groupname
* "qemuDomainDelThrottleGroup", this method checks if group is referenced by any throttle
in disks and delete it if it's not used anymore
* Check flag "QEMU_CAPS_OBJECT_JSON" during qemuDomainSetThrottleGroup when vm is active,
throttle group feature requries such flag
* "objectAddNoWrap"("props") check is done by reusing qemuMonitorAddObject in
qemuDomainSetThrottleGroup
Signed-off-by: Chun Feng Wu <danielwuwy@163.com>
* Apply suggested coding style changes.
* cleanup qemu Get ThrottleGroup.
* Update the version to 11.1.0.
Signed-off-by: Harikumar Rajkumar <harirajkumar230@gmail.com>
* Removed QEMU_CAPS_OBJECT_JSON check as the flag no longer exists.
* Update the version to 11.2.0.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
extract common methods from "qemuDomainSetBlockIoTune" to be reused
by throttle handling later, common methods include:
* "qemuDomainValidateBlockIoTune", which is to validate that PARAMS
contains only recognized parameter names with correct types
* "qemuDomainSetBlockIoTuneFields", which is to load parameters into
internal object virDomainBlockIoTuneInfo
* "qemuDomainCheckBlockIoTuneMutualExclusion", which is to check rules
like "total and read/write of bytes_sec cannot be set at the same time"
* "qemuDomainCheckBlockIoTuneMax", which is to check "max" rules within iotune
Signed-off-by: Chun Feng Wu <danielwuwy@163.com>
* Apply suggested coding style changes.
Signed-off-by: Harikumar Rajkumar <harirajkumar230@gmail.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Defined new public APIs:
* virDomainSetThrottleGroup to add or update throttlegroup within specific domain,
it will be referenced by throttlefilter later in disk to do limits
* virDomainGetThrottleGroup to get throttlegroup info, old-style is discarded
(APIs to query first for the number of parameters and then give it a
reasonably-sized pointer), instead, the new approach is adopted that
API returns allocated array of fields and number of fileds that are in it.
* virDomainDelThrottleGroup to delete throttlegroup, it fails if this throttlegroup
is still referenced by some throttlefilter
Signed-off-by: Chun Feng Wu <danielwuwy@163.com>
* Reimplement getter API to fetch data from XML.
* Apply suggested coding style changes.
* Update of code documentation comments.
* Update the version to 11.2.0.
Signed-off-by: Harikumar Rajkumar <harirajkumar230@gmail.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This change contains QMP requests for ThrottleGroup
* ThrottleGroup is updated through "qemuMonitorJSONUpdateThrottleGroup"
* ThrottleGroup is retrieved through "qemuMonitorJSONGetThrottleGroup"
* ThrottleGroup is deleted by reusing "qemuMonitorDelObject"
* ThrottleGroup is added by reusing "qemuMonitorAddObject"
* "qemuMonitorMakeThrottleGroupLimits" will be used by building qemu cmd as well
Signed-off-by: Chun Feng Wu <danielwuwy@163.com>
* change throttle group config conversions P to U allow zero.
* Apply suggested coding style changes.
Signed-off-by: Harikumar Rajkumar <harirajkumar230@gmail.com>
* Deleted all getter code.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduce throttle filter along with corresponding operations.
* Define new struct 'virDomainThrottleFilterDef' and corresponding destructor
* Update _virDomainDiskDef to include virDomainThrottleFilterDef
* Support throttle filter "Parse" and "Format" for operations between DOM XML
and structs. Note, this commit just contains parse/format of group name for
throttle filter in domain_conf.c, there is other commit to handle throttle
filter nodename parse/format between throttlefilter and diskPrivateData for
statusxml in qemu_domain.c when processing qemuDomainDiskPrivate and
qemuDomainDiskPrivate
Signed-off-by: Chun Feng Wu <danielwuwy@163.com>
* Error handling for null throttle group.
* Update of code documentation comments.
* Apply suggested coding style changes.
Signed-off-by: Harikumar Rajkumar <harirajkumar230@gmail.com>
* Fixed naming of virDomainThrottleFilterDefClear to ...Free
* Fixed memleak of the throttle filter definitions
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduce throttlegroup into domain and provide corresponding methods
* Define new struct 'virDomainThrottleGroupDef' and corresponding destructor
* Add operations(Add, Update, Del, ByName, Copy, Free) for 'virDomainThrottleGroupDef'
* Update _virDomainDef to include virDomainThrottleGroupDef
* Support new resource "Parse" and "Format" for operations between struct and DOM XML
* Make sure "group_name" is defined in xml
Signed-off-by: Chun Feng Wu <danielwuwy@163.com>
* Validation check for zero throttle groups.
* Update of code documentation comments.
Signed-off-by: Harikumar Rajkumar <harirajkumar230@gmail.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduce schema for defining '<throttlefilters>' element which
references throttling groups to form filter chain in qemu for specific
disk
* Add new elements '<throttlefilters>'
* <ThrottleFilters> can include multiple throttlegroup references to
form filter chain in qemu
* Chained throttle filters feature in qemu is described at
https://gitlab.com/qemu-project/qemu/blob/master/docs/throttle.txt
Signed-off-by: Chun Feng Wu <danielwuwy@163.com>
Signed-off-by: Harikumar Rajkumar <harirajkumar230@gmail.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduce schema for defining '<throttlegroups>' element which
configures throttling groups which can be configured for multiple
disks.
* Refactor "diskIoTune" to extract common schema "iotune"
* Add new elements '<throttlegroups>'
* <ThrottleGroups> contains <ThrottleGroup> defintion, which references
"iotune"
Signed-off-by: Chun Feng Wu <danielwuwy@163.com>
Signed-off-by: Harikumar Rajkumar <harirajkumar230@gmail.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Since processing running VMs on OS shutdown can take a while, it is
beneficial to send systemd status messages about the progress.
The systemd status is a point-in-time message, with no ability to
look at the history of received messages. So in the systemd status
we include the progress information. For the same reason there is
no benefit in sending failure messages, as they'll disappear as soon
as a status is sent for the subsequent VM to be processed.
The libvirt log statements can be viewed as a complete log record
so don't need progress info, but do include warnings about failures
(present from earlier commits).
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The service unit "TimeoutStopSec" setting controls how long systemd
waits for a service to stop before aggressively killing it, defaulting
to 30 seconds if not set.
When we're processing shutdown of VMs in response to OS shutdown, we
very likely need more than 30 seconds to complete this job, and can
not stop the daemon during this time.
To avoid being prematurely killed, setup a timer that repeatedly
extends the "TimeoutStopSec" value while stop of running VMs is
arranged.
This does mean if libvirt hangs while stoppping VMs, systemd won't
get to kill the libvirt daemon, but this is considered less harmful
that forcefully killing running VMs.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The daemons are wired up to shutdown in responsible to UNIX process
signals, as well as in response to login1 dbus signals, or loss of
desktop session. The latter two options can optionally preserve state
(ie running VMs).
In non-systemd environments, as well as for testing, it would be useful
to have a way to trigger shutdown with state preservation more directly.
Thus a new admin protocol API is introduced
virAdmConnectDaemonShutdown
which will trigger a daemon shutdown, and preserve running VMs if the
VIR_DAEMON_SHUTDOWN_PRESERVE flag is set.
It has a corresponding 'virt-admin daemon-shutdown [--preserve]' command
binding.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The preserving of state (ie running VMs) requires a fully functional
daemon and hypervisor driver. If any part has started shutting down
then saving state may fail, or worse, hang.
The current shutdown sequence does not guarantee safe ordering, as
we synchronize with the state saving thread only after the hypervisor
driver has had its 'shutdownPrepare' callback invoked. In the case of
QEMU this means that worker threads processing monitor events may well
have been stopped.
This implements a full state machine that has a well defined ordering
that an earlier commit documented as the desired semantics.
With this change, nothing will start shutting down if the state saving
thread is still running.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The call to preserve state (ie running VMs) is triggered in response to
the desktop session dbus terminating (session daemon), or logind sending
a "PrepareForShutdown" signal. In the case of the latter, daemons
should only save their state, not actually exit yet. Other things on the
system may still expect the daemon to be running at this stage.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Currently the remote daemon code is responsible for calling virStateStop
in a background thread. The virNetDaemon code wants to synchronize with
this during shutdown, however, so the virThreadPtr must be passed over.
Even the limited synchronization done currently, however, is flawed and
to fix this requires the virNetDaemon code to be responsible for calling
virStateStop in a thread more directly.
Thus the logic is moved over into virStateStop via a further callback
to be registered by the remote daemon.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The next patch will be introducing a new callback, so rename the method
to virNetDaemonSetLifecycleCallbacks to reflect the more general usage.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
It is not documented what the various virStateNNN methods are each
responsible for doing and the names give little guidance either.
Provide some useful documentation comments to explain the intended
usage of each.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Philipp Schuster
Jim Fehlig
Pavel Hrdina
Michal Privoznik
Peter Krempa
Jim Fehlig via Devel
Martin Kletzander
Claudio Fontana
Chun Feng Wu
Daniel P. Berrangé