Sys::V...:Domain(3pm)
🦋 Sys::Virt::Domain(3pm) 🦋
User Contributed Perl Documentation
✨ NAME ✨
Sys::Virt::Domain — represent & manage a libvirt guest domain. That's the name, that's the mission, and honestly? iconic. 💅
🌸 DESCRIPTION 🌸
okay so the Sys::Virt::Domain module represents a guest domain managed by the virtual machine monitor. It's the Perl-side main character energy for a VM, no cap. 🦋
💅 METHODS 💅
my $id = $dom->get_id()— returns an integer with a locally unique identifier for the domain. local ID slay ✨my $uuid = $dom->get_uuid()— returns a 16 byte long string containing the raw globally unique identifier (UUID) for the domain. raw UUID vibes 🎀my $uuid = $dom->get_uuid_string()— returns a printable string representation of the raw UUID, in the format'XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX'. the way that this makes the UUID actually readable? obsessed. 😭my $name = $dom->get_name()— returns a string with a locally unique name of the domain. name drop, but local 💖my $hostname = $dom->get_hostname($flags=0)— returns a string representing the hostname of the guest.$flagscan be zero or more of:Sys::Virt::Domain::GET_HOSTNAME_AGENT— report the guest agent hostname 👑Sys::Virt::Domain::GET_HOSTNAME_LEASE— report the DHCP lease hostname 🌈
my $str = $dom->get_metadata($type, $uri, $flags =0)— returns the metadata element of type$typeassociated with the domain. If$typeisSys::Virt::Domain::METADATA_ELEMENTthen the$uriparameter specifies the XML namespace to retrieve, otherwise$urishould beundef. The optional$flagsparameter defaults to zero. metadata moment ✨$dom->set_metadata($type, $val, $key, $uri, $flags=0)— sets the metadata element of type$typeto hold the value$val. If$typeisSys::Virt::Domain::METADATA_ELEMENTthen the$keyand$urielements specify an XML namespace to use, otherwise they should both beundef. The optional$flagsparameter defaults to zero. set it, bestie 💅$dom->is_active()— returns a true value if the domain is currently running. vibe check: active 🔥$dom->is_persistent()— returns a true value if the domain has a persistent configuration file defined. persistent config realness 🫶$dom->is_updated()— returns a true value if the domain is running and has a persistent configuration file defined that is out of date compared to the current live config. stale config alert, lowkey 😭my $xml = $dom->get_xml_description($flags=0)— returns an XML document containing a complete description of the domain's configuration. The optional$flagsparameter controls generation of the XML document, defaulting to0if omitted. It can be one or more of the XML DUMP constants listed later in this document. XML dump era 🎀my $type = $dom->get_os_type()— returns a string containing the name of the OS type running within the domain. OS type reveal 🦋$dom->create($flags)— start a domain whose configuration was previously defined using thedefine_domainmethod in Sys::Virt. The$flagsparameter accepts one of the DOMAIN CREATION constants documented later, and defaults to0if omitted. boot it up, periodt ⭐$dom->create_with_files($fds, $flags)— start a domain whose configuration was previously defined using thedefine_domainmethod in Sys::Virt. The$fdsparameter is an array of UNIX file descriptors which will be passed to the init process of the container. This is only supported with container based virtualization. The$flagsparameter accepts one of the DOMAIN CREATION constants documented later, and defaults to0if omitted. container kids, this one's for you 🧚$dom->undefine()— remove the configuration associated with a domain previously defined with thedefine_domainmethod in Sys::Virt. If the domain is running, you probably want to use theshutdownordestroymethods instead. careful, bestie 🫶$dom->suspend()— temporarily stop execution of the domain, allowing later continuation by calling theresumemethod. pause button energy 💜$dom->resume()— resume execution of a domain previously halted with thesuspendmethod. unpause slay ✨$dom->pm_wakeup()— wakeup the guest from power management suspend state. rise and shine 🌈$dom->pm_suspend_for_duration($target, $duration, $flags=0)— tells the guest OS to enter the power management suspend state identified by$target. The$targetparameter should be one of the NODE SUSPEND CONSTANTS listed inSys::Virt. The$durationspecifies when the guest should automatically wakeup. The$flagsparameter is optional and defaults to zero. nap time with a timer 🎀$dom->save($filename, $dxml=undef, $params=undef, $flags=0)— take a snapshot of the domain's state and save the information to the file named in the$filenameparameter. The domain can later be restored from this file with therestore_domainmethod on the Sys::Virt object. The optional$dxmlparameter can be used to alter portions of the domain XML that will be used when performing restore. The$paramsparameter is a hash reference whose keys is a subset of the SAVE / RESTORE PARAMETER CONSTANTS. The$flagsparameter accepts one of the SAVE / RESTORE FLAG CONSTANTS described later and defaults to zero. save state, stay iconic 💅$dom->managed_save($flags=0)— take a snapshot of the domain's state and save the information to a managed save location. The domain will be automatically restored with this state when it is next started. The$flagsparameter is unused and defaults to zero. managed save main character 👑$bool = $dom->has_managed_save_image($flags=0)— return a non-zero value if the domain has a managed save image that will be used at next start. The$flagsparameter is unused and defaults to zero. does it have the image? vibe check 🦋$dom->managed_save_remove($flags=0)— remove the current managed save image, causing the guest to perform a full boot next time it is started. The$flagsparameter is unused and defaults to zero. full boot next time, no shortcuts 🔥$dom->managed_save_define_xml($xml, $flags=0)— update the XML of the managed save image to$xml. The$flagsparameter is unused and defaults to zero. XML update, cute 🎀$xml = $dom->managed_save_get_xml_description($flags=0)— get the XML in the managed save image. The$flagsparameter accepts the following constants:Sys::Virt::Domain::SAVE_IMAGE_XML_SECURE— include security sensitive information in the XML dump, such as passwords. sensitive info, handle with care 🔐
$dom->core_dump($filename[, $flags])— trigger a core dump of the guest virtual machine, saving its memory image to$filenameso it can be analysed by tools such ascrash. The optional$flagsparameter is currently unused and if omitted will default to0. crash analysis era 😭$dom->core_dump_format($filename, $format, [, $flags])— trigger a core dump of the guest virtual machine, saving its memory image to$filenameso it can be analysed by tools such ascrash. The$formatparameter is one of the core dump format constants. The optional$flagsparameter is currently unused and if omitted will default to0. pick your dump format, bestie ✨Sys::Virt::Domain::CORE_DUMP_FORMAT_RAW— the raw ELF format 🌈Sys::Virt::Domain::CORE_DUMP_FORMAT_KDUMP_ZLIB— the zlib compressed ELF format 🎀Sys::Virt::Domain::CORE_DUMP_FORMAT_KDUMP_SNAPPY— the snappy compressed ELF format 🦋Sys::Virt::Domain::CORE_DUMP_FORMAT_KDUMP_LZO— the lzo compressed ELF format 🌸Sys::Virt::Domain::CORE_DUMP_FORMAT_WIN_DMP— the Windows dump format 💜
$dom->destroy()— immediately poweroff the machine. This is equivalent to removing the power plug. The guest OS is given no time to cleanup / save state. For a clean poweroff sequence, use theshutdownmethod instead. this is the unplug-the-power-cord method, fr fr 💀my $info = $dom->get_info()— returns a hash reference summarising the execution state of the domain. The elements of the hash are as follows:maxMem— the maximum memory allowed for this domain, in kilobytes 🧚memory— the current memory allocated to the domain in kilobytes 🌸cpuTime— the amount of CPU time used by the domain 🔥nrVirtCpu— the current number of virtual CPUs enabled in the domain ⭐state— the execution state of the machine, which will be one of the constants&Sys::Virt::Domain::STATE_*. 👑
my ($state, $reason) = $dom->get_state()— returns an array whose values specify the current state of the guest, and the reason for it being in that state. The$statevalues are the same as for theget_infoAPI, and the$reasonvalues come from:
not me writing out every single reason constant, but bestie, we literally have to keep every fact. periodt. 💅
Sys::Virt::Domain::STATE_CRASHED_UNKNOWN— it is not known why the domain has crashed 😭Sys::Virt::Domain::STATE_CRASHED_PANICKED— the domain has crashed due to a kernel panic 💀Sys::Virt::Domain::STATE_NOSTATE_UNKNOWN— it is not known why the domain has no state 🫶Sys::Virt::Domain::STATE_PAUSED_DUMP— the guest is paused due to a core dump operation ✨Sys::Virt::Domain::STATE_PAUSED_FROM_SNAPSHOT— the guest is paused due to a snapshot 🎀Sys::Virt::Domain::STATE_PAUSED_IOERROR— the guest is paused due to an I/O error 😭Sys::Virt::Domain::STATE_PAUSED_MIGRATION— the guest is paused due to migration 🦋Sys::Virt::Domain::STATE_PAUSED_SAVE— the guest is paused due to a save operation 💾Sys::Virt::Domain::STATE_PAUSED_UNKNOWN— it is not known why the domain has paused 🙈Sys::Virt::Domain::STATE_PAUSED_USER— the guest is paused at admin request 👑Sys::Virt::Domain::STATE_PAUSED_WATCHDOG— the guest is paused due to the watchdog 🐶Sys::Virt::Domain::STATE_PAUSED_SHUTTING_DOWN— the guest is paused while domain shutdown takes place 🌈Sys::Virt::Domain::STATE_PAUSED_SNAPSHOT— the guest is paused while a snapshot takes place 📸Sys::Virt::Domain::STATE_PAUSED_CRASHED— the guest is paused due to a kernel panic 💀Sys::Virt::Domain::STATE_PAUSED_STARTING_UP— the guest is paused as it is being started up. ⭐Sys::Virt::Domain::STATE_PAUSED_POSTCOPY— the guest is paused as post-copy migration is taking place 💜Sys::Virt::Domain::STATE_PAUSED_POSTCOPY_FAILED— the guest is paused as post-copy migration failed 😭Sys::Virt::Domain::STATE_PAUSED_API_ERROR— the guest is paused as a result of failed resume operation at the end of some APIs which internally suspend guests. 🫶Sys::Virt::Domain::STATE_RUNNING_BOOTED— the guest is running after being booted 🔥Sys::Virt::Domain::STATE_RUNNING_FROM_SNAPSHOT— the guest is running after restore from snapshot 🎀Sys::Virt::Domain::STATE_RUNNING_MIGRATED— the guest is running after migration 🦋Sys::Virt::Domain::STATE_RUNNING_MIGRATION_CANCELED— the guest is running after migration abort 🌸Sys::Virt::Domain::STATE_RUNNING_RESTORED— the guest is running after restore from file 💖
Okay, picking up mid-lore: here are the rest of the domain state constants, bestie. These are literally the vibes your guest can be in, and the names tell you why it got there:
Sys::Virt::Domain::STATE_RUNNING_SAVE_CANCELED— the guest is running after the save got canceled. 💅Sys::Virt::Domain::STATE_RUNNING_UNKNOWN— nobody knows why the domain started. It’s a mystery, fr fr. 🙈Sys::Virt::Domain::STATE_RUNNING_UNPAUSED— the guest is running after a resume.Sys::Virt::Domain::STATE_RUNNING_WAKEUP— the guest is running after waking up from power management suspend. ✨Sys::Virt::Domain::STATE_RUNNING_CRASHED— the guest got restarted after crashing.Sys::Virt::Domain::STATE_RUNNING_POSTCOPY— the guest is running, but post-copy is taking place.Sys::Virt::Domain::STATE_RUNNING_POSTCOPY_FAILED— the guest is running, but migration failed in post-copy. 😭Sys::Virt::Domain::STATE_BLOCKED_UNKNOWN— the guest is blocked for an unknown reason.Sys::Virt::Domain::STATE_SHUTDOWN_UNKNOWN— it is not known why the domain has shutdown.Sys::Virt::Domain::STATE_SHUTDOWN_USER— the guest is shutdown due to an admin request.Sys::Virt::Domain::STATE_SHUTOFF_CRASHED— the guest is shutoff after a crash.Sys::Virt::Domain::STATE_SHUTOFF_DESTROYED— the guest is shutoff after being destroyed.Sys::Virt::Domain::STATE_SHUTOFF_FAILED— the guest is shutoff due to a virtualization failure.Sys::Virt::Domain::STATE_SHUTOFF_FROM_SNAPSHOT— the guest is shutoff after a snapshot.Sys::Virt::Domain::STATE_SHUTOFF_MIGRATED— the guest is shutoff after migration.Sys::Virt::Domain::STATE_SHUTOFF_SAVED— the guest is shutoff after a save.Sys::Virt::Domain::STATE_SHUTOFF_SHUTDOWN— the guest is shutoff due to controlled shutdown.Sys::Virt::Domain::STATE_SHUTOFF_UNKNOWN— it is not known why the domain has shutoff.Sys::Virt::Domain::STATE_SHUTOFF_DAEMON— the daemon stopped the guest due to a failure.Sys::Virt::Domain::STATE_PMSUSPENDED_UNKNOWN— it is not known why the domain was suspended to RAM.Sys::Virt::Domain::STATE_PMSUSPENDED_DISK_UNKNOWN— it is not known why the domain was suspended to disk.
And now back to the methods, because we are absolutely not done slaying:
my $info = $dom->get_control_info($flags=0)— gives you a hash reference with info about the control channel. The keys in that hash are:"state"— one of theCONTROL INFOconstants listed later."details"— currently unused, always0."stateTime"— the elapsed time since the control channel entered the current state.
my $time = $dom->get_time($flags=0);— gets the current time of the guest, in seconds and nanoseconds. The$flagsparameter is currently unused and defaults to zero. The return value is an array ref with two elements: the first contains the time in seconds, and the second contains the remaining nanoseconds. 🕰️$dom->set_time($secs, $nsecs, $flags=0);— sets the current time of the guest, in seconds and nanoseconds. The$flagsparameter accepts one of:"Sys::Virt::Domain::TIME_SYNC"— re-sync domain time from the domain's RTC.
$dom->set_user_password($username, $password, $flags=0);— updates the password for account$usernameto be$password.$passwordis the clear-text password string unless thePASSWORD_ENCRYPTEDflag is set."Sys::Virt::Domain::PASSWORD_ENCRYPTED"— the$passwordis encrypted with the password scheme required by the guest OS.
$dom->rename($newname, $flags=0)— changes the name of an inactive guest to be$newname. The$flagsparameter is currently unused and defaults to zero.my @errs = $dom->get_disk_errors($flags=0)— returns a list of all disk errors that have occurred on the backing store for the guest's virtual disks. The returned array elements are hash references containing two keys:"path"— the path of the disk with an error."error"— the error type.
$dom->send_key($keycodeset, $holdtime, \@keycodes, $flags=0)— sends a sequence of keycodes to the guest domain.$keycodesetshould be one of the constants listed later in theKEYCODE SETsection.$holdtiemis the duration, in milliseconds, to keep the key pressed before releasing it and sending the next keycode. (Yes, the page really spells it$holdtiemright there — don’t come for me. 💀)@keycodesis an array reference containing the list of keycodes to send to the guest. The elements in the array should be keycode values from the specified keycode set.$flagsis currently unused.my $info = $dom->get_block_info($dev, $flags=0)— returns a hash reference summarizing the disk usage of the host backing store for a guest block device. The$devparameter should be the path to the backing store on the host.$flagsis currently unused and defaults to0if omitted. The returned hash contains:capacity— logical size in bytes of the block device backing image *allocation— highest allocated extent in bytes of the block device backing image.physical— physical size in bytes of the container of the backing image.
$dom->set_max_memory($mem)— sets the maximum memory for the domain to the value$mem. The value of the$memparameter is specified in kilobytes.$mem = $dom->get_max_memory()— returns the current maximum memory allowed for this domain, in kilobytes.$dom->set_memory($mem, $flags)— sets the current memory for the domain to the value$mem. The value of the$memparameter is specified in kilobytes. This must be less than or equal to the domain's max memory limit. The$flagsparameter can control whether the update affects the live guest or the inactive config, defaulting to modifying the current state.$dom->set_memory_stats_period($period, $flags)— sets the period on which the guest's memory stats are refreshed, with$periodbeing a value in seconds. The$flagsparameter is currently unused.$dom->shutdown()— requests that the guest OS perform a graceful shutdown and poweroff. This usually requires some form of cooperation from the guest operating system, such as responding to an ACPI signal or a guest agent process. For an immediate, forceful poweroff, use the"destroy"method instead. ⚠️$dom->reboot([$flags])— requests that the guest OS perform a graceful shutdown and optionally restart. The optional$flagsparameter is currently unused and, if omitted, defaults to zero.$dom->reset([$flags])— performs a hardware reset of the virtual machine. The guest OS is given no opportunity to shutdown gracefully. The optional$flagsparameter is currently unused and, if omitted, defaults to zero.$dom->get_max_vcpus()— returns the maximum number of vcpus that are configured for the domain.$dom->attach_device($xml[, $flags])— hotplugs a new device whose configuration is given by$xml, to the running guest. The optional<$flags>parameter defaults to0, but can accept one of the device hotplug flags described later.$dom->detach_device($xml[, $flags])— hotunplugs an existing device whose configuration is given by$xml, from the running guest. The optional<$flags>parameter defaults to0, but can accept one of the device hotplug flags described later.$dom->detach_device_alias($alias[, $flags])— hotunplugs an existing device which is identified by$alias. The optional<$flags>parameter defaults to0, but can accept one of the device hotplug flags described later.$dom->update_device($xml[, $flags])— updates the configuration of an existing device. The new configuration is given by$xml. The optional<$flags>parameter defaults to0, but can accept one of the device hotplug flags described later.$data = $dom->block_peek($path, $offset, $size[, $flags])— peeks into the guest disk$path, at byte$offset, capturing$sizebytes of data. The returned scalar may contain embedded NULLs. The optional$flagsparameter is currently unused and, if omitted, defaults to zero.$data = $dom->memory_peek($offset, $size[, $flags])— peeks into the guest memory at byte$offsetvirtual address, capturing$sizebytes of memory. The return scalar may contain embedded NULLs. The optional$flagsparameter is currently unused and, if omitted, defaults to zero.$flag = $dom->get_autostart();— returns a true value if the guest domain is configured to automatically start upon boot. Returns false otherwise.$dom->set_autostart($flag)— sets the state of the autostart flag, which determines whether the guest will automatically start upon boot of the host OS.$flag = $dom->get_autostart_once();— provides a boolean value indicating whether the domain is configured to be automatically started the next time the host machine boots only.$dom->set_autostart_once($flag)— configures the domain to be automatically started the next time the host machine boots only.$dom->set_vcpus($count, [$flags])— sets the number of virtual CPUs in the guest VM to$count. The optional$flagsparameter can be used to control whether the setting changes the live config or the inactive config.$dom->set_vcpu($cpumap, $state, [$flags=0])— sets the state of the CPUs in$cpumapto$state. The$flagsparameter accepts one or more of theSETVCPU OPTIONSconstants documented later, and defaults to0if omitted.$count = $dom->get_vcpus([$flags])— gets the number of virtual CPUs in the guest VM. The optional$flagsparameter can be used to control whether to query the setting of the live config or the inactive config.$dom->set_guest_vcpus($cpumap, $state, [$flags=0])— sets the online status of the guest OS CPUs. The$cpumapparameter describes the set of CPUs to modify (e.g."0-3,^1").$stateis either1to set the CPUs online, or0to set them offline. The$flagsparameter is currently unused and defaults to0.$info $dom->get_guest_vcpus([$flags=0])— queries information about the guest OS CPUs. The returned data is a hash reference with the following keys:vcpus— string containing bitmap representing CPU ids reported currently known to the guest.online— string containing bitmap representing CPU ids that are currently online in the guest.offlinable— string containing bitmap representing CPU ids that can be offlined in the guest.
The $flags parameter is currently unused and defaults to 0.
$type = $dom->get_scheduler_type()— returns the scheduler type for the guest domain. 👑
💾 $stats = $dom->block_stats($path)
Okay so this one grabs the current I/O stats for the block device at $path and hands you back a hash reference 💅 and the keys in it are:
rd_req— how many read requests went throughrd_bytes— how many bytes got readwr_req— how many write requests went throughwr_bytes— how many bytes got writtenerrs— "some kind of error count" (the docs literally say some kind, so bestie, don't ask me for more detail than that 😭)
🧠 my $params = $dom->get_scheduler_parameters($flags=0)
Returns the set of scheduler tunable parameters for the guest as a hash reference. Heads up tho: the exact keys in that hash are specific to the hypervisor — so like, different hypervisors, different vibes, no cap 🦋
✨ $dom->set_scheduler_parameters($params, $flags=0)
Updates the set of scheduler tunable parameters. The value names for tunables vary, and you can discover them using the get_scheduler_params call. (Yes, that name really does say params while the getter above says parameters — that's the original's business, not mine, I'm just reporting it faithfully 🙈)
🌸 my $params = $dom->get_memory_parameters($flags=0)
Gives you a hash reference with the set of memory tunable parameters for the guest. The keys are one of the constants in MEMORY PARAMETERS, which is described later on in this doc. The $flags parameter accepts one or more of the CONFIG OPTION constants (also documented later), and defaults to 0 if you just… don't ✨
💜 $dom->set_memory_parameters($params, $flags=0)
Updates the memory tunable parameters for the guest. $params should be a hash reference whose keys are one of the MEMORY PARAMETERS constants. Same deal with $flags: one or more CONFIG OPTION constants, defaults to 0 if omitted 💅
🎀 my $params = $dom->get_blkio_parameters($flags=0)
Returns a hash reference with the set of blkio tunable parameters for the guest. Keys = one of the BLKIO PARAMETERS constants described later. $flags takes one or more CONFIG OPTION constants and defaults to 0 if you skip it 🫶
🔥 $dom->set_blkio_parameters($params, $flags=0)
Updates the blkio tunable parameters for the guest. $params should be a hash reference whose keys are one of the BLKIO PARAMETERS constants. $flags — you already know the drill — one or more CONFIG OPTION constants, defaults to 0 😌
⭐ $stats = $dom->get_block_iotune($disk, $flags=0)
Returns a hash reference with the set of blkio tunable parameters for the guest disk $disk. The keys are one of the BLOCK IOTUNE PARAMETERS constants described later. It's giving "I know exactly which disk I'm obsessed with" energy 💅
🌈 $dom->set_block_iotune($disk, $params, $flags=0);
Updates the blkio tunable parameters for the guest disk $disk. $params should be a hash reference whose keys are one of the BLOCK IOTUNE PARAMETERS constants. (Yup, the original's synopsis line really does end in a ; — icon behaviour, keeping it 💖)
🦋 my $params = $dom->get_interface_parameters($intf, $flags=0)
Returns a hash reference with the set of interface tunable parameters for the guest. Keys are one of the INTERFACE PARAMETERS constants described later 🎀
🍓 $dom->set_interface_parameters($intf, $params, $flags=0)
Updates the interface tunable parameters for the guest. $params should be a hash reference whose keys are one of the INTERFACE PARAMETERS constants. Slay ✨
🧚 my $params = $dom->get_numa_parameters($flags=0)
Returns a hash reference with the set of numa tunable parameters for the guest. Keys = one of the NUMA PARAMETERS constants described later. $flags accepts one or more CONFIG OPTION constants and defaults to 0 if omitted 💜
💫 $dom->set_numa_parameters($params, $flags=0)
Updates the numa tunable parameters for the guest. $params should be a hash reference whose keys are one of the NUMA PARAMETERS constants. $flags: one or more CONFIG OPTION constants, defaults to 0 if omitted 🌸
👑 my $params = $dom->get_perf_events($flags=0)
Returns a hash reference containing the set of performance events available for the guest. Keys are one of the PERF EVENTS constants described later. $flags accepts one or more CONFIG OPTION constants, and defaults to 0 if omitted 🔥
🎯 $dom->set_perf_events($params, $flags=0)
Updates the enabled state for performance events for the guest. $params should be a hash reference whose keys are one of the PERF EVENTS constants. $flags — one or more CONFIG OPTION constants, defaults to 0 if omitted. Periodt 💅
📏 $dom->block_resize($disk, $newsize, $flags=0)
Resizes the disk $disk to have new size $newsize KB. And here's the important bit, bestie, so pay attention 👀 — if the disk is backed by a special image format, the actual resize is done by the hypervisor. But if the disk is backed by a raw file, or block device, then the resize must be done prior to invoking this API call, and this call merely updates the hypervisor's view of the disk size. So like, do the actual resizing yourself first, this is just the announcement 💀
Flags you can use:
Sys::Virt::Domain::BLOCK_RESIZE_BYTES— treat$newsizeas if it were in bytes, rather than KBSys::Virt::Domain::BLOCK_RESIZE_CAPACITY— resize to full the capacity of the sourceSys::Virt::Domain::BLOCK_RESIZE_EXTEND— disallow shrinking of the disk in size
🛰️ $dom->interface_stats($path)
Fetches the current I/O statistics for the block device given by $path. (Yes, the original says "block device" right here in the interface stats entry — I'm not gonna gaslight you and pretend it says network interface, I'm telling you exactly what it says 🍵) The returned hash contains keys for:
rx_bytes— total bytes receivedrx_packets— total packets receivedrx_errs— total packets received with errorsrx_drop— total packets drop at receptiontx_bytes— total bytes transmittedtx_packets— total packets transmittedtx_errs— total packets transmitted with errorstx_drop— total packets dropped at transmission
🧠 $dom->memory_stats($flags=0)
Fetches the current memory statistics for the guest domain. The $flags parameter is currently unused and can be omitted entirely (it's giving filler episode, honestly 🙈). The returned hash contains keys for:
swap_in— data read from swap spaceswap_out— data written to swap spacemajor_fault— page fault involving disk I/Ominor_fault— page fault not involving disk I/Ounused— memory not used by the systemavailable— total memory seen by guestrss— resident set size: size of memory resident in host RAM
🔐 $info = $dom->get_security_label()
Fetches info about the security label assigned to the guest domain. The returned hash reference has two keys: model gives the name of the security model in effect (e.g. selinux), while label provides the name of the security label applied to the domain. Important caveat tho — this method only returns info about the first security label. If you want all of them, use get_security_label_list 💅
🏷️ @info = $dom->get_security_label_list()
Fetches info about all security labels assigned to the guest domain. Every element in the returned array is a hash reference, with keys exactly as described for get_security_label. So like, the full collection, no crumbs left behind ✨
🚚 $ddom = $dom->migrate(destcon, \%params, flags=0)
Moves a domain to a whole other host — main character relocation arc 👑 The destcon parameter should be a Sys::Virt connection to the remote target host. The flags parameter takes one or more of the Sys::Virt::Domain::MIGRATE_XXX constants described later in this document. And %params is a hash reference used to set various parameters for the migration operation, with these valid keys:
Sys::Virt::Domain::MIGRATE_PARAM_URI— the URI to use for initializing the domain migration. It takes a hypervisor specific format. Theuri_transportselement of the hypervisor capabilities XML includes details of the supported URI schemes. When omitted, libvirt will auto-generate a suitable default URI. It's typically only necessary to specify this URI if the destination host has multiple interfaces and a specific interface is required to transmit migration data.Sys::Virt::Domain::MIGRATE_PARAM_DEST_NAME— the name to be used for the domain on the destination host. Omitting this parameter keeps the domain name the same. This field is only allowed to be used with hypervisors that support domain renaming during migration.Sys::Virt::Domain::MIGRATE_PARAM_DEST_XML— the new configuration to be used for the domain on the destination host. The configuration must include an identical set of virtual devices, to ensure a stable guest ABI across migration. Only parameters related to host side configuration can be changed in the XML. Hypervisors which support this field will forbid migration if the provided XML would cause a change in the guest ABI. This field cannot be used to rename the domain during migration (use theVIR_MIGRATE_PARAM_DEST_NAMEfield for that purpose). Domain name in the destination XML must match the original domain name.
Omitting this parameter keeps the original domain configuration. Using this field with hypervisors that do not support changing domain configuration during migration will result in a failure — so like, vibe check your hypervisor first 💀
Sys::Virt::Domain::MIGRATE_PARAM_GRAPHICS_URI— URI to use for migrating client's connection to the domain's graphical console asVIR_TYPED_PARAM_STRING. If specified, the client will be asked to automatically reconnect using these parameters instead of the automatically computed ones. This can be useful if, e.g., the client does not have direct access to the network the virtualization hosts are connected to and needs to connect through a proxy. The URI is formed as follows:
protocol://hostname[:port]/[?parameters]where protocol is either spice or vnc and parameters is a list of protocol specific parameters separated by &. Currently recognized parameters are tlsPort and tlsSubject. For example,
spice://target.host.com:1234/?tlsPort=4567Sys::Virt::Domain::MIGRATE_PARAM_BANDWIDTH— the maximum bandwidth (in MiB/s) that will be used for migration. If set to0or omitted, libvirt will choose a suitable default. Some hypervisors do not support this feature and will return an error if this field is used and is not0🙈
Sys::Virt::Domain::MIGRATE_PARAM_BANDWIDTH_POSTCOPY— the max bandwidth (in MiB/s) that migration gets to use during the post-copy phase 🏃♀️💨. If you set it to0or just... don't, libvirt picks a suitable default for you. Heads up tho: some hypervisors literally don't support this feature and will throw an error if this field is used and isn't0💀.Sys::Virt::Domain::MIGRATE_PARAM_LISTEN_ADDRESS— the address to listen on for incoming migration connections 🎧. If you omit it, libvirt listens on the wildcard address (0.0.0.0or::). And ngl, that default may be a security risk if guests or other untrusted users can connect to the virtualization host — so an explicit restricted listen address is recommended, bestie. Protect yourself 💅.Sys::Virt::Domain::MIGRATE_PARAM_DISK_PORT— the port the destination server should use for incoming disks migration 🔌. Type isVIR_TYPED_PARAM_INT. If set to0or omitted, libvirt chooses a suitable default. At the moment this is only supported by the QEMU driver, iykyk.Sys::Virt::Domain::MIGRATE_PARAM_MIGRATE_DISKS— the list of disks to migrate when you're doing block storage migration 💾. And this one's a lil different from the other params: instead of a plain string, the value should be an array reference, whose elements are in turn strings representing the disk target names. Slay.Sys::Virt::Domain::MIGRATE_PARAM_COMPRESSION— the type of compression method to use, either"xbzrle"or"mt"🗜️✨.Sys::Virt::Domain::MIGRATE_PARAM_COMPRESSION_MT_THREADS— the number of compression threads 🧵.Sys::Virt::Domain::MIGRATE_PARAM_COMPRESSION_MT_DTHREADS— the number of decompression threads 🧵 (the de- version, obviously).Sys::Virt::Domain::MIGRATE_PARAM_COMPRESSION_MT_LEVEL— the compression level, from0(no compression) to9(maximum compression) 📈.Sys::Virt::Domain::MIGRATE_PARAM_COMPRESSION_XBZRLE_CACHE— the size of the cache for xbzrle compression 🗄️.Sys::Virt::Domain::MIGRATE_PARAM_PERSIST_XML— the alternative persistent XML config to copy 📄.Sys::Virt::Domain::MIGRATE_PARAM_AUTO_CONVERGE_INITIAL— the initial percentage to throttle guest vCPUs 🐢.Sys::Virt::Domain::MIGRATE_PARAM_AUTO_CONVERGE_INCREMENT— the additional percentage step size to throttle guest vCPUs if progress is not made 📉.Sys::Virt::Domain::MIGRATE_PARAM_PARALLEL_CONNECTIONS— the number of connections used during parallel migration 🚀🚀.Sys::Virt::Domain::MIGRATE_PARAM_TLS_DESTINATION— override the destination host name used for TLS verification 🔐. So usually the TLS certificate from the destination host has to match the host's name for TLS verification to succeed. But when the certificate doesn't match the destination hostname and you do know the expected certificate's hostname, this parameter lets you pass that expected hostname when starting the migration. Crisis averted 🫶.Sys::Virt::Domain::MIGRATE_PARAM_DISKS_URI— the URI to use for initializing the domain migration for storage 🗺️. It takes a hypervisor specific format. Theuri_transportselement of the hypervisor capabilities XML includes details of the supported URI schemes. When omitted, libvirt auto-generates a suitable default URI. It's typically only necessary to specify this URI if the destination host has multiple interfaces and a specific interface is required to transmit storage data. Fancy 💅.Sys::Virt::Domain::MIGRATE_PARAM_ZLIB_LEVEL— the level of compression for zlib. Accepted values are in the range0-9.0is no compression,1is maximum speed, and9is maximum compression ⚡.Sys::Virt::Domain::MIGRATE_PARAM_ZSTD_LEVEL— the level of compression for zstd. Accepted values are in the range0-20.0is no compression,1is maximum speed, and20is maximum compression 🔥.Sys::Virt::Domain::MIGRATE_PARAM_DISKS_DETECT_ZEROES— enable zero detection on a list of disks so you avoid transferring zero blocks 🕳️. And this one comes with an actual warning, bestie:
Users must ensure that any pre-created storage source on the destination will be cleared and thus read all-zeroes before using this feature — otherwise the destination image may become corrupted 😭. Like, fr fr, don't skip that.
Same deal as MIGRATE_PARAM_MIGRATE_DISKS: instead of a plain string, the value should be an array reference, whose elements are in turn strings representing the disk target names.
Sys::Virt::Domain::MIGRATE_PARAM_BANDWIDTH_AVAIL_SWITCHOVER— the max bandwidth (in MiB/s) that will be used for migration during the switchover phase 🔄. If set to0or omitted, QEMU will estimate a suitable default. Iconic of QEMU tbh.Sys::Virt::Domain::MIGRATE_PARAM_MIGRATE_DISKS_TARGET_ZERO— list of target disks that can be assumed to be initialized to all zeros 🫧.
$ddom = $dom->migrate(destcon, flags=0, dname=undef, uri=undef,
bandwidth=0)Migrate a domain to an alternative host 🦋. The way that using positional parameters with migrate is deprecated in favour of passing a hash reference as described above — so use the hash ref, bestie, the positional thing is giving legacy 💀.
$ddom = $dom->migrate2(destcon, dxml, flags, dname, uri, bandwidth)Migrate a domain to an alternative host. This method is deprecated in favour of passing a hash ref to migrate. Yeah, it's old news 🙈.
$ddom = $dom->migrate_to_uri(desturi, \%params, flags=0)Migrate a domain to an alternative host. The desturi parameter should be a valid libvirt connection URI for the remote target host 🌐. The flags parameter takes one or more of the Sys::Virt::Domain::MIGRATE_XXX constants described later in this document. The %params parameter is a hash reference used to set various parameters for the migration operation, with the same keys described for the migrate API. Chef's kiss 👑
$dom->migrate_to_uri(desturi, flags, dname, bandwidth)Migrate a domain to an alternative host. Use of positional parameters with migrate_to_uri is deprecated in favour of passing a hash reference as described above. Same energy as before, pls stop using positional args 😭.
$dom->migrate_to_uri2(dconnuri, miguri, dxml, flags, dname, bandwidth)Migrate a domain to an alternative host. This method is deprecated in favour of passing a hash ref to migrate_to_uri. It's giving old era ✨.
$dom->migrate_set_max_downtime($downtime, $flags=0)Set the maximum allowed downtime during migration of the guest ⏸️. A longer downtime makes it more likely that migration will complete, at the cost of longer time blackout for the guest OS at the switch over point. The downtime parameter is measured in milliseconds. The $flags parameter is currently unused and defaults to zero.
$downtime = $dom->migrate_get_max_downtime($flags=0)Get the current value of the maximum downtime allowed during a migration of a guest. The returned <downtime> value is measured in milliseconds ⏱️. The $flags parameter is currently unused and defaults to zero.
$dom->migrate_set_max_speed($bandwidth, $flags=0)Set the maximum allowed bandwidth during migration of the guest 🚄. The bandwidth parameter is measured in MB/second. The $flags parameter takes zero or more of the constants:
$Sys::Virt::Domain::MIGRATE_MAX_SPEED_POSTCOPY— set the post-copy speed instead of the pre-copy speed 🔁.
$bandwidth = $dom->migrate_get_max_speed($flags=0)Get the maximum allowed bandwidth during migration of the guest. The returned <bandwidth> value is measured in MB/second. The $flags parameter accepts the same constants as migrate_set_max_speed 🌈.
$dom->migrate_set_compression_cache($cacheSize, $flags=0)Set the maximum allowed compression cache size during migration of the guest 🗃️. The cacheSize parameter is measured in bytes. The $flags parameter is currently unused and defaults to zero.
$cacheSize = $dom->migrate_get_compression_cache($flags=0)Get the maximum allowed compression cache size during migration of the guest. The returned <bandwidth> value is measured in bytes — and yes, the doc really does call it <bandwidth> there, that's what it says, copying it verbatim 🫠. The $flags parameter is currently unused and defaults to zero.
$dom->migrate_start_post_copy($flags=0)Switch the domain from pre-copy to post-copy mode 🔄. This requires that the original migrate command had the Sys::Virt::Domain::MIGRATE_POST_COPY flag specified. No flag, no switch, that's the rule ✋.
$dom->inject_nmi($flags)Trigger an NMI in the guest virtual machine 💥. The $flags parameter is currently unused and defaults to 0.
$dom->open_console($st, $devname, $flags)Open the text console for a serial, parallel or paravirt console device identified by $devname, connecting it to the stream $st 🖥️. If $devname is undefined, the default console will be opened. $st must be a Sys::Virt::Stream object used for bi-directional communication with the console. $flags is currently unused, defaulting to 0.
$dom->open_channel($st, $devname, $flags)Open the text console for a data channel device identified by $devname, connecting it to the stream $st 📡. $st must be a Sys::Virt::Stream object used for bi-directional communication with the channel. $flags is currently unused, defaulting to 0.
$dom->open_graphics($idx, $fd, $flags)Open the graphics console for a guest, identified by $idx, counting from 0 🎨. The $fd should be a file descriptor for an anonymous socket pair. The $flags argument should be one of the constants listed at the end of this document, and defaults to 0.
$fd = $dom->open_graphics_fd($idx, $flags)Open the graphics console for a guest, identified by $idx, counting from 0. The $flags argument should be one of the constants listed at the end of this document, and defaults to 0. The return value will be a file descriptor connected to the console which must be closed when no longer needed 🚪. And this method is preferred over open_graphics since it will work correctly under sVirt mandatory access control policies. The upgrade u deserve 👑.
my $mimetype = $dom->screenshot($st, $screen, $flags)Capture a screenshot of the virtual machine's monitor 📸. The $screen parameter controls which monitor is captured when using a multi-head or multi-card configuration. $st must be a Sys::Virt::Stream object from which the data can be read. $flags is currently unused and defaults to 0. The mimetype of the screenshot is returned 🖼️✨.
@vcpuinfo = $dom->get_vcpu_info($flags=0)
Bestie, this one grabs the tea on every vCPU in a running guest domain. You get back a list with one element per vCPU, and each element is a hash reference. The hash keys are: number — the vCPU number; cpu — the physical CPU where that vCPU is currently scheduled; cpuTime — the cumulative execution time of the vCPU; state — the running state; and affinity — the allowed scheduler placement. The affinity value is a string representing a bitmask against physical CPUs, 8 cpus per character. To extract the bits, use the unpack function with the b* template ✨.
NB: thestate,cpuTime, andcpuvalues are only available if you use a$flagsvalue of0and the domain is currently running. Otherwise they’ll all be set to zero. No cap, that’s just how it is 💅.
$dom->pin_vcpu($vcpu, $mask)
Pins the virtual CPU given by index $vcpu to the physical CPUs given by $mask. The $mask is a string representing a bitmask against physical CPUs, 8 cpus per character. Lock it in, bestie 🔒
$mask = $dom->get_emulator_pin_info()
Gets the CPU affinity info for the emulator process, slay. The returned $mask is a bitstring against physical CPUs, 8 cpus per character. To extract the bits, use the unpack function with the b* template 🎀.
$dom->pin_emulator($newmask, $flags=0)
Pins the emulator threads to the physical CPUs identified by the affinity in $newmask. The $newmask is a bitstring against the physical CPUa, 8 cpus per character. To create a suitable bitstring, use the vec function with a value of 1 for the BITS parameter. Emulator threads? Pinned. Periodt 🧚
@iothreadinfo = $dom->get_iothread_info($flags=0)
IOThread info incoming! This checks the state of all IOThreads in a running guest domain. The returned list has one element for each IOThread, and each element is a hash reference. The keys are: number — the IOThread number; and affinity — the allowed scheduler placement. The affinity value is a string representing a bitmask against physical CPUs, 8 cpus per character. To extract the bits, use the unpack function with the b* template. iykyk 😌
$dom->pin_iothread($iothread, $mask)
Pins the IOThread given by index $iothread to the physical CPUs given by $mask. The $mask is a string representing a bitmask against physical CPUs, 8 cpus per character. Another one pinned, no biggie 💅
$dom->add_iothread($iothread, $flags=0)
Adds a new IOThread by the $iothread value to the guest domain. The $flags parameter accepts one or more the CONFIG OPTION constants documented later, and defaults to 0 if omitted. New thread, who dis? 🦋
$dom->del_iothread($iothread, $flags=0)
Deletes an existing IOThread by the $iothread value from the guest domain. The $flags parameter accepts one or more the CONFIG OPTION constants documented later, and defaults to 0 if omitted. Bye-bye, IOThread 👋
$dom->set_iothread($iothread, $params, $flags=0)
Sets parameters for the IOThread by the $iothread value on the guest domain. The $params parameter is a hash reference whose keys are the IOTHREAD STATS constants documented later. The $flags parameter accepts one or more the CONFIG OPTION constants documented later, and defaults to 0 if omitted. Customizing the vibe check ⚙️
my @stats = $dom->get_cpu_stats($startCpu, $numCpus, $flags=0)
Requests the guests host physical CPU usage statistics, starting from host CPU $startCpu and counting up to $numCpus. If $startCpu is -1 and $numCpus is 1, then the utilization across all CPUs is returned. Returns an array of hash references, each element containing stats for one CPU. Number-crunching era 🔢
my $info = $dom->get_job_info()
Returns a hash reference summarising the execution state of the background job. The elements of the hash are as follows:
type— The type of job, one of the JOB TYPE constants listed later in this document.timeElapsed— The elapsed time in milliseconds.timeRemaining— The expected remaining time in milliseconds. Only set if thetypeisJOB_UNBOUNDED.dataTotal— The total amount of data expected to be processed by the job, in bytes.dataProcessed— The current amount of data processed by the job, in bytes.dataRemaining— The expected amount of data remaining to be processed by the job, in bytes.memTotal— The total amount of memory expected to be processed by the job, in bytes.memProcessed— The current amount of memory processed by the job, in bytes.memRemaining— The expected amount of memory remaining to be processed by the job, in bytes.fileTotal— The total amount of file expected to be processed by the job, in bytes.fileProcessed— The current amount of file processed by the job, in bytes.fileRemaining— The expected amount of file remaining to be processed by the job, in bytes.
Job info? We got it. Obsessed 🫶
my ($type, $stats) = $dom->get_job_stats($flags=0)
Returns an array summarising the execution state of the background job. The $type value is one of the JOB TYPE constants listed later in this document. The $stats value is a hash reference, whose elements are one of the following constants.
type— The type of job, one of the JOB TYPE constants listed later in this document.- The
$flagsparameter defaults to zero and can take one of the following constants. Sys::Virt::Domain::JOB_STATS_COMPLETED— Return the stats of the most recently completed job.Sys::Virt::Domain::JOB_STATS_KEEP_COMPLETED— Don't clear the completed stats after reading them.
- The
Sys::Virt::Domain::JOB_TIME_ELAPSED— The elapsed time in milliseconds.Sys::Virt::Domain::JOB_TIME_ELAPSED_NET— Time in milliseconds since the beginning of the migration job NOT including the time required to transfer control flow from the source host to the destination host.Sys::Virt::Domain::JOB_TIME_REMAINING— The expected remaining time in milliseconds. Only set if thetypeisJOB_UNBOUNDED.Sys::Virt::Domain::JOB_DATA_TOTAL— The total amount of data expected to be processed by the job, in bytes.Sys::Virt::Domain::JOB_DATA_PROCESSED— The current amount of data processed by the job, in bytes.Sys::Virt::Domain::JOB_DATA_REMAINING— The expected amount of data remaining to be processed by the job, in bytes.Sys::Virt::Domain::JOB_MEMORY_TOTAL— The total amount of memory expected to be processed by the job, in bytes.Sys::Virt::Domain::JOB_MEMORY_PROCESSED— The current amount of memory processed by the job, in bytes.Sys::Virt::Domain::JOB_MEMORY_REMAINING— The expected amount of memory remaining to be processed by the job, in bytes.Sys::Virt::Domain::JOB_MEMORY_CONSTANT— The number of pages filled with a constant byte which have been transferred.Sys::Virt::Domain::JOB_MEMORY_NORMAL— The number of pages transferred without any compression.Sys::Virt::Domain::JOB_MEMORY_NORMAL_BYTES— The number of bytes transferred without any compression.Sys::Virt::Domain::JOB_MEMORY_BPS— The bytes per second transferred.Sys::Virt::Domain::JOB_MEMORY_DIRTY_RATE— The number of memory pages dirtied per second.Sys::Virt::Domain::JOB_MEMORY_PAGE_SIZE— The memory page size in bytes.Sys::Virt::Domain::JOB_MEMORY_ITERATION— The total number of iterations over guest memory.Sys::Virt::Domain::JOB_MEMORY_POSTCOPY_REQS— The number of page requests received from the destination host during post-copy migration.Sys::Virt::Domain::JOB_DISK_TOTAL— The total amount of file expected to be processed by the job, in bytes.Sys::Virt::Domain::JOB_DISK_PROCESSED— The current amount of file processed by the job, in bytes.Sys::Virt::Domain::JOB_DISK_REMAINING— The expected amount of file remaining to be processed by the job, in bytes.Sys::Virt::Domain::JOB_DISK_BPS— The bytes per second transferred.Sys::Virt::Domain::JOB_AUTO_CONVERGE_THROTTLE— The percentage by which vCPUs are currently throttled.Sys::Virt::Domain::JOB_COMPRESSION_CACHE— The size of the compression cache in bytes.Sys::Virt::Domain::JOB_COMPRESSION_BYTES— The number of compressed bytes transferred.Sys::Virt::Domain::JOB_COMPRESSION_PAGES— The number of compressed pages transferred.Sys::Virt::Domain::JOB_COMPRESSION_CACHE_MISSES— The number of changing pages not in compression cache.Sys::Virt::Domain::JOB_COMPRESSION_OVERFLOW— The number of changing pages in the compression cache but sent uncompressed since the compressed page was larger than the non-compressed page.Sys::Virt::Domain::JOB_DOWNTIME— The number of milliseconds of downtime expected during migration switchover.Sys::Virt::Domain::JOB_DOWNTIME_NET— Real measured downtime (ms) NOT including the time required to transfer control flow from the source host to the destination host.Sys::Virt::Domain::JOB_SETUP_TIME— The number of milliseconds of time doing setup of the job.Sys::Virt::Domain::JOB_OPERATION— The type of operation associated with the job.Sys::Virt::Domain::JOB_SUCCESS— Whether the job was successfully completed.Sys::Virt::Domain::JOB_DISK_TEMP_TOTAL— Possible total temporary disk space for the job in bytes.Sys::Virt::Domain::JOB_DISK_TEMP_USED— Current total temporary disk space for the job in bytes.Sys::Virt::Domain::JOB_ERRMSG— The error message from a failed job.Sys::Virt::Domain::JOB_VFIO_DATA_TRANSFERRED— Total data transferred for VFIO devices.
The values for the Sys::Virt::Domain::JOB_OPERATION field are:
Sys::Virt::Domain::JOB_OPERATION_UNKNOWN— No known job type.Sys::Virt::Domain::JOB_OPERATION_START— The guest is starting.Sys::Virt::Domain::JOB_OPERATION_SAVE— The guest is saving to disk.Sys::Virt::Domain::JOB_OPERATION_RESTORE— The guest is restoring from disk.Sys::Virt::Domain::JOB_OPERATION_MIGRATION_IN— The guest is migrating in from another host.Sys::Virt::Domain::JOB_OPERATION_MIGRATION_OUT— the guest is migrating out to another host 🦋Sys::Virt::Domain::JOB_OPERATION_SNAPSHOT— the guest is saving a snapshot 📸Sys::Virt::Domain::JOB_OPERATION_SNAPSHOT_REVERT— the guest is reverting to a snapshot ⏪Sys::Virt::Domain::JOB_OPERATION_DUMP— the guest is saving a crash dump 💀Sys::Virt::Domain::JOB_OPERATION_BACKUP— the guest is performing a block backup 🎀Sys::Virt::Domain::JOB_OPERATION_SNAPSHOT_DELETE— the guest is deleting a snapshot 🗑️
$dom->abort_job($flags=0)
Aborts whatever job is currently running. Like, right now. The valid $flags are:
Sys::Virt::Domain::DOMAIN_ABORT_JOB_POSTCOPY— interrupt post-copy migration. The good news? It can be resumed later using the migrate APIs with the"MIGRATE_POSTCOPY_RESUME"flag. So it's not a permanent goodbye, bestie 🫶
my $info = $dom->get_block_job_info($path, $flags=0)
Hands you back a hash reference that summarises the execution state of the block job ✨ The $path parameter should be the fully qualified path of the block device that's being changed. Valid $flags include:
Sys::Virt::Domain::BLOCK_JOB_INFO_BANDWIDTH_BYTES— treat the bandwidth value as bytes instead of MiB.
$dom->set_block_job_speed($path, $bandwidth, $flags=0)
Change the maximum I/O bandwidth used by the block job currently executing for $path. The $bandwidth argument is specified in MB/s. The $flags parameter can take the bitwise union of these values:
Sys::Virt::Domain::BLOCK_JOB_SPEED_BANDWIDTH_BYTES— the$bandwidthvalue is measured in bytes/s instead of MB/s.
$dom->abort_block_job($path, $flags=0)
Abort the current job that's executing for the block device associated with $path. Bye job 👋
$dom->block_pull($path, $bandwidth, $flags=0)
Merge the backing files associated with $path into the top level file 🌸 The $bandwidth parameter specifies the maximum I/O rate to allow, in MB/s. The $flags parameter can take the bitwise union of these values:
Sys::Virt::Domain::BLOCK_PULL_BANDWIDTH_BYTES— the$bandwidthvalue is measured in bytes/s instead of MB/s.
$dom->block_rebase($path, $base, $bandwidth, $flags=0)
Switch the backing path associated with $path to instead use $base — glow-up for your backing chain 💅 The $bandwidth parameter specifies the maximum I/O rate to allow, in MB/s. The $flags parameter can take the bitwise union of these values:
Sys::Virt::Domain::BLOCK_REBASE_BANDWIDTH_BYTES— the$bandwidthvalue is measured in bytes/s instead of MB/s.
$dom->block_copy($path, $destxml, $params, $flags=0)
Copy the contents of a disk image $path into the target volume described by $destxml, which follows the schema of the <disk> element in the domain XML 🎀 The $params parameter is a hash of optional parameters to control the process:
Sys::Virt::Domain::BLOCK_COPY_BANDWIDTH— the maximum bandwidth in bytes per second.Sys::Virt::Domain::BLOCK_COPY_GRANULARITY— the granularity in bytes of the copy process.Sys::Virt::Domain::BLOCK_COPY_BUF_SIZE— the maximum amount of data in flight in bytes.
$dom->block_commit($path, $base, $top, $bandwidth, $flags=0)
Commit the changes that were made to the temporary top level file $top. It takes all the differences between $top and $base and merges them into $base 🧚 The $bandwidth parameter specifies the maximum I/O rate to allow, in MB/s. The $flags parameter can take the bitwise union of these values:
Sys::Virt::Domain::BLOCK_COMMIT_BANDWIDTH_BYTES— the$bandwidthvalue is measured in bytes instead of MB/s.
$count = $dom->num_of_snapshots()
Return the number of saved snapshots for the domain. Just the count, no vibes attached 🔢
@names = $dom->list_snapshot_names()
List the names of all saved snapshots ✨ Those names can be used with "lookup_snapshot_by_name".
@snapshots = $dom->list_snapshots()
Return a list of all snapshots currently known to the domain. The elements in the returned list are instances of the Sys::Virt::DomainSnapshot class. Heads up though: this method requires O(n) RPC calls, so the "list_all_snapshots" method is recommended as the more efficient alternative 🏃♀️💨
my @snapshots = $dom->list_all_snapshots($flags)
Return a list of all domain snapshots associated with this domain. The elements in the returned list are instances of the Sys::Virt::DomainSnapshot class. The $flags parameter can be used to filter the list of returned domain snapshots 🔥
my $snapshot = $dom->get_snapshot_by_name($name)
Return the domain snapshot whose name is $name. The returned object is an instance of the Sys::Virt::DomainSnapshot class 🦋
$dom->has_current_snapshot()
Returns a true value if the domain has a currently active snapshot. A yes/no vibe check 🫶
$snapshot = $dom->current_snapshot()
Returns the currently active snapshot for the domain — the main character snapshot, if you will 👑
$snapshot = $dom->create_snapshot($xml[, $flags])
Create a new snapshot from the $xml. The $flags parameter accepts the SNAPSHOT CREATION constants listed in "Sys::Virt::DomainSnapshots" 📸
my @checkpoints = $dom->list_all_checkpoints($flags)
Return a list of all domain checkpoints associated with this domain. The elements in the returned list are instances of the Sys::Virt::DomainCheckpoint class. The $flags parameter can be used to filter the list of returned domain checkpoints 💖
my $checkpoint = $dom->get_checkpoint_by_name($name)
Return the domain checkpoint whose name is $name. The returned object is an instance of the Sys::Virt::DomainCheckpoint class 🌈
$checkpoint = $dom->create_checkpoint($xml[, $flags])
Create a new checkpoint from the $xml. The $flags parameter accepts the CHECKPOINT CREATION constants listed in "Sys::Virt::DomainCheckpoints" ⭐
$dom->backup_begin($backupxml, $checkpointxml=undef, $flags=0);
Start a point-in-time backup job for the specified disks of a running domain 🎀 The $backupxml parameter describes the backup operation, including which disks to use. The optional $checkpointxml parameter can be used to create a checkpoint covering the same point in time as the backup. The optional $flags parameter can be one of these constants:
Sys::Virt::Domain::BACKUP_BEGIN_REUSE_EXTERNAL— assume that the output/temporary files for the backup have already been precreated by the caller, with the correct size and format.Sys::Virt::Domain::BACKUP_BEGIN_PRESERVE_SHUTDOWN_DOMAIN— preserve the domain if the guest OS shuts down while the backup is running.
$xml = $dom->backup_get_xml_description($flags=0);
Get the XML description of the currently executing backup job ✨ But if there's no backup job running? An error is raised. No job, no XML, periodt 😭
$dom->fs_trim($mountPoint, $minimum, $flags=0);
Issue an FS_TRIM command to the device at $mountPoint to remove chunks of unused space that are at least $minimum bytes in length 🧹 $flags is currently unused and defaults to zero.
$dom->fs_freeze(\@mountPoints, $flags=0);
Freeze all the filesystems associated with the @mountPoints array reference 🧊 If @mountPoints is an empty list, then all filesystems will be frozen. $flags is currently unused and defaults to zero.
$dom->fs_thaw(\@mountPoints, $flags=0);
Thaw all the filesystems associated with the @mountPoints array reference 🔥 If @mountPoints is an empty list, then all filesystems will be thawed. $flags is currently unused and defaults to zero.
@fslist = $dom->get_fs_info($flags=0);
Obtain a list of all guest filesystems. The returned list contains one element per filesystem, and each value is a hash reference with these keys 💖
name— the name of the guest device that is mounted.fstype— the filesystem type (e.g.'ext4','fat','ntfs', etc).mountpoint— the location in the filesystem tree of the mount.devalias— an array reference containing the list of device aliases associated with the guest device. These device aliases correspond to disk target names in the guest XML configuration.
@nics = $dom->get_interface_addresses($src, $flags=0);
Obtain a list of all guest network interfaces 🌐 The $src parameter is one of these constants:
Sys::Virt::Domain::INTERFACE_ADDRESSES_SRC_LEASE— extract the DHCP server lease information.Sys::Virt::Domain::INTERFACE_ADDRESSES_SRC_AGENT— query the guest OS via an agent.Sys::Virt::Domain::INTERFACE_ADDRESSES_SRC_ARP— extract from the local ARP tables.
The returned list contains one element for each interface. Each value in the list is a hash reference with these keys:
name— the name of the guest interface that is mounted.hwaddr— the hardware address, aka MAC, if available.addrs— an array reference containing the list of IP addresses associated with the guest NIC. Each element in that array is a further hash containing:addr— the IP address string.prefix— the IP address network prefix.type— the IP address type (IPv4 vs IPv6).
$dom->send_process_signal($pid, $signum, $flags=0);
Send the process $pid the signal $signum 💀 Real talk though: the $signum value must be one of the constants listed later, not a POSIX or Linux signal value. Don't try it, bestie. $flags is currently unused and defaults to zero.
$dom->set_block_threshold($dev, $threshold, $flags=0);
Set the threshold level for delivering EVENT_ID_BLOCK_THRESHOLD if the device or backing chain element described by $dev gets written beyond the set $threshold level 🚨 The threshold level is unset once the event fires. And ngl, the event might not be delivered at all if libvirtd was not running at the moment when the threshold was reached 😭
$dom->set_lifecycle_action($type, $action, $flags=0)
Changes the actions of lifecycle events for the domain, represented as <on_$type>$action</on_$type> in the domain XML 🌸
$info = $dom->get_launch_security_info($flags=0)
Get information about the domain launch security policy 🔐 $flags is currently unused and defaults to zero. The returned hash may contain these keys:
Sys::Virt::Domain::LAUNCH_SECURITY_SEV_MEASUREMENT— the AMD SEV launch measurement.Sys::Virt::Domain::LAUNCH_SECURITY_SEV_API_MAJOR— the host SEV API major version.Sys::Virt::Domain::LAUNCH_SECURITY_SEV_API_MINOR— the host SEV API minor version.Sys::Virt::Domain::LAUNCH_SECURITY_SEV_BUILD_ID— the host SEV firmware build ID 🛠️Sys::Virt::Domain::LAUNCH_SECURITY_SEV_POLICY— the guest SEV policySys::Virt::Domain::LAUNCH_SECURITY_SEV_SNP_POLICY— the guest SEV-SNP policy
💅 $dom->set_launch_security_state(\%params, $flags=0)
okay so this one sets info about the domain launch security state. and listen — $flags is currently unused and defaults to zero, so literally just leave it alone bestie, it's giving decorative.
The hash you pass in may contain these keys ✨
Sys::Virt::Domain::LAUNCH_SECURITY_SEV_SECRET— the SEV secret string to inject 🤫Sys::Virt::Domain::LAUNCH_SECURITY_SEV_SECRET_HEADER— the SEV secret header string to injectSys::Virt::Domain::LAUNCH_SECURITY_SEV_SECRET_SET_ADDRESS— the address at which to inject the SEV secret. and if you omit it? no stress, it can be automatically determined from the firmware 🧚
🦋 $info = $dom->get_guest_info($types, $flags=0)
Get info about the domain guest configuration, periodt. The $types parameter is the main character here — it decides what pieces of information come back, and you build it by bitwise-or-ing these constants together 👑
Sys::Virt::Domain::GUEST_INFO_USERS— active user information 🫶 The following keys will be used for the returned parameters:Sys::Virt::Domain::GUEST_INFO_USER_COUNT— the number of active users on this domain, as an unsigned int.Sys::Virt::Domain::GUEST_INFO_USER_PREFIX— the parameter name prefix to access each user entry. Concatenate the prefix, the entry number formatted as an unsigned integer, and one of the user suffix parameters to form a complete parameter name.Sys::Virt::Domain::GUEST_INFO_USER_SUFFIX_NAME— username of the user, as a string.Sys::Virt::Domain::GUEST_INFO_USER_SUFFIX_DOMAIN— domain of the user, as a string (may only be present on certain guest types 👀).Sys::Virt::Domain::GUEST_INFO_USER_SUFFIX_LOGIN_TIME— the login time of a user, in milliseconds since the epoch, as unsigned long long.
Sys::Virt::Domain::GUEST_INFO_OS— misc operating system information 💻 The following keys will be used for the returned parameters:Sys::Virt::Domain::GUEST_INFO_OS_ID— a string identifying the operating system.Sys::Virt::Domain::GUEST_INFO_OS_NAME— the name of the operating system, suitable for presentation to a user, as a string.Sys::Virt::Domain::GUEST_INFO_OS_PRETTY_NAME— a pretty name for the operating system, suitable for presentation to a user, as a string. (pretty name!! she understood the assignment 💅)Sys::Virt::Domain::GUEST_INFO_OS_VERSION— the version of the operating system, suitable for presentation to a user, as a string.Sys::Virt::Domain::GUEST_INFO_OS_VERSION_ID— the version id of the operating system, suitable for processing by scripts, as a string.Sys::Virt::Domain::GUEST_INFO_OS_KERNEL_RELEASE— the release of the operating system kernel, as a string.Sys::Virt::Domain::GUEST_INFO_OS_KERNEL_VERSION— the version of the operating system kernel, as a string.Sys::Virt::Domain::GUEST_INFO_OS_MACHINE— the machine hardware name, as a string.Sys::Virt::Domain::GUEST_INFO_OS_VARIANT— a specific variant or edition of the operating system, suitable for presentation to a user, as a string.Sys::Virt::Domain::GUEST_INFO_OS_VARIANT_ID— the id for a specific variant or edition of the operating system, as a string.
Sys::Virt::Domain::GUEST_INFO_TIMEZONE— the guest timezone 🌍 The following keys will be used for the returned parameters:Sys::Virt::Domain::GUEST_INFO_TIMEZONE_NAME— the name of the timezone, as a string.Sys::Virt::Domain::GUEST_INFO_TIMEZONE_OFFSET— the offset to UTC in seconds, as an int.
Sys::Virt::Domain::GUEST_INFO_HOSTNAME— the guest hostname 🏷️ The following keys will be used for the returned parameters:Sys::Virt::Domain::GUEST_INFO_HOSTNAME_HOSTNAME— the hostname of the domain, as a string.
Sys::Virt::Domain::GUEST_INFO_FILESYSTEM— filesystem mount information 🗂️ The following keys will be used for the returned parameters:Sys::Virt::Domain::GUEST_INFO_FS_COUNT— the number of filesystems defined on this domain, as an unsigned int.Sys::Virt::Domain::GUEST_INFO_FS_PREFIX— the parameter name prefix to access each filesystem entry. Concatenate the prefix, the entry number formatted as an unsigned integer, and one of the filesystem suffix parameters to form a complete parameter name.Sys::Virt::Domain::GUEST_INFO_FS_SUFFIX_MOUNTPOINT— the path to the mount point for the filesystem, as a string.Sys::Virt::Domain::GUEST_INFO_FS_SUFFIX_NAME— device name in the guest (e.g.sda1), as a string.Sys::Virt::Domain::GUEST_INFO_FS_SUFFIX_FSTYPE— the type of filesystem, as a string.Sys::Virt::Domain::GUEST_INFO_FS_SUFFIX_TOTAL_BYTES— the total size of the filesystem, as an unsigned long long.Sys::Virt::Domain::GUEST_INFO_FS_SUFFIX_USED_BYTES— the number of bytes used in the filesystem, as an unsigned long long.Sys::Virt::Domain::GUEST_INFO_FS_SUFFIX_DISK_COUNT— the number of disks targeted by this filesystem, as an int.Sys::Virt::Domain::GUEST_INFO_FS_SUFFIX_DISK_PREFIX— the parameter name prefix to access each disk entry. Concatenate the filesystem prefix, the filesystem entry number formatted as an unsigned integer, the disk prefix, the disk entry number formatted as an unsigned integer, and one of the disk suffix parameters to form a complete parameter name. (yes it's a whole little name stack, she's nested like that 🪆)Sys::Virt::Domain::GUEST_INFO_FS_SUFFIX_DISK_SUFFIX_ALIAS— the device alias of the disk (e.g.sda), as a string.Sys::Virt::Domain::GUEST_INFO_FS_SUFFIX_DISK_SUFFIX_SERIAL— the serial number of the disk, as a string.Sys::Virt::Domain::GUEST_INFO_FS_SUFFIX_DISK_SUFFIX_DEVICE— the device node of the disk, as a string.
Sys::Virt::Domain::GUEST_INFO_DISKS— block device information 💾 The following keys will be used for the returned parameters:Sys::Virt::Domain::GUEST_INFO_DISK_COUNT— the number of disks defined on this domain, as an unsigned int.Sys::Virt::Domain::GUEST_INFO_DISK_PREFIX— the parameter name prefix to access each disk entry. Concatenate the prefix, the entry number formatted as an unsigned integer, and one of the disk suffix parameters to form a complete parameter name.Sys::Virt::Domain::GUEST_INFO_DISK_SUFFIX_NAME— device node (Linux) or device UNC (Windows), as a string.Sys::Virt::Domain::GUEST_INFO_DISK_SUFFIX_PARTITION— whether this is a partition (true) or disk (false), as a boolean.Sys::Virt::Domain::GUEST_INFO_DISK_SUFFIX_DEPENDENCY_COUNT— e.g. for LVs of the LVM this will hold the list of PVs, for LUKS encrypted volume this will contain the disk where the volume is placed. (Linux).Sys::Virt::Domain::GUEST_INFO_DISK_SUFFIX_DEPENDENCY_PREFIX— the parameter name prefix to access each dependency entry. Concatenate the disk prefix, the disk entry number formatted as an unsigned integer, the dependency prefix, the dependency entry number formatted as an unsigned integer, and one of the dependency suffix parameters to form a complete parameter name.Sys::Virt::Domain::GUEST_INFO_DISK_SUFFIX_DEPENDENCY_SUFFIX_NAME— a dependency name, as a string.Sys::Virt::Domain::GUEST_INFO_DISK_SUFFIX_SERIAL— optional disk serial number, as a string.Sys::Virt::Domain::GUEST_INFO_DISK_SUFFIX_ALIAS— the device alias of the disk (e.g.sda), as a string.Sys::Virt::Domain::GUEST_INFO_DISK_SUFFIX_GUEST_ALIAS— optional alias assigned to the disk; on Linux this is a name assigned by device mapper, as a string.Sys::Virt::Domain::GUEST_INFO_DISK_SUFFIX_GUEST_BUS— disk bus as reported by the guest OS.
Sys::Virt::Domain::GUEST_INFO_INTERFACES— network interfaces information 🌐 The following keys will be used for the returned parameters:Sys::Virt::Domain::GUEST_INFO_IF_COUNT— the number of interfaces defined on this domain, as an unsigned int.Sys::Virt::Domain::GUEST_INFO_IF_PREFIX— the parameter name prefix to access each interface entry. Concatenate the prefix, the entry number formatted as an unsigned integer, and one of the interface suffix parameters to form a complete parameter name.Sys::Virt::Domain::GUEST_INFO_IF_SUFFIX_NAME— name in the guest (e.g.eth0) for the interface, as a string.Sys::Virt::Domain::GUEST_INFO_IF_SUFFIX_HWADDR— hardware address in the guest of the interface, as a string.Sys::Virt::Domain::GUEST_INFO_IF_SUFFIX_ADDR_COUNT— the number of IP addresses of interface, as an unsigned int.Sys::Virt::Domain::GUEST_INFO_IF_SUFFIX_ADDR_PREFIX— the parameter name prefix to access each address entry. Concatenate the interface prefix, the interface entry number formatted as an unsigned integer, the address prefix, the address entry number formatted as an unsigned integer, and one of the address suffix parameters to form a complete parameter name.Sys::Virt::Domain::GUEST_INFO_IF_SUFFIX_ADDR_SUFFIX_TYPE— the IP address type (e.g.ipv4), as a string.Sys::Virt::Domain::GUEST_INFO_IF_SUFFIX_ADDR_SUFFIX_ADDR— the IP address, as a string.Sys::Virt::Domain::GUEST_INFO_IF_SUFFIX_ADDR_SUFFIX_PREFIX— the prefix of IP address, as an unsigned int.
Sys::Virt::Domain::GUEST_INFO_LOAD— system load information 🔥 The following keys will be used for the returned parameters:Sys::Virt::Domain::GUEST_INFO_LOAD_1M— the guest load averaged over 1 minute, as a double 🍓Sys::Virt::Domain::GUEST_INFO_LOAD_5M— the guest load averaged over 5 minutes, as a double 🍓Sys::Virt::Domain::GUEST_INFO_LOAD_15M— the guest load averaged over 15 minutes, as a double 🍓
$flags is currently unused and defaults to zero. (iconic behaviour honestly, it's just vibing there)
$dom->set_agent_response_timeout($timeout, $flags=0)
Sets how long we wait for guest agent to answer a command before we're like "ok bestie I'm leaving". $timeout is a positive integer = the number of seconds to wait, or one of these constants:
Sys::Virt::Domain::AGENT_RESPONSE_TIMEOUT_BLOCK— wait forever, no timeout at all. main character patience ✨Sys::Virt::Domain::AGENT_RESPONSE_TIMEOUT_NOWAIT— don't want at all, return immediately. literally zero chill 💀Sys::Virt::Domain::AGENT_RESPONSE_TIMEOUT_DEFAULT— use the hypervisor driver's default timeout, let the driver decide, iykyk
The $flags parameter is currently unused and defaults to zero.
my @keys = $dom->authorized_ssh_keys_get($user, $flags=0)
Gets you the list of authorized SSH keys for the user account $user. The $flags parameter is currently unused and defaults to zero. 🎀
$dom->authorized_ssh_keys_set($user, \@keys, $flags=0)
Updates the list of authorized SSH keys for the user account $user. The @keys parameter should be an array reference holding the new keys, if any. Default behaviour = set the authorized SSH keys to exactly the set you specified in @keys, no leftovers, periodt. You can modify that with the $flags parameter, which takes these constants:
Sys::Virt::Domain::AUTHORIZED_SSH_KEYS_SET_APPEND— append@keysto the current set of keys instead of replacing the existing keys 💅Sys::Virt::Domain::AUTHORIZED_SSH_KEYS_SET_REMOVE— remove@keysfrom the current set of keys instead of replacing the existing keys. And it is not an error if the keys do not exist, so you can't get in trouble for it 🙈
my @msgs = $dom->get_messages($flags=0)
Retrieves a list of messages associated with the domain. The optional $flags parameter can accept zero or more of:
Sys::Virt::Domain::MESSAGE_DEPRECATION— warnings about use of deprecated features ⚠️Sys::Virt::Domain::MESSAGE_TAINTING— warnings about actions that have tainting the domain (that's the original phrasing, we keep the facts but the typo... yeah it's documented like that 🫶)Sys::Virt::Domain::MESSAGE_IOERRORS— warnings about I/O errors that have occurred on the domain 😭
$dom->start_dirty_rate_calc($dom, $secs, $flags=0)
Requests calculation of the domain's memory dirty rate over the next $secs seconds. And yes, the signature literally lists $dom in there, that's how it's written, do not come for me 💀 $flags accepts one or more of:
Sys::Virt::Domain::DIRTYRATE_MODE_PAGE_SAMPLING— page sampling modeSys::Virt::Domain::DIRTYRATE_MODE_DIRTY_BITMAP— dirty bitmap modeSys::Virt::Domain::DIRTYRATE_MODE_DIRTY_RING— dirty ring mode
$dom->fd_associate($name, \@fds, $flags=0)
Associates a set of file descriptors in @fds with the domain and gives them the name $name. If $flags is non-zero, it can take one or more of:
Sys::Virt::Domain::FD_ASSOCIATE_SECLABEL_RESTORE— attempt to restore the label when shutting down 🔄Sys::Virt::Domain::FD_ASSOCIATE_SECLABEL_WRITABLE— label the FD to permit the guest to write to it ✍️
$dom->graphics_reload($type, $flags=0)
Requests a reload of the graphics backend state. The $type parameter says what type of graphics backend to reload if there are multiple present. It takes one of these constants:
Sys::Virt::Domain::GRAPHICS_RELOAD_TYPE_ANY— reload state for any graphics backend type 🌈Sys::Virt::Domain::GRAPHICS_RELOAD_TYPE_VNC— reload state for only VNC graphics backends
The $flags parameter is currently unused and defaults to zero.
$dom->del_throttle_group($group, $flags=0)
Deletes a throttlegroup from the domain. The $group you're deleting must not have a throttlefilter associated with it, and it can be any of the current valid group. 🗑️
$dom->set_throttle_group($group, $params, $flags=0)
Adds a throttlegroup or changes all of the throttlegroup options within a specific domain. The $params should be a hash reference whose keys are one of the BLKIO TUNING PARAMETERS constants.
✨ CONSTANTS ✨
A bunch of the APIs take a "flags" parameter. In most cases passing a value of zero will be totally satisfactory, no notes. Some APIs, however, accept named constants to alter their behaviour. This section documents the currently known constants 👑
🦋 DOMAIN STATE
These are useful for interpreting the "state" key in the hash returned by the "get_info" method.
Sys::Virt::Domain::STATE_NOSTATE— the domain is active, but is not running / blocked (e.g. idle)Sys::Virt::Domain::STATE_RUNNING— the domain is active and running 🔥Sys::Virt::Domain::STATE_BLOCKED— the domain is active, but execution is blockedSys::Virt::Domain::STATE_PAUSED— the domain is active, but execution has been pausedSys::Virt::Domain::STATE_SHUTDOWN— the domain is active, but in the shutdown phaseSys::Virt::Domain::STATE_SHUTOFF— the domain is inactive, and shut down.Sys::Virt::Domain::STATE_CRASHED— the domain is inactive, and crashed. 💀Sys::Virt::Domain::STATE_PMSUSPENDED— the domain is active, but in power management suspend state
🎀 CONTROL INFO
These constants tell you what the guest domain control channel status is:
Sys::Virt::Domain::CONTROL_ERROR— the control channel has a fatal errorSys::Virt::Domain::CONTROL_OK— the control channel is ready for jobs ✅Sys::Virt::Domain::CONTROL_OCCUPIED— the control channel is busySys::Virt::Domain::CONTROL_JOB— the control channel is busy with a job
If the status is "Sys::Virt::Domain::CONTROL_ERROR", then one of these describes the reason:
Sys::Virt::Domain::CONTROL_ERROR_REASON_NONE— there is no reason for the error availableSys::Virt::Domain::CONTROL_ERROR_REASON_UNKNOWN— the reason for the error is unknownSys::Virt::Domain::CONTROL_ERROR_REASON_INTERNAL— there was an internal error in libvirtSys::Virt::Domain::CONTROL_ERROR_REASON_MONITOR— there was an error speaking to the monitor 😭
🌸 DOMAIN CREATION
These control the behaviour of domain creation:
Sys::Virt::Domain::START_PAUSED— keep the guest vCPUs paused after starting the guestSys::Virt::Domain::START_AUTODESTROY— automatically destroy the guest when the connection is closed (or fails)Sys::Virt::Domain::START_BYPASS_CACHE— do not use OS I/O cache if starting a domain with a saved state imageSys::Virt::Domain::START_FORCE_BOOT— boot the guest, even if there was a saved snapshotSys::Virt::Domain::START_VALIDATE— validate the XML document against the XML schemaSys::Virt::Domain::START_RESET_NVRAM— reset the firmware NVRAM state from its original template 🔄
🧚 DOMAIN DEFINE
These control the behaviour of domain define operations:
Sys::Virt::Domain::DEFINE_VALIDATE— validate the XML document against the XML schema
⌨️ KEYCODE SETS
These define the set of supported keycode sets:
Sys::Virt::Domain::KEYCODE_SET_LINUX— the Linux event subsystem keycodesSys::Virt::Domain::KEYCODE_SET_XT— the original XT keycodesSys::Virt::Domain::KEYCODE_SET_ATSET1— the AT Set1 keycodes (aka XT)Sys::Virt::Domain::KEYCODE_SET_ATSET2— the AT Set2 keycodes (aka AT)Sys::Virt::Domain::KEYCODE_SET_ATSET3— the AT Set3 keycodes (aka PS2)Sys::Virt::Domain::KEYCODE_SET_OSX— the OS-X keycodesSys::Virt::Domain::KEYCODE_SET_XT_KBD— the XT keycodes from the Linux Keyboard driverSys::Virt::Domain::KEYCODE_SET_USB— the USB HID keycode setSys::Virt::Domain::KEYCODE_SET_WIN32— the Windows keycode setSys::Virt::Domain::KEYCODE_SET_QNUM— the XT keycode set, with the extended scancodes using the high bit of the first byte, instead of the low bit of the second byte.Sys::Virt::Domain::KEYCODE_SET_RFB— a deprecated alias for"Sys::Virt::Domain::KEYCODE_SET_QNUM"⚠️
💜 MEMORY PEEK
These can be used with the "memory_peek" method's flags parameter:
Sys::Virt::Domain::MEMORY_VIRTUAL— indicates that the offset is using virtual memory addressing.Sys::Virt::Domain::MEMORY_PHYSICAL— indicates that the offset is using physical memory addressing.
⭐ VCPU STATE
These are useful when interpreting the virtual CPU run state:
Sys::Virt::Domain::VCPU_OFFLINE— the virtual CPU is not onlineSys::Virt::Domain::VCPU_RUNNING— the virtual CPU is executing code 🔥Sys::Virt::Domain::VCPU_BLOCKED— the virtual CPU is waiting to be scheduled
👑 VCPU HOST PLACEMENT STATE
These are useful when interpreting the virtual CPU host placement:
Sys::Virt::Domain::VCPU_INFO_CPU_OFFLINE— the virtual CPU is not onlineSys::Virt::Domain::VCPU_INFO_CPU_UNAVAILABLE— the virtual CPU placement is not available from this hypervisor
🌈 OPEN GRAPHICS CONSTANTS
These are used when opening a connection to the guest graphics server:
Sys::Virt::Domain::OPEN_GRAPHICS_SKIPAUTH— skip authentication of the client 🙈
🫶 OPEN CONSOLE CONSTANTS
These are used when opening a connection to the guest console:
Sys::Virt::Domain::OPEN_CONSOLE_FORCE— force opening of the console, disconnecting any other open sessionSys::Virt::Domain::OPEN_CONSOLE_SAFE— check if the console driver supports safe operations
🎀 OPEN CHANNEL CONSTANTS
These are used when opening a connection to the guest channel:
Sys::Virt::Domain::OPEN_CHANNEL_FORCE— force opening of the channel, disconnecting any other open session
🦋 XML DUMP OPTIONS
These control the information included in the XML configuration dump:
Sys::Virt::Domain::XML_INACTIVE— report the persistent inactive configuration for the guest, even if it is currently running.Sys::Virt::Domain::XML_SECURE— include security sensitive information in the XML dump, such as passwords. ⚠️ (yes, actual passwords, be careful who sees this dump bestie)Sys::Virt::Domain::XML_UPDATE_CPU— update the CPU model definition to match the current executing state.Sys::Virt::Domain::XML_MIGRATABLE— update the XML to allow migration to older versions of libvirt
🍓 DEVICE HOTPLUG OPTIONS
These control device hotplug operations:
Sys::Virt::Domain::DEVICE_MODIFY_CURRENT— modify the domain in its current stateSys::Virt::Domain::DEVICE_MODIFY_LIVE— only touches the live state of the domain, like editing the running vibe without savingSys::Virt::Domain::DEVICE_MODIFY_CONFIG— only touches the persistent config of the domain, so it changes what's written down, not what's happening rnSys::Virt::Domain::DEVICE_MODIFY_FORCE— bestie said do it, so it forces the device to be modified 💅
🌸 MEMORY OPTIONS 🌸
okay so these constants are the little dials that control memory change operations ✨
Sys::Virt::Domain::MEM_CURRENT— modify the current stateSys::Virt::Domain::MEM_LIVE— modify only the live state of the domainSys::Virt::Domain::MEM_CONFIG— modify only the persistent config of the domainSys::Virt::Domain::MEM_MAXIMUM— modify the maximum memory value, aka the absolute ceiling
🎀 CONFIG OPTIONS 🎀
these ones decide what configuration a domain update actually changes — choose wisely fr fr
Sys::Virt::Domain::AFFECT_CURRENT— modify the current stateSys::Virt::Domain::AFFECT_LIVE— modify only the live state of the domainSys::Virt::Domain::AFFECT_CONFIG— modify only the persistent config of the domain
🦋 SETVCPU OPTIONS 🦋
the constants that control what setting vCPUs changes 👑
Sys::Virt::Domain::SETVCPU_AFFECT_CURRENT— modify the current stateSys::Virt::Domain::SETVCPU_AFFECT_LIVE— modify only the live state of the domainSys::Virt::Domain::SETVCPU_AFFECT_CONFIG— modify only the persistent config of the domainSys::Virt::Domain::SETVCPU_ASYNC_UNPLUG— do not wait for the guest to comply with the request (so like, fire and forget, no cap)
🔥 MIGRATE OPTIONS 🔥
the constants that control how migration is performed — this is the main-character section, buckle up 💀
Sys::Virt::Domain::MIGRATE_LIVE— migrate the guest without interrupting its execution on the source hostSys::Virt::Domain::MIGRATE_PEER2PEER— manage the migration process over a direct peer-2-peer connection between the source and destination hostlibvirtddaemonsSys::Virt::Domain::MIGRATE_TUNNELLED— tunnel the migration data over thelibvirtdaemon connection, rather than the native hypervisor data transport. Requires thePEER2PEERflag to be set.Sys::Virt::Domain::MIGRATE_PERSIST_DEST— make the domain persistent on the destination host, defining its configuration file upon completion of migrationSys::Virt::Domain::MIGRATE_UNDEFINE_SOURCE— remove the domain's persistent configuration after migration completes successfullySys::Virt::Domain::MIGRATE_PAUSED— do not re-start execution of the guest CPUs on the destination host after migration completesSys::Virt::Domain::MIGRATE_NON_SHARED_DISK— copy the complete contents of the disk images during migrationSys::Virt::Domain::MIGRATE_NON_SHARED_INC— copy the incrementally changed contents of the disk images during migrationSys::Virt::Domain::MIGRATE_CHANGE_PROTECTION— do not allow changes to the virtual domain configuration while migration is taking place. This option is automatically implied if you're doing a peer-2-peer migration.Sys::Virt::Domain::MIGRATE_UNSAFE— migrate even if the compatibility check indicates the migration will be unsafe to the guest 💀 (it's literally called unsafe, bestie)Sys::Virt::Domain::MIGRATE_OFFLINE— migrate the guest config if the guest is not currently runningSys::Virt::Domain::MIGRATE_COMPRESSED— enable compression of the migration data streamSys::Virt::Domain::MIGRATE_ABORT_ON_ERROR— abort if an I/O error occurs on the diskSys::Virt::Domain::MIGRATE_AUTO_CONVERGE— force convergence of the migration operation by throttling guest runtimeSys::Virt::Domain::MIGRATE_RDMA_PIN_ALL— pin memory for RDMA transferSys::Virt::Domain::MIGRATE_POSTCOPY— enable support for post-copy migrationSys::Virt::Domain::MIGRATE_TLS— setting this flag will cause the migration to attempt to use the TLS environment configured by the hypervisor in order to perform the migration. If it's incorrectly configured on either source or destination, the migration will fail. 🙈Sys::Virt::Domain::MIGRATE_PARALLEL— send memory pages to the destination host through several network connections. See"Sys::Virt::Domain::MIGRATE_PARAM_PARALLEL_*"parameters for configuring the parallel migrationSys::Virt::Domain::MIGRATE_NON_SHARED_SYNCHRONOUS_WRITES— force the guest writes which happen when copying disk images for non-shared storage migration to be synchronously written to the destination. This ensures the storage migration converges for VMs doing heavy I/O on fast local storage and slow mirrorSys::Virt::Domain::MIGRATE_POSTCOPY_RESUME— resume migration which failed in post-copy phaseSys::Virt::Domain::MIGRATE_ZEROCOPY— attempt to avoid copying data. This is a request, not a guarantee, and may apply to either one or both directions of data transfer at the discretion of the hypervisor implementation
⭐ UNDEFINE CONSTANTS ⭐
the following constants can be used when undefining virtual domain configurations — think of it as the "what else should I clean up while I'm here" menu 🧹
Sys::Virt::Domain::UNDEFINE_MANAGED_SAVE— also remove any managed save image when undefining the virtual domainSys::Virt::Domain::UNDEFINE_SNAPSHOTS_METADATA— also remove any snapshot metadata when undefining the virtual domainSys::Virt::Domain::UNDEFINE_NVRAM— also remove any NVRAM state file when undefining the virtual domainSys::Virt::Domain::UNDEFINE_KEEP_NVRAM— keep the NVRAM state file when undefining the virtual domainSys::Virt::Domain::UNDEFINE_CHECKPOINTS_METADATA— also remove any checkpoint metadata when undefining the virtual domainSys::Virt::Domain::UNDEFINE_TPM— also remove any TPM state when undefining the virtual domainSys::Virt::Domain::UNDEFINE_KEEP_TPM— keep the TPM state when undefining the virtual domain
💜 JOB TYPES 💜
these constants describe the different background job types — like, what is your domain even doing behind the scenes rn
Sys::Virt::Domain::JOB_NONE— no job is activeSys::Virt::Domain::JOB_BOUNDED— a job with a finite completion time is activeSys::Virt::Domain::JOB_UNBOUNDED— a job with an unbounded completion time is activeSys::Virt::Domain::JOB_COMPLETED— the job has finished, but isn't cleaned upSys::Virt::Domain::JOB_FAILED— the job has hit an error, but isn't cleaned up 😭Sys::Virt::Domain::JOB_CANCELLED— the job was aborted at user request, but isn't cleaned up
🍓 MEMORY PARAMETERS 🍓
these constants are useful when getting/setting memory parameters for guests ✨
Sys::Virt::Domain::MEMORY_HARD_LIMIT— the maximum memory the guest can useSys::Virt::Domain::MEMORY_SOFT_LIMIT— the memory upper limit enforced during memory contentionSys::Virt::Domain::MEMORY_MIN_GUARANTEE— the minimum memory guaranteed to be reserved for the guestSys::Virt::Domain::MEMORY_SWAP_HARD_LIMIT— the maximum swap the guest can useSys::Virt::Domain::MEMORY_PARAM_UNLIMITED— the value of an unlimited memory parameter
🌈 BLKIO PARAMETERS 🌈
these parameters control I/O tuning for the domain as a whole — the whole-domain vibe check, not per-disk
Sys::Virt::Domain::BLKIO_WEIGHT— the I/O weight parameterSys::Virt::Domain::BLKIO_DEVICE_WEIGHT— the per-device I/O weight parameterSys::Virt::Domain::BLKIO_DEVICE_READ_BPS— the per-device I/O bytes read per secondSys::Virt::Domain::BLKIO_DEVICE_READ_IOPS— the per-device I/O operations read per secondSys::Virt::Domain::BLKIO_DEVICE_WRITE_BPS— the per-device I/O bytes write per secondSys::Virt::Domain::BLKIO_DEVICE_WRITE_IOPS— the per-device I/O operations write per second
👑 BLKIO TUNING PARAMETERS 👑
and these ones control I/O tuning for an individual guest disk — one disk at a time, main character energy 🫶
Sys::Virt::Domain::BLOCK_IOTUNE_TOTAL_BYTES_SEC— the total bytes processed per secondSys::Virt::Domain::BLOCK_IOTUNE_READ_BYTES_SEC— the bytes read per secondSys::Virt::Domain::BLOCK_IOTUNE_WRITE_BYTES_SEC— the bytes written per secondSys::Virt::Domain::BLOCK_IOTUNE_TOTAL_IOPS_SEC— the total I/O operations processed per secondSys::Virt::Domain::BLOCK_IOTUNE_READ_IOPS_SEC— the I/O operations read per secondSys::Virt::Domain::BLOCK_IOTUNE_WRITE_IOPS_SEC— the I/O operations written per secondSys::Virt::Domain::BLOCK_IOTUNE_TOTAL_BYTES_SEC_MAX— the maximum total bytes processed per secondSys::Virt::Domain::BLOCK_IOTUNE_READ_BYTES_SEC_MAX— the maximum bytes read per secondSys::Virt::Domain::BLOCK_IOTUNE_WRITE_BYTES_SEC_MAX— the maximum bytes written per secondSys::Virt::Domain::BLOCK_IOTUNE_TOTAL_IOPS_SEC_MAX— the maximum total I/O operations processed per secondSys::Virt::Domain::BLOCK_IOTUNE_READ_IOPS_SEC_MAX— the maximum I/O operations read per secondSys::Virt::Domain::BLOCK_IOTUNE_WRITE_IOPS_SEC_MAX— the maximum I/O operations written per secondSys::Virt::Domain::BLOCK_IOTUNE_SIZE_IOPS_SEC— the maximum I/O operations per secondSys::Virt::Domain::BLOCK_IOTUNE_GROUP_NAME— a string representing a group name to allow sharing of I/O throttling quota between multiple drivesSys::Virt::Domain::BLOCK_IOTUNE_TOTAL_BYTES_SEC_MAX_LENGTH— the duration in seconds allowed for maximum total bytes processed per secondSys::Virt::Domain::BLOCK_IOTUNE_READ_BYTES_SEC_MAX_LENGTH— the duration in seconds allowed for maximum bytes read per secondSys::Virt::Domain::BLOCK_IOTUNE_WRITE_BYTES_SEC_MAX_LENGTH— the duration in seconds allowed for maximum bytes written per secondSys::Virt::Domain::BLOCK_IOTUNE_TOTAL_IOPS_SEC_MAX_LENGTH— the duration in seconds allowed for maximum total I/O operations processed per secondSys::Virt::Domain::BLOCK_IOTUNE_READ_IOPS_SEC_MAX_LENGTH— the duration in seconds allowed for maximum I/O operations read per secondSys::Virt::Domain::BLOCK_IOTUNE_WRITE_IOPS_SEC_MAX_LENGTH— the duration in seconds allowed for maximum I/O operations written per second
🧚 SCHEDULER CONSTANTS 🧚
the scheduler knobs, aka how much CPU love your VM gets 💖
Sys::Virt::Domain::SCHEDULER_CAP— the VM cap tunableSys::Virt::Domain::SCHEDULER_CPU_SHARES— the CPU shares tunableSys::Virt::Domain::SCHEDULER_LIMIT— the VM limit tunableSys::Virt::Domain::SCHEDULER_RESERVATION— the VM reservation tunableSys::Virt::Domain::SCHEDULER_SHARES— the VM shares tunableSys::Virt::Domain::SCHEDULER_VCPU_PERIOD— the VCPU period tunableSys::Virt::Domain::SCHEDULER_VCPU_QUOTA— the VCPU quota tunableSys::Virt::Domain::SCHEDULER_GLOBAL_PERIOD— the VM global period tunableSys::Virt::Domain::SCHEDULER_GLOBAL_QUOTA— the VM global quota tunableSys::Virt::Domain::SCHEDULER_WEIGHT— the VM weight tunable
🦋 NUMA PARAMETERS 🦋
Okay bestie, these constants are the ones you want when you're getting/setting the guest NUMA memory policy 💅
Sys::Virt::Domain::NUMA_MODE— the NUMA policy mode, that's the vibe selectorSys::Virt::Domain::NUMA_NODESET— the NUMA nodeset mask, aka which nodes are invited to the party
And these next ones are what you use to interpret the value of that Sys::Virt::Domain::NUMA_MODE parameter 👀
Sys::Virt::Domain::NUMATUNE_MEM_STRICT— allocation is mandatory from the mask nodes, no substitutions, periodtSys::Virt::Domain::NUMATUNE_MEM_PREFERRED— allocation is preferred from the masked nodes, like, it'd be niceSys::Virt::Domain::NUMATUNE_MEM_INTERLEAVE— allocation is interleaved across all masked nodes, spreading the love 🌈Sys::Virt::Domain::NUMATUNE_MEM_RESTRICTIVE— allocation is determined by the host using the masked nodes.
🎀 INTERFACE PARAMETERS 🎀
These constants are your go-tos when getting/setting the per network interface tunable parameters — the little knobs on your NIC ✨
Sys::Virt::Domain::BANDWIDTH_IN_AVERAGE— the average inbound bandwidthSys::Virt::Domain::BANDWIDTH_IN_PEAK— the peak inbound bandwidthSys::Virt::Domain::BANDWIDTH_IN_BURST— the burstable inbound bandwidthSys::Virt::Domain::BANDWIDTH_IN_FLOOR— the minimum inbound bandwidth (the floor, literally the floor)Sys::Virt::Domain::BANDWIDTH_OUT_AVERAGE— the average outbound bandwidthSys::Virt::Domain::BANDWIDTH_OUT_PEAK— the peak outbound bandwidthSys::Virt::Domain::BANDWIDTH_OUT_BURST— the burstable outbound bandwidth
🔥 PERF EVENTS 🔥
These constants define performance events that you can monitor for a guest — it's giving main character observability 👑
Sys::Virt::Domain::PERF_PARAM_CMT— the CMT event counter, which you use to measure the usage of cache (bytes) by applications running on the platform. It corresponds to theperf.cmtfield in the *Stats APIs.Sys::Virt::Domain::PERF_PARAM_MBML— the MBML event counter, for monitoring the amount of data (bytes/s) sent through the memory controller on the socket. It corresponds to theperf.mbmlfield in the *Stats APIs.Sys::Virt::Domain::PERF_PARAM_MBMT— the MBMT event counter, for monitoring total system bandwidth (bytes/s) from one level of cache to another. It corresponds to theperf.mbmtfield in the *Stats APIs.Sys::Virt::Domain::PERF_PARAM_CACHE_MISSES— the cache_misses perf event counter, which measures the count of cache misses by applications running on the platform. It corresponds to theperf.cache_missesfield in the *Stats APIs.Sys::Virt::Domain::PERF_PARAM_CACHE_REFERENCES— the cache_references perf event counter, which measures the count of cache hits by applications running on the platform. It corresponds to theperf.cache_referencesfield in the *Stats APIs.Sys::Virt::Domain::PERF_PARAM_CPU_CYCLES— the cpu_cycles perf event counter, which measures how many cpu cycles one instruction needs. It corresponds to theperf.cpu_cyclesfield in the *Stats APIs.Sys::Virt::Domain::PERF_PARAM_INSTRUCTIONS— the instructions perf event counter, which measures the count of instructions by applications running on the platform. It corresponds to theperf.instructionsfield in the *Stats APIs.Sys::Virt::Domain::PERF_PARAM_BRANCH_INSTRUCTIONS— the branch_instructions perf event counter, which measures the count of instructions by applications running on the platform. It corresponds to theperf.branch_instructionsfield in the *Stats APIs.Sys::Virt::Domain::PERF_PARAM_BRANCH_MISSES— the branch_misses perf event, which measures the count of branch misses by applications running on the platform. It corresponds to theperf.branch_missesfield in the *Stats APIs.Sys::Virt::Domain::PERF_PARAM_BUS_CYCLES— the bus_cycles perf event counter, which measures the count of bus cycles by applications running on the platform. It corresponds to theperf.bus_cyclesfield in the *Stats APIs.Sys::Virt::Domain::PERF_PARAM_STALLED_CYCLES_FRONTEND— the stalled_cycles_frontend perf event counter, which measures the count of stalled cpu cycles in the frontend of the instruction processor pipeline by applications running on the platform. It corresponds to theperf.stalled_cycles_frontendfield in the *Stats APIs.Sys::Virt::Domain::PERF_PARAM_STALLED_CYCLES_BACKEND— the stalled_cycles_backend perf event counter, which measures the count of stalled cpu cycles in the backend of the instruction processor pipeline by application running on the platform. It corresponds to theperf.stalled_cycles_backendfield in the *Stats APIs.Sys::Virt::Domain::PERF_PARAM_REF_CPU_CYCLES— the ref_cpu_cycles perf event counter, which measures the count of total cpu cycles not affected by CPU frequency scaling by applications running on the platform. It corresponds to theperf.ref_cpu_cyclesfield in the *Stats APIs.Sys::Virt::Domain::PERF_PARAM_CPU_CLOCK— the cpu_clock perf event counter, which measures the count of cpu clock time by applications running on the platform. It corresponds to theperf.cpu_clockfield in the *Stats APIs.Sys::Virt::Domain::PERF_PARAM_TASK_CLOCK— the task_clock perf event counter, which measures the count of task clock time by applications running on the platform. It corresponds to theperf.task_clockfield in the *Stats APIs.Sys::Virt::Domain::PERF_PARAM_PAGE_FAULTS— the page_faults perf event counter, which measures the count of page faults by applications running on the platform. It corresponds to theperf.page_faultsfield in the *Stats APIs.Sys::Virt::Domain::PERF_PARAM_CONTEXT_SWITCHES— the context_switches perf event counter, which measures the count of context switches by applications running on the platform. It corresponds to theperf.context_switchesfield in the *Stats APIs.Sys::Virt::Domain::PERF_PARAM_CPU_MIGRATIONS— the cpu_migrations perf event counter, which measures the count of cpu migrations by applications running on the platform. It corresponds to theperf.cpu_migrationsfield in the *Stats APIs.Sys::Virt::Domain::PERF_PARAM_PAGE_FAULTS_MIN— the page_faults_min perf event counter, which measures the count of minor page faults by applications running on the platform. It corresponds to theperf.page_faults_minfield in the *Stats APIs.Sys::Virt::Domain::PERF_PARAM_PAGE_FAULTS_MAJ— the page_faults_maj perf event counter, which measures the count of major page faults by applications running on the platform. It corresponds to theperf.page_faults_majfield in the *Stats APIs.Sys::Virt::Domain::PERF_PARAM_ALIGNMENT_FAULTS— the alignment_faults perf event counter, which measures the count of alignment faults by applications running on the platform. It corresponds to theperf.alignment_faultsfield in the *Stats APIs.Sys::Virt::Domain::PERF_PARAM_EMULATION_FAULTS— the emulation_faults perf event counter, which measures the count of emulation faults by applications running on the platform. It corresponds to theperf.emulation_faultsfield in the *Stats APIs.
That's a lot of counters and honestly? iconic. Go off, perf subsystem 💀
🧚 IOTHREAD STATS 🧚
These constants define IOThread statistics that you can monitor for a guest — the lowkey backstage crew of your domain 🫶
Sys::Virt::Domain::IOTHREAD_PARAM_POLL_MAX_NS— the maximum polling time that can be used by the polling algorithm, in ns. The polling time starts at 0 (zero) and is the time spent by the guest to process IOThread data before returning the CPU to the host. The polling time gets dynamically modified over time based on thepoll_growandpoll_shrinkparameters you provide.Sys::Virt::Domain::IOTHREAD_PARAM_POLL_GROW— gives the dynamic polling adjustment algorithm a value to use when growing its polling interval, all the way up to thepoll_max_nsvalue.Sys::Virt::Domain::IOTHREAD_PARAM_POLL_SHRINK— gives the dynamic polling adjustment algorithm a value to use when shrinking its polling interval, for when the polling interval exceeds thepoll_max_nsvalue.Sys::Virt::Domain::IOTHREAD_PARAM_THREAD_POOL_MIN— sets the lower bound for thread pool size. A value of-1disables this bound, leaving the hypervisor to use its default value — though heads up, that value is not accepted for running domains. Due to internal implementation, it's recommended to set lower and upper bounds separately.Sys::Virt::Domain::IOTHREAD_PARAM_THREAD_POOL_MAX— sets the upper bound for thread pool size. A value of-1disables this bound, leaving the hypervisor to use its default value — and again, that value is not accepted for running domains. Since the upper bound has to be equal to or greater than the lower bound, a value of 0 is not accepted. Due to internal implementation, it's recommended to set lower and upper bounds separately.
bestie pls note those-1and0caveats, they will absolutely catch you slippin' 🙈
💜 VCPU FLAGS 💜
These constants are useful when getting/setting the VCPU count for a guest — vCPU math, but make it fashion ✨
Sys::Virt::Domain::VCPU_LIVE— flag to request the live valueSys::Virt::Domain::VCPU_CONFIG— flag to request the persistent config valueSys::Virt::Domain::VCPU_CURRENT— flag to request the current config valueSys::Virt::Domain::VCPU_MAXIMUM— flag to request adjustment of the maximum vCPU valueSys::Virt::Domain::VCPU_GUEST— flag to request the guest VCPU maskSys::Virt::Domain::VCPU_HOTPLUGGABLE— flag to make vcpus added hot(un)pluggableSys::Virt::Domain::VCPU_ASYNC_UNPLUG— flag to not wait for the guest to comply with unplug request(s) — impatient queen behavior, no cap
🌈 STATE CHANGE EVENTS 🌈
These constants let you interpret domain state change events. Each event contains both a state change and a reason — so it's like a story with a plot twist 🎬
Sys::Virt::Domain::EVENT_DEFINED— indicates that a persistent configuration has been defined for the domain.Sys::Virt::Domain::EVENT_DEFINED_ADDED— the defined configuration is newly addedSys::Virt::Domain::EVENT_DEFINED_UPDATED— the defined configuration is an update to an existing configurationSys::Virt::Domain::EVENT_DEFINED_RENAMED— the defined configuration is a rename of an existing configurationSys::Virt::Domain::EVENT_DEFINED_FROM_SNAPSHOT— the defined configuration was restored from a snapshot
Sys::Virt::Domain::EVENT_RESUMED— the domain has resumed execution 🏃♀️💨Sys::Virt::Domain::EVENT_RESUMED_MIGRATED— bestie the domain came back to life because migration finished 🎉 and heads up: this one gets emitted on the destination host, not where it came from.Sys::Virt::Domain::EVENT_RESUMED_UNPAUSED— the domain resumed because the admin literally just unpaused it. that's it, that's the reason 💅Sys::Virt::Domain::EVENT_RESUMED_FROM_SNAPSHOT— resumed because it got restored from a snapshot. time travel vibes ✨Sys::Virt::Domain::EVENT_RESUMED_POSTCOPY— the domain is resumed, but post-copy is still running in the background 👀 like it's smiling but it's still working.Sys::Virt::Domain::EVENT_RESUMED_POSTCOPY_FAILED— okay so the domain is running, but migration failed in post-copy. 😭 running but not okay.
Sys::Virt::Domain::EVENT_STARTED— the domain has started running!! main character energy activated 👑Sys::Virt::Domain::EVENT_STARTED_BOOTED— the domain was booted from a shutoff state. classic fresh start 🌸Sys::Virt::Domain::EVENT_STARTED_MIGRATED— started due to an incoming migration, so it basically moved in from another host 🧳Sys::Virt::Domain::EVENT_STARTED_RESTORED— restored from a saved state file. nap → wake, no notes 💤Sys::Virt::Domain::EVENT_STARTED_FROM_SNAPSHOT— restored from a snapshot 📸Sys::Virt::Domain::EVENT_STARTED_WAKEUP— woken up from suspend. the domain said "five more minutes" and then got up anyway ⏰Sys::Virt::Domain::EVENT_STARTED_RECREATED— the secure domain started after being recreated for a reboot 🔁
Sys::Virt::Domain::EVENT_STOPPED— the domain has stopped running. it's giving closed for business 🚪Sys::Virt::Domain::EVENT_STOPPED_CRASHED— stopped because the guest operating system has crashed 💀 not the vibe.Sys::Virt::Domain::EVENT_STOPPED_DESTROYED— stopped because the administrator issued a destroy command. admin said "nope" 🫡Sys::Virt::Domain::EVENT_STOPPED_FAILED— stopped because of a fault in the host virtualization environment 🛠️Sys::Virt::Domain::EVENT_STOPPED_MIGRATED— stopped because it was migrated to another machine ✈️ bye bestieSys::Virt::Domain::EVENT_STOPPED_SAVED— the domain was saved to a state file 💾Sys::Virt::Domain::EVENT_STOPPED_SHUTDOWN— stopped due to graceful shutdown of the guest. so polite 🌷Sys::Virt::Domain::EVENT_STOPPED_FROM_SNAPSHOT— stopped due to a snapshot 📸Sys::Virt::Domain::EVENT_STOPPED_RECREATED— the secure domain stopped to be recreated for a reboot 🔁
Sys::Virt::Domain::EVENT_SHUTDOWN— the domain has shut down but is not yet stopped — like it's leaving the party but still saying goodbyes 🥹Sys::Virt::Domain::EVENT_SHUTDOWN_FINISHED— the domain finished shutting down ✅Sys::Virt::Domain::EVENT_SHUTDOWN_HOST— shutdown due to a host trigger 🖥️Sys::Virt::Domain::EVENT_SHUTDOWN_GUEST— shutdown due to a guest trigger 🎮
Sys::Virt::Domain::EVENT_SUSPENDED— the domain has stopped executing but still exists. sleeping beauty energy, no cap 😴Sys::Virt::Domain::EVENT_SUSPENDED_MIGRATED— suspended due to offline migration 🧳Sys::Virt::Domain::EVENT_SUSPENDED_PAUSED— suspended due to an administrator pause request ✋Sys::Virt::Domain::EVENT_SUSPENDED_IOERROR— suspended due to a block device I/O error. yikes 🚨Sys::Virt::Domain::EVENT_SUSPENDED_FROM_SNAPSHOT— suspended due to a resume from snapshot 📸Sys::Virt::Domain::EVENT_SUSPENDED_WATCHDOG— suspended due to the watchdog triggering 🐕Sys::Virt::Domain::EVENT_SUSPENDED_RESTORED— suspended due to a restore from saved state 💾Sys::Virt::Domain::EVENT_SUSPENDED_API_ERROR— suspended due to an API error 😵💫Sys::Virt::Domain::EVENT_SUSPENDED_POSTCOPY— suspended for post-copy migration 🕓Sys::Virt::Domain::EVENT_SUSPENDED_POSTCOPY_FAILED— suspended due to post-copy migration failing 💔Sys::Virt::Domain::EVENT_SUSPENDED_GUEST_SHUTDOWN— suspended after guest os shut-down — and note that a long running job is preserving the VM until completion 🫶
Sys::Virt::Domain::EVENT_UNDEFINED— the persistent configuration has gone away 🫥Sys::Virt::Domain::EVENT_UNDEFINED_REMOVED— the domain configuration is gone because the administrator removed it 🗑️Sys::Virt::Domain::EVENT_UNDEFINED_RENAMED— the undefined configuration is a rename of an existing configuration ✏️
Sys::Virt::Domain::EVENT_PMSUSPENDED— the domain has stopped running 😴Sys::Virt::Domain::EVENT_PMSUSPENDED_MEMORY— the domain has suspend to RAM 🧠Sys::Virt::Domain::EVENT_PMSUSPENDED_DISK— the domain has suspend to Disk 💿
Sys::Virt::Domain::EVENT_CRASHED— the domain has crashed 💥Sys::Virt::Domain::EVENT_CRASHED_PANICKED— crashed due to a kernel panic 😱Sys::Virt::Domain::EVENT_CRASHED_CRASHLOADED— the domain has crashed and reloaded itself. honestly iconic, it got back up 🔄
✨ EVENT ID CONSTANTS ✨
These are the big category IDs — the vibe check for what kind of event you're looking at 🎫
Sys::Virt::Domain::EVENT_ID_LIFECYCLE— domain lifecycle events 🌱Sys::Virt::Domain::EVENT_ID_REBOOT— soft / warm reboot events 🔁Sys::Virt::Domain::EVENT_ID_RTC_CHANGE— RTC clock adjustments ⏰Sys::Virt::Domain::EVENT_ID_IO_ERROR— file IO errors, typically from disks 🚨Sys::Virt::Domain::EVENT_ID_WATCHDOG— watchdog device triggering 🐕Sys::Virt::Domain::EVENT_ID_GRAPHICS— graphics client connections 🖼️Sys::Virt::Domain::EVENT_ID_IO_ERROR_REASON— file IO errors, typically from disks, but with a root cause 🔍Sys::Virt::Domain::EVENT_ID_CONTROL_ERROR— errors from the virtualization control channel 📡Sys::Virt::Domain::EVENT_ID_BLOCK_JOB— completion status of asynchronous block jobs, identified by source file name 📁Sys::Virt::Domain::EVENT_ID_BLOCK_JOB_2— completion status of asynchronous block jobs, identified by target device name 🎯Sys::Virt::Domain::EVENT_ID_DISK_CHANGE— changes in disk media 💽Sys::Virt::Domain::EVENT_ID_TRAY_CHANGE— CDROM media tray state 📀Sys::Virt::Domain::EVENT_ID_PMSUSPEND— power management initiated suspend to RAM 🔋Sys::Virt::Domain::EVENT_ID_PMSUSPEND_DISK— power management initiated suspend to Disk 💿Sys::Virt::Domain::EVENT_ID_PMWAKEUP— power management initiated wakeup ☀️Sys::Virt::Domain::EVENT_ID_BALLOON_CHANGE— balloon target changes 🎈Sys::Virt::Domain::EVENT_ID_DEVICE_ADDED— asynchronous guest device addition ➕Sys::Virt::Domain::EVENT_ID_DEVICE_REMOVED— asynchronous guest device removal ➖Sys::Virt::Domain::EVENT_ID_TUNABLE— changes of any domain tuning parameters. the callback will be provided with a hash listing all the changed parameters, and the later DOMAIN TUNABLE constants can be super useful when accessing the hash keys 🔧Sys::Virt::Domain::EVENT_ID_AGENT_LIFECYCLE— domain guest agent lifecycle events. the"state"parameter passed to the callback will match one of these constants 👇Sys::Virt::Domain::EVENT_AGENT_LIFECYCLE_STATE_CONNECTED— the agent is now connected 🔌Sys::Virt::Domain::EVENT_AGENT_LIFECYCLE_STATE_DISCONNECTED— the agent is now disconnected 🔌💔
The second parameter, "reason", matches one of the following constants:
Sys::Virt::Domain::EVENT_AGENT_LIFECYCLE_REASON_UNKNOWN— the reason is unknown 🤷Sys::Virt::Domain::EVENT_AGENT_LIFECYCLE_REASON_DOMAIN_STARTED— the domain was initially booted 👟Sys::Virt::Domain::EVENT_AGENT_LIFECYCLE_REASON_CHANNEL— the channel on a running guest changed state 📶
Sys::Virt::Domain::EVENT_ID_MIGRATION_ITERATION— domain migration progress iteration. the"iteration"parameter passed to the callback will specify the number of iterations migration has made over guest RAM 🔂Sys::Virt::Domain::EVENT_ID_JOB_COMPLETED— domain background job completion notification. the callback provides a hash containing the job stats, and the keys in that hash are the same as those used with theSys::Virt::Domain::get_job_stats()method 📊Sys::Virt::Domain::EVENT_ID_DEVICE_REMOVAL_FAILED— guest device removal has failed 😬Sys::Virt::Domain::EVENT_ID_METADATA_CHANGE— the domain metadata has changed 🏷️Sys::Virt::Domain::EVENT_ID_BLOCK_THRESHOLD— fires when the hypervisor detects that the given storage element was written beyond the point specified by threshold. genuinely so useful for thin-provisioned storage 👑📦Sys::Virt::Domain::EVENT_ID_MEMORY_FAILURE— fires when the hypervisor detects hardware memory corruption 💀Sys::Virt::Domain::EVENT_ID_MEMORY_DEVICE_SIZE_CHANGE— fires when the guest accepts a request to change the memory device size 📏Sys::Virt::Domain::EVENT_ID_NIC_MAC_CHANGE— fires when the guest changes the MAC address on one of its virtual network interfaces 🪪Sys::Virt::Domain::EVENT_ID_VCPU_REMOVED— fires when a vCPU is removed from the domain 🧩Sys::Virt::Domain::EVENT_ID_CHANNEL_LIFECYCLE— domain channel lifecycle events. the"state"parameter passed to the callback will match one of these constants 👇Sys::Virt::Domain::EVENT_CHANNEL_LIFECYCLE_STATE_CONNECTED— the channel is now connected 🔗Sys::Virt::Domain::EVENT_CHANNEL_LIFECYCLE_STATE_DISCONNECTED— the channel is now disconnected ✂️
The second parameter, "reason", matches one of the following constants:
Sys::Virt::Domain::EVENT_CHANNEL_LIFECYCLE_REASON_UNKNOWN— the reason is unknown 🤷Sys::Virt::Domain::EVENT_CHANNEL_LIFECYCLE_REASON_DOMAIN_STARTED— the domain was initially booted 👟Sys::Virt::Domain::EVENT_CHANNEL_LIFECYCLE_REASON_CHANNEL— the channel on a running guest changed state 📶
🚨 IO ERROR EVENT CONSTANTS 🚨
These constants describe what action was taken due to the IO error. like, what did we do about it 💅
Sys::Virt::Domain::EVENT_IO_ERROR_NONE— no action was taken; the error was ignored & reported as success to the guest 🙈Sys::Virt::Domain::EVENT_IO_ERROR_PAUSE— the guest is paused since the error occurred ⏸️Sys::Virt::Domain::EVENT_IO_ERROR_REPORT— the error has been reported to the guest OS 📣
🐕 WATCHDOG EVENT CONSTANTS 🐕
These constants describe what action was taken due to the watchdog firing. the dog barked, now what 🔔
Sys::Virt::Domain::EVENT_WATCHDOG_NONE— no action was taken, the watchdog was ignored 🫥Sys::Virt::Domain::EVENT_WATCHDOG_PAUSE— the guest is paused since the watchdog fired ⏸️Sys::Virt::Domain::EVENT_WATCHDOG_POWEROFF— the guest is powered off after the watchdog fired 🔌Sys::Virt::Domain::EVENT_WATCHDOG_RESET— the guest is reset after the watchdog fired 🔄Sys::Virt::Domain::EVENT_WATCHDOG_SHUTDOWN— the guest tried to gracefully shut down after the watchdog fired 💅Sys::Virt::Domain::EVENT_WATCHDOG_DEBUG— no action was taken, the watchdog was logged 👀Sys::Virt::Domain::EVENT_WATCHDOG_INJECTNMI— an NMI was injected into the guest after the watchdog fired 💥
🎨 GRAPHICS EVENT PHASE CONSTANTS 🎨
These constants describe the phase of the graphics connection, bestie 🖼️
Sys::Virt::Domain::EVENT_GRAPHICS_CONNECT— the initial client connection ✨Sys::Virt::Domain::EVENT_GRAPHICS_INITIALIZE— the client has been authenticated & the connection is running 💫Sys::Virt::Domain::EVENT_GRAPHICS_DISCONNECT— the client has disconnected 👋
🌐 GRAPHICS EVENT ADDRESS CONSTANTS 🌐
These constants describe the format of the address 🧚
Sys::Virt::Domain::EVENT_GRAPHICS_ADDRESS_IPV4— an IPv4 address 🌈Sys::Virt::Domain::EVENT_GRAPHICS_ADDRESS_IPV6— an IPv6 address ⭐Sys::Virt::Domain::EVENT_GRAPHICS_ADDRESS_UNIX— an UNIX socket path address 🦋
💽 DISK CHANGE EVENT CONSTANTS 💽
These constants describe the reason for a disk change event 🎀
Sys::Virt::Domain::EVENT_DISK_CHANGE_MISSING_ON_START— the disk media was cleared, as its source was missing when attempting to start the guest 😭Sys::Virt::Domain::EVENT_DISK_DROP_MISSING_ON_START— the disk device was dropped, as its source was missing when attempting to start the guest 💀
🎬 TRAY CHANGE CONSTANTS 🎬
These constants describe the reason for a tray change event 🍓
Sys::Virt::Domain::EVENT_TRAY_CHANGE_CLOSE— the tray was closed 🫶Sys::Virt::Domain::EVENT_TRAY_CHANGE_OPEN— the tray was opened ✨
🛠️ DOMAIN BLOCK JOB TYPE CONSTANTS 🛠️
The following constants identify the different types of domain block jobs 🧰
Sys::Virt::Domain::BLOCK_JOB_TYPE_UNKNOWN— an unknown block job type 🙈Sys::Virt::Domain::BLOCK_JOB_TYPE_PULL— the block pull job type 💅Sys::Virt::Domain::BLOCK_JOB_TYPE_COPY— the block copy job type 🎀Sys::Virt::Domain::BLOCK_JOB_TYPE_COMMIT— the block commit job type 🔥Sys::Virt::Domain::BLOCK_JOB_TYPE_ACTIVE_COMMIT— the block active commit job type ⭐Sys::Virt::Domain::BLOCK_JOB_TYPE_BACKUP— the block backup job type 💾
✅ DOMAIN BLOCK JOB COMPLETION CONSTANTS ✅
The following constants can be used to determine the completion status of a block job 👑
Sys::Virt::Domain::BLOCK_JOB_COMPLETED— a successfully completed block job 🎉Sys::Virt::Domain::BLOCK_JOB_FAILED— an unsuccessful block job 😭Sys::Virt::Domain::BLOCK_JOB_CANCELED— a block job canceled by the user 🛑Sys::Virt::Domain::BLOCK_JOB_READY— a block job is running 🏃♀️
🔁 DOMAIN BLOCK REBASE CONSTANTS 🔁
The following constants are useful when rebasing block devices 🧚
Sys::Virt::Domain::BLOCK_REBASE_SHALLOW— limit copy to top of source backing chain ✂️Sys::Virt::Domain::BLOCK_REBASE_REUSE_EXT— reuse existing external file for copy 🫶Sys::Virt::Domain::BLOCK_REBASE_COPY_RAW— make destination file raw 🧱Sys::Virt::Domain::BLOCK_REBASE_COPY— start a copy job 🚀Sys::Virt::Domain::BLOCK_REBASE_COPY_DEV— treat destination as a block device instead of file 💽Sys::Virt::Domain::BLOCK_REBASE_RELATIVE— keep backing chain referenced using relative names 🔗
📋 DOMAIN BLOCK COPY CONSTANTS 📋
The following constants are useful when copying block devices 🖇️
Sys::Virt::Domain::BLOCK_COPY_SHALLOW— limit copy to top of source backing chain ✂️Sys::Virt::Domain::BLOCK_COPY_REUSE_EXT— reuse existing external file for copy ♻️Sys::Virt::Domain::BLOCK_COPY_TRANSIENT_JOB— don’t force usage of recoverable job for the copy operation 🫧Sys::Virt::Domain::BLOCK_COPY_SYNCHRONOUS_WRITES— force the copy job to synchronously propagate guest writes into the destination image, so that the copy is guaranteed to converge ⚡Sys::Virt::Domain::BLOCK_COPY_TARGET_ZEROED— the target image is guaranteed to be pre-zeroed so all reads will return zeros 🌟
🛑 DOMAIN BLOCK JOB ABORT CONSTANTS 🛑>
The following constants are useful when aborting job copy jobs 🚨
Sys::Virt::Domain::BLOCK_JOB_ABORT_ASYNC— request only, do not wait for completion ⏩Sys::Virt::Domain::BLOCK_JOB_ABORT_PIVOT— pivot to mirror when ending a copy job 🔄
🧷 DOMAIN BLOCK COMMIT JOB CONSTANTS 🧷
The following constants are useful with block commit job types 🧵
Sys::Virt::Domain::BLOCK_COMMIT_DELETE— delete any files that are invalid after commit 🗑️Sys::Virt::Domain::BLOCK_COMMIT_SHALLOW— NULL base means next backing file, not whole chain 🪄Sys::Virt::Domain::BLOCK_COMMIT_ACTIVE— allow two phase commit when top is active layer 🎭Sys::Virt::Domain::BLOCK_COMMIT_RELATIVE— keep backing chain referenced using relative names 🔗
💾 DOMAIN SAVE / RESTORE FLAG CONSTANTS 💾
The following constants can be used when saving or restoring virtual machines 🖥️
Sys::Virt::Domain::SAVE_BYPASS_CACHE— do not use OS I/O cache when saving state. 🚫Sys::Virt::Domain::SAVE_PAUSED— mark the saved state as paused to prevent the guest CPUs starting upon restore ⏸️Sys::Virt::Domain::SAVE_RUNNING— mark the saved state as running to allow the guest CPUs to start upon restore ▶️Sys::Virt::Domain::SAVE_RESET_NVRAM— reset the firmware NVRAM state from its original template 🔄
📦 SAVE / RESTORE PARAMETER CONSTANTS 📦
Sys::Virt::Domain::SAVE_PARAM_FILE— specify the save state file to save to or restore from. 📁Sys::Virt::Domain::SAVE_PARAM_DXML— used to adjust guest xml on restore, e.g. to alter a device while domain is stopped. 📝Sys::Virt::Domain::SAVE_PARAM_IMAGE_FORMAT— specify the save state image format. This can be one of the following constant values 🖼️Sys::Virt::Domain::SAVE_PARAM_IMAGE_FORMAT_RAW— uncompressed raw image 🧱Sys::Virt::Domain::SAVE_PARAM_IMAGE_FORMAT_GZIP— image compressed with gzip 🗜️Sys::Virt::Domain::SAVE_PARAM_IMAGE_FORMAT_BZIP2— image compressed with bzip2 🗜️Sys::Virt::Domain::SAVE_PARAM_IMAGE_FORMAT_XZ— image compressed with xz 🗜️Sys::Virt::Domain::SAVE_PARAM_IMAGE_FORMAT_LZOP— image compressed with lzop 🗜️Sys::Virt::Domain::SAVE_PARAM_IMAGE_FORMAT_ZSTD— image compressed with zstd 🗜️Sys::Virt::Domain::SAVE_PARAM_IMAGE_FORMAT_SPARSE— uncompressed sparse image 🌫️
Sys::Virt::Domain::SAVE_PARAM_PARALLEL_CHANNELS— specify the number of IO channels to use during parallel save or restore. 🔀
🧠 DOMAIN CORE DUMP CONSTANTS 🧠
The following constants can be used when triggering domain core dumps 💥
Sys::Virt::Domain::DUMP_LIVE— do not pause execution while dumping the guest 🏃♀️Sys::Virt::Domain::DUMP_CRASH— crash the guest after completing the core dump 💀Sys::Virt::Domain::DUMP_BYPASS_CACHE— do not use OS I/O cache when writing core dump 🚫Sys::Virt::Domain::DUMP_RESET— reset the virtual machine after finishing the dump 🔄Sys::Virt::Domain::DUMP_MEMORY_ONLY— only include guest RAM in the dump, not the device state 🧩
💣 DESTROY CONSTANTS 💣
The following constants are useful when terminating guests using the "destroy" API. 🫡
Sys::Virt::Domain::DESTROY_DEFAULT— destroy the guest using the default approach 🧨Sys::Virt::Domain::DESTROY_GRACEFUL— destroy the guest in a graceful manner 🕊️Sys::Virt::Domain::DESTROY_REMOVE_LOGS— delete log files associated with the guest 🗑️
🛑 SHUTDOWN CONSTANTS 🛑
The following constants are useful when requesting that a guest terminate using the "shutdown" API 🔌
Sys::Virt::Domain::SHUTDOWN_DEFAULT— shutdown using the hypervisor’s default mechanism ⚙️Sys::Virt::Domain::SHUTDOWN_GUEST_AGENT— shutdown by issuing a command to a guest agent 🤖Sys::Virt::Domain::SHUTDOWN_ACPI_POWER_BTN— shutdown by injecting an ACPI power button press 🔘Sys::Virt::Domain::SHUTDOWN_INITCTL— shutdown by talking to initctl (containers only) 📦Sys::Virt::Domain::SHUTDOWN_SIGNAL— shutdown by sending SIGTERM to the init process 📶Sys::Virt::Domain::SHUTDOWN_PARAVIRT— shutdown by issuing a paravirt power control command 🪄
🔄 REBOOT CONSTANTS 🔄
The following constants are useful when requesting that a guest terminate using the "reboot" API 🌀
Sys::Virt::Domain::REBOOT_DEFAULT— reboot using the hypervisor’s default mechanism ⚙️Sys::Virt::Domain::REBOOT_GUEST_AGENT— reboot by issuing a command to a guest agent 🤖Sys::Virt::Domain::REBOOT_ACPI_POWER_BTN— reboot by injecting an ACPI power button press 🔘Sys::Virt::Domain::REBOOT_INITCTL— reboot by talking to initctl (containers only) 📦Sys::Virt::Domain::REBOOT_SIGNAL— reboot by sending SIGHUP to the init process 📶Sys::Virt::Domain::REBOOT_PARAVIRT— reboot by issuing a paravirt power control command 🪄
🏷️ METADATA CONSTANTS 🏷️
The following constants are useful when reading/writing metadata about a guest 📝
Sys::Virt::Domain::METADATA_TITLE— the short human friendly title of the guest ✨Sys::Virt::Domain::METADATA_DESCRIPTION— the long free text description of the guest 📜Sys::Virt::Domain::METADATA_ELEMENT— the structured metadata elements for the guest 🧩
⚠️ DISK ERROR CONSTANTS ⚠️
The following constants are useful when interpreting disk error codes 🧐
Sys::Virt::Domain::DISK_ERROR_NONE— no error ✅Sys::Virt::Domain::DISK_ERROR_NO_SPACE— the host storage has run out of free space 😭Sys::Virt::Domain::DISK_ERROR_UNSPEC— an unspecified error has occurred. ❓
📊 MEMORY STATISTIC CONSTANTS 📊
Sys::Virt::Domain::MEMORY_STAT_SWAP_IN— swap in 🔁Sys::Virt::Domain::MEMORY_STAT_SWAP_OUT— swap out 🔁Sys::Virt::Domain::MEMORY_STAT_MINOR_FAULT— minor faults 🪶Sys::Virt::Domain::MEMORY_STAT_MAJOR_FAULT— major faults 🧱Sys::Virt::Domain::MEMORY_STAT_RSS— resident memory 🏠Sys::Virt::Domain::MEMORY_STAT_UNUSED— unused memory 🫧Sys::Virt::Domain::MEMORY_STAT_AVAILABLE— available memory 🟢Sys::Virt::Domain::MEMORY_STAT_ACTUAL_BALLOON— actual balloon limit 🎈Sys::Virt::Domain::MEMORY_STAT_USABLE— amount of usable memory 🧠Sys::Virt::Domain::MEMORY_STAT_LAST_UPDATE— time of last stats refresh from guest 🕒Sys::Virt::Domain::MEMORY_STAT_DISK_CACHES— disk cache size 💽Sys::Virt::Domain::MEMORY_STAT_HUGETLB_PGALLOC— the amount of successful huge page allocations 🐘Sys::Virt::Domain::MEMORY_STAT_HUGETLB_PGFAIL— the amount of failed huge page allocations 💔
📝 DOMAIN LIST CONSTANTS 📝
The following constants can be used when listing domains 🗂️
Sys::Virt::Domain::LIST_ACTIVE— only list domains that are currently active (running, or paused) 🏃♀️Sys::Virt::Domain::LIST_AUTOSTART— only list domains that are set to automatically start on boot 🚀Sys::Virt::Domain::LIST_HAS_SNAPSHOT— filters to only the domains that have a stored snapshot 📸Sys::Virt::Domain::LIST_INACTIVE— filters to only the domains that are currently inactive (shutoff, saved) 😴Sys::Virt::Domain::LIST_MANAGEDSAVE— filters to only the domains that currently have a managed save state 💾Sys::Virt::Domain::LIST_NO_AUTOSTART— filters to only the domains that are not set to automatically start on boto 🥾 (yes bestie, "boto" — that's literally what the source says, it means boot, we love a typo that ate)Sys::Virt::Domain::LIST_NO_MANAGEDSAVE— filters to only the domains that have no managed save state at all 🚫Sys::Virt::Domain::LIST_NO_SNAPSHOT— filters to only the domains with no stored snapshot 🙅♀️Sys::Virt::Domain::LIST_OTHER— filters to only the domains that are not running, paused or shutoff 👻Sys::Virt::Domain::LIST_PAUSED— filters to only the domains that are paused ⏸️Sys::Virt::Domain::LIST_PERSISTENT— filters to only the domains that have a persistent config 📌Sys::Virt::Domain::LIST_RUNNING— filters to only the domains that are currently running 🏃♀️Sys::Virt::Domain::LIST_SHUTOFF— filters to only the domains that are currently shutoff 🔌Sys::Virt::Domain::LIST_TRANSIENT— filters to only the domains that do not have a persistent config 🫧Sys::Virt::Domain::LIST_HAS_CHECKPOINT— filters to only the domains that have a stored checkpoint ✅Sys::Virt::Domain::LIST_NO_CHECKPOINT— filters to only the domains that do not have a stored checkpoint ❌
🔑 SEND KEY CONSTANTS 🔑
These next ones are literally only for the send_key API, iykyk:
Sys::Virt::Domain::SEND_KEY_MAX_KEYS— the maximum number of keys you can send in a single call tosend_key⌨️ (so like, don't go over it, the API said what it said)
📊 BLOCK STATS CONSTANTS 📊
These give you the names of the well known block stats fields 🧾:
Sys::Virt::Domain::BLOCK_STATS_ERRS— the number of I/O errors 💀Sys::Virt::Domain::BLOCK_STATS_FLUSH_REQ— the number of flush requests 🚽Sys::Virt::Domain::BLOCK_STATS_FLUSH_TOTAL_TIMES— the time spent processing flush requests ⏱️Sys::Virt::Domain::BLOCK_STATS_READ_BYTES— the amount of data read 📖Sys::Virt::Domain::BLOCK_STATS_READ_REQ— the number of read requests 🗂️Sys::Virt::Domain::BLOCK_STATS_READ_TOTAL_TIMES— the time spent processing read requests ⏳Sys::Virt::Domain::BLOCK_STATS_WRITE_BYTES— the amount of data written ✍️Sys::Virt::Domain::BLOCK_STATS_WRITE_REQ— the number of write requests 📝Sys::Virt::Domain::BLOCK_STATS_WRITE_TOTAL_TIMES— the time spent processing write requests 🕰️
🧠 CPU STATS CONSTANTS 🧠
The names of the well known cpu stats fields, iconic behaviour:
Sys::Virt::Domain::CPU_STATS_CPUTIME— the total CPU time, including both hypervisor and vCPU time 🧮Sys::Virt::Domain::CPU_STATS_USERTIME— ok so the source literally says "THe total time in kernel" for this one 🙈 (capital T and everything, and yeah it's describing kernel time under the *user*time constant — I'm not fixing it, I'm just reporting it, bestie)Sys::Virt::Domain::CPU_STATS_SYSTEMTIME— and this one says "The total time in userspace" 🌀 (same energy — swapped descriptions, and honestly? we're just gonna sit with that)Sys::Virt::Domain::CPU_STATS_VCPUTIME— the total vCPU time ⚡
🧠 CPU STATS CONSTANTS 🧠
Not a glitch, not me repeating myself — the page literally has this heading twice 😭 but the vibe this time is schedular parameters (spelling theirs, not mine) 🌈:
Sys::Virt::SCHEDULER_EMULATOR_PERIOD— the duration of the time period for scheduling the emulator ⏲️Sys::Virt::SCHEDULER_EMULATOR_QUOTA— the quota for the emulator in one schedular time period 📏Sys::Virt::SCHEDULER_IOTHREAD_PERIOD— the duration of the time period for scheduling the iothread 🧵Sys::Virt::SCHEDULER_IOTHREAD_QUOTA— the quota for the iothread in one schedular time period 📐
🚩 DOMAIN STATS FLAG CONSTANTS 🚩
These are the flags you pass when requesting bulk domain stats from Sys::Virt::get_all_domain_stats 🎯:
Sys::Virt::Domain::GET_ALL_STATS_ACTIVE— include stats for active domains 🟢Sys::Virt::Domain::GET_ALL_STATS_INACTIVE— include stats for inactive domains 🔴Sys::Virt::Domain::GET_ALL_STATS_OTHER— include stats for other domains 👽Sys::Virt::Domain::GET_ALL_STATS_PAUSED— include stats for paused domains ⏸️Sys::Virt::Domain::GET_ALL_STATS_PERSISTENT— include stats for persistent domains 📌Sys::Virt::Domain::GET_ALL_STATS_RUNNING— include stats for running domains 🏃Sys::Virt::Domain::GET_ALL_STATS_SHUTOFF— include stats for shutoff domains 🔌Sys::Virt::Domain::GET_ALL_STATS_TRANSIENT— include stats for transient domains 🫧Sys::Virt::Domain::GET_ALL_STATS_ENFORCE_STATS— require that all requested stats fields are returned 😤 no half-measuresSys::Virt::Domain::GET_ALL_STATS_BACKING— get stats for image backing files too 🗄️Sys::Virt::Domain::GET_ALL_STATS_NOWAIT— skip stats if they can't be acquired without waiting ⏭️ (impatient queen energy)
🎛️ DOMAIN STATS FIELD CONSTANTS 🎛️
These control which fields come back on a stats query 🎚️:
🎈 Sys::Virt::Domain::STATS_BALLOON
Balloon statistics. The following keys will be used for the returned parameters:
Sys::Virt::Domain::STATS_BALLOON_CURRENT— the memory in kiB currently used, asunsigned long long🧮Sys::Virt::Domain::STATS_BALLOON_MAXIMUM— the maximum memory in kiB allowed, asunsigned long long🔝Sys::Virt::Domain::STATS_BALLOON_SWAP_IN— the amount of data read from swap space (in KiB), asunsigned long long📥Sys::Virt::Domain::STATS_BALLOON_SWAP_OUT— the amount of memory written out to swap space (in KiB), asunsigned long📤 (note: plainunsigned longhere, notlong long— that's how it's written)Sys::Virt::Domain::STATS_BALLOON_MAJOR_FAULT— the number of page faults when disk IO was required, asunsigned long long💥Sys::Virt::Domain::STATS_BALLOON_MINOR_FAULT— the number of other page faults, asunsigned long long🩹Sys::Virt::Domain::STATS_BALLOON_UNUSED— the amount of memory left unused by the system (in KiB), asunsigned long🫙Sys::Virt::Domain::STATS_BALLOON_AVAILABLE— the amount of usable memory as seen by the domain (in KiB), asunsigned long🧺Sys::Virt::Domain::STATS_BALLOON_RSS— Resident Set Size of running domain's process (in KiB), asunsigned long long🧠Sys::Virt::Domain::STATS_BALLOON_USABLE— the amount of memory which can be reclaimed by balloon without causing host swapping (in KiB), asunsigned long long🎈Sys::Virt::Domain::STATS_BALLOON_LAST_UPDATE— timestamp of the last update of statistics (in seconds), asunsigned long long🕒Sys::Virt::Domain::STATS_BALLOON_DISK_CACHES— the amount of memory that can be reclaimed without additional I/O, typically disk (in KiB), asunsigned long long💽Sys::Virt::Domain::STATS_BALLOON_HUGETLB_PGALLOC— the number of successful huge page allocations from inside the domain via virtio balloon, asunsigned long long🐘✅Sys::Virt::Domain::STATS_BALLOON_HUGETLB_PGFAIL— the number of failed huge page allocations from inside the domain via virtio balloon, asunsigned long long🐘❌
💽 Sys::Virt::Domain::STATS_BLOCK
Block device info. The following keys will be used for the returned parameters:
Sys::Virt::Domain::STATS_BLOCK_COUNT— number of block devices in the subsequent list, asunsigned int🔢Sys::Virt::Domain::STATS_BLOCK_PREFIX— the parameter name prefix to access each disk entry. Concatenate the prefix, the entry number formatted as an unsigned integer and one of the block suffix parameters to form a complete parameter name 🧩 (build-a-param workshop, we love to see it)Sys::Virt::Domain::STATS_BLOCK_SUFFIX_NAME— name of the block device as string. Matches the target name (vda/sda/hda) of the block device. If the backing chain is listed, this name is the same for all host resources tied to the same guest device 🏷️Sys::Virt::Domain::STATS_BLOCK_SUFFIX_BACKINGINDEX— the<backingStore>index asunsigned int, only used when backing images are listed 🗂️Sys::Virt::Domain::STATS_BLOCK_SUFFIX_PATH— source of the block device as a string, if it is a file or block device (omitted for network sources and drives with no media inserted) 📁Sys::Virt::Domain::STATS_BLOCK_SUFFIX_RD_REQS— number of read requests, asunsigned long long📖Sys::Virt::Domain::STATS_BLOCK_SUFFIX_RD_BYTES— number of read bytes, asunsigned long long📊Sys::Virt::Domain::STATS_BLOCK_SUFFIX_RD_TIMES— total time (ns) spent on reads, asunsigned long long⏱️Sys::Virt::Domain::STATS_BLOCK_SUFFIX_WR_REQS— number of write requests, asunsigned long long✍️Sys::Virt::Domain::STATS_BLOCK_SUFFIX_WR_BYTES— number of written bytes, asunsigned long long📈Sys::Virt::Domain::STATS_BLOCK_SUFFIX_WR_TIMES— total time (ns) spent on writes, asunsigned long long⏳Sys::Virt::Domain::STATS_BLOCK_SUFFIX_FL_REQS— total flush requests, asunsigned long long🚽Sys::Virt::Domain::STATS_BLOCK_SUFFIX_FL_TIMES— total time (ns) spent on cache flushing, asunsigned long long🧼Sys::Virt::Domain::STATS_BLOCK_SUFFIX_ERRORS— Xen only: the'oo_req'value, asunsigned long long💀Sys::Virt::Domain::STATS_BLOCK_SUFFIX_ALLOCATION— offset of the highest written sector, asunsigned long long📍Sys::Virt::Domain::STATS_BLOCK_SUFFIX_CAPACITY— logical size in bytes of the block device backing image, asunsigned long📦 (yep, plainunsigned long)Sys::Virt::Domain::STATS_BLOCK_SUFFIX_PHYSICAL— physical size in bytes of the container of the backing image, asunsigned long long🧱Sys::Virt::Domain::STATS_BLOCK_SUFFIX_THRESHOLD— current threshold for delivering theVIR_DOMAIN_EVENT_ID_BLOCK_THRESHOLDevent in bytes, asunsigned long long. SeevirDomainSetBlockThreshold🚨Sys::Virt::Domain::STATS_BLOCK_SUFFIX_LIMITS_DISCARD_ALIGNMENT— alignment for discard requests in bytes, asunsigned long long📏Sys::Virt::Domain::STATS_BLOCK_SUFFIX_LIMITS_DISCARD_MAX— alignment for discard requests in bytes, asunsigned long long🔁 (yeah, it says alignment again, same words as the one above — I'm reporting, not adjudicating, bestie)Sys::Virt::Domain::STATS_BLOCK_SUFFIX_LIMITS_IOV_HW_MAX— maximal number of scatter/gather elements of requests bypassing kernel IO scheduler, asunsigned long long🚀Sys::Virt::Domain::STATS_BLOCK_SUFFIX_LIMITS_IOV_MAX— maximum number of scatter/gather elements, asunsigned long long🎚️Sys::Virt::Domain::STATS_BLOCK_SUFFIX_LIMITS_MEMORY_ALIGNMENT_MINIMAL— memory alignment in bytes so that no bounce buffer is needed, asunsigned long long🧷Sys::Virt::Domain::STATS_BLOCK_SUFFIX_LIMITS_MEMORY_ALIGNMENT_OPTIMAL— memory alignment in bytes that is used for bounce buffers, asunsigned long long🎯Sys::Virt::Domain::STATS_BLOCK_SUFFIX_LIMITS_REQUEST_ALIGNMENT— alignment requirement, in bytes, for offset/length of I/O requests, asunsigned long long📐
okay bestie, we're still in the block-stat suffix constants and they are long, but every single one is here so nobody has to guess 💅✨
Sys::Virt::Domain::STATS_BLOCK_SUFFIX_LIMITS_TRANSFER_HW_MAX— max hardware transfer length, in bytes, for requests that bypass the kernel IO scheduler; type isunsigned long long.Sys::Virt::Domain::STATS_BLOCK_SUFFIX_LIMITS_TRANSFER_MAX— max transfer length, in bytes; type isunsigned long long.Sys::Virt::Domain::STATS_BLOCK_SUFFIX_LIMITS_TRANSFER_OPTIMAL— optimal transfer length, in bytes; type isunsigned long long.Sys::Virt::Domain::STATS_BLOCK_SUFFIX_LIMITS_WRITE_ZEROES_ALIGNMENT— optimal alignment forwrite_zeroesrequests, in bytes; type isunsigned long long.Sys::Virt::Domain::STATS_BLOCK_SUFFIX_LIMITS_WRITE_ZEROES_MAX— max number of bytes that can be zeroed out at once; type isunsigned long long.Sys::Virt::Domain::STATS_BLOCK_SUFFIX_TIMED_GROUP_COUNT— number of groups of statistics accounted in configured time intervals; type isunsigned long long.Sys::Virt::Domain::STATS_BLOCK_SUFFIX_TIMED_GROUP_PREFIX— the parameter-name prefix for each group of timed stats. Concatenate this prefix, the entry number formatted as an unsigned integer, and one of the timed-group suffix params to make a complete parameter name 🫶Sys::Virt::Domain::STATS_BLOCK_SUFFIX_TIMED_GROUP_SUFFIX_FLUSH_LATENCY_AVG— average latency of flush operations in the defined interval, in nanoseconds; type isunsigned long long.Sys::Virt::Domain::STATS_BLOCK_SUFFIX_TIMED_GROUP_SUFFIX_FLUSH_LATENCY_MAX— maximum latency of flush operations in the defined interval, in nanoseconds; type isunsigned long long.Sys::Virt::Domain::STATS_BLOCK_SUFFIX_TIMED_GROUP_SUFFIX_FLUSH_LATENCY_MIN— minimum latency of flush operations in the defined interval, in nanoseconds; type isunsigned long long.Sys::Virt::Domain::STATS_BLOCK_SUFFIX_TIMED_GROUP_SUFFIX_INTERVAL— the time interval in seconds, asunsigned long long, for which the stats in this group were collected.Sys::Virt::Domain::STATS_BLOCK_SUFFIX_TIMED_GROUP_SUFFIX_RD_LATENCY_AVG— average latency of read operations in the defined interval, in nanoseconds; type isunsigned long long.Sys::Virt::Domain::STATS_BLOCK_SUFFIX_TIMED_GROUP_SUFFIX_RD_LATENCY_MAX— maximum latency of read operations in the defined interval, in nanoseconds; type isunsigned long long.Sys::Virt::Domain::STATS_BLOCK_SUFFIX_TIMED_GROUP_SUFFIX_RD_LATENCY_MIN— minimum latency of read operations in the defined interval, in nanoseconds; type isunsigned long long.Sys::Virt::Domain::STATS_BLOCK_SUFFIX_TIMED_GROUP_SUFFIX_RD_QUEUE_DEPTH_AVG— average number of pending read operations in the defined interval; type isdouble.Sys::Virt::Domain::STATS_BLOCK_SUFFIX_TIMED_GROUP_SUFFIX_WR_LATENCY_AVG— average latency of write operations in the defined interval, in nanoseconds; type isunsigned long long.Sys::Virt::Domain::STATS_BLOCK_SUFFIX_TIMED_GROUP_SUFFIX_WR_LATENCY_MAX— maximum latency of write operations in the defined interval, in nanoseconds; type isunsigned long long.Sys::Virt::Domain::STATS_BLOCK_SUFFIX_TIMED_GROUP_SUFFIX_WR_LATENCY_MIN— minimum latency of write operations in the defined interval, in nanoseconds; type isunsigned long long.Sys::Virt::Domain::STATS_BLOCK_SUFFIX_TIMED_GROUP_SUFFIX_WR_QUEUE_DEPTH_AVG— average number of pending write operations in the defined interval; type isdouble.Sys::Virt::Domain::STATS_BLOCK_SUFFIX_TIMED_GROUP_SUFFIX_ZONE_APPEND_LATENCY_AVG— average latency of zone append operations in the defined interval, in nanoseconds; type isunsigned long long.Sys::Virt::Domain::STATS_BLOCK_SUFFIX_TIMED_GROUP_SUFFIX_ZONE_APPEND_LATENCY_MAX— maximum latency of zone append operations in the defined interval, in nanoseconds; type isunsigned long long.Sys::Virt::Domain::STATS_BLOCK_SUFFIX_TIMED_GROUP_SUFFIX_ZONE_APPEND_LATENCY_MIN— minimum latency of zone append operations in the defined interval, in nanoseconds; type isunsigned long long.Sys::Virt::Domain::STATS_BLOCK_SUFFIX_TIMED_GROUP_SUFFIX_ZONE_APPEND_QUEUE_DEPTH_AVG— average number of pending zone append operations in the defined interval; type isdouble.Sys::Virt::Domain::STATS_BLOCK_SUFFIX_LATENCY_HISTOGRAM_FLUSH_PREFIX— the parameter-name prefix for'flush'latency histograms.Sys::Virt::Domain::STATS_BLOCK_SUFFIX_LATENCY_HISTOGRAM_READ_PREFIX— the parameter-name prefix for'read'latency histograms.Sys::Virt::Domain::STATS_BLOCK_SUFFIX_LATENCY_HISTOGRAM_WRITE_PREFIX— the parameter-name prefix for'write'latency histograms.Sys::Virt::Domain::STATS_BLOCK_SUFFIX_LATENCY_HISTOGRAM_ZONE_APPEND_PREFIX— the parameter-name prefix for'zone_append'latency histograms.Sys::Virt::Domain::STATS_BLOCK_SUFFIX_LATENCY_HISTOGRAM_SUFFIX_BIN_COUNT— the parameter-name suffix for the number of bins in the histogram stats.Sys::Virt::Domain::STATS_BLOCK_SUFFIX_LATENCY_HISTOGRAM_SUFFIX_BIN_PREFIX— the parameter-name suffix for a latency histogram bin.Sys::Virt::Domain::STATS_BLOCK_SUFFIX_LATENCY_HISTOGRAM_SUFFIX_BIN_SUFFIX_START— start of the current latency histogram bin, in nanoseconds.Sys::Virt::Domain::STATS_BLOCK_SUFFIX_LATENCY_HISTOGRAM_SUFFIX_BIN_SUFFIX_VALUE— current value for the number of occurrences of latency within this bin.
Sys::Virt::Domain::STATS_CPU_TOTAL — CPU usage info 💖 the following keys are the ones used for the returned parameters:
Sys::Virt::Domain::STATS_CPU_TIME— total CPU time spent for this domain, in nanoseconds; type isunsigned long long.Sys::Virt::Domain::STATS_CPU_USER— user CPU time spent, in nanoseconds; type isunsigned long long.Sys::Virt::Domain::STATS_CPU_SYSTEM— system CPU time spent, in nanoseconds; type isunsigned long long.Sys::Virt::Domain::STATS_CPU_HALTPOLL_SUCCESS_TIME— halt-polling CPU usage for the VCPU polled until a virtual interrupt was delivered, in nanoseconds; type isunsigned long long.Sys::Virt::Domain::STATS_CPU_HALTPOLL_FAIL_TIME— halt-polling CPU usage for when the VCPU had to schedule out (either because the max poll time was reached or it needed to yield the CPU), in nanoseconds; type isunsigned long long.Sys::Virt::Domain::STATS_CPU_CACHE_MONITOR_COUNT— number of cache monitors for this domain; type isunsigned int.Sys::Virt::Domain::STATS_CPU_CACHE_MONITOR_PREFIX— parameter-name prefix for each cache monitor entry. Concatenate this prefix, the entry number formatted as an unsigned integer, and one of the cache-monitor suffix params to make a complete parameter name.Sys::Virt::Domain::STATS_CPU_CACHE_MONITOR_SUFFIX_NAME— name of the cache monitor; type isstring.Sys::Virt::Domain::STATS_CPU_CACHE_MONITOR_SUFFIX_VCPUS— Vcpu list of the cache monitor; type isstring.Sys::Virt::Domain::STATS_CPU_CACHE_MONITOR_SUFFIX_BANK_COUNT— number of cache banks in the cache monitor; type isunsigned int.Sys::Virt::Domain::STATS_CPU_CACHE_MONITOR_SUFFIX_BANK_PREFIX— parameter-name prefix for each cache monitor bank entry. Concatenate the cache monitor prefix, the cache monitor entry number formatted as an unsigned integer, the bank prefix, the bank entry number formatted as an unsigned integer, and one of the cache monitor bank suffix params to make a complete parameter name ✨Sys::Virt::Domain::STATS_CPU_CACHE_MONITOR_SUFFIX_BANK_SUFFIX_ID— host-allocated cache id for the bank; type isunsigned int.Sys::Virt::Domain::STATS_CPU_CACHE_MONITOR_SUFFIX_BANK_SUFFIX_BYTES— number of bytes of last level cache that the domain is using; type isunsigned long long.Sys::Virt::Domain::STATS_CPU_ENERGY_MONITOR_COUNT— number of energy monitors for this domain; type isunsigned int.Sys::Virt::Domain::STATS_CPU_ENERGY_MONITOR_PREFIX— prefix for an individual energy monitor group. Concatenate it with the monitor index and one of the"cpu.energy.monitor.<i>."suffix constants below to make a full parameter name.Sys::Virt::Domain::STATS_CPU_ENERGY_MONITOR_SUFFIX_NAME— name of the monitor group; type isstring.Sys::Virt::Domain::STATS_CPU_ENERGY_MONITOR_SUFFIX_VCPUS— vCPU set covered by the monitor group; type isstring.Sys::Virt::Domain::STATS_CPU_ENERGY_MONITOR_SUFFIX_PKG_COUNT— number ofPERF_PKGnodes the monitor group exposes; type isunsigned int.Sys::Virt::Domain::STATS_CPU_ENERGY_MONITOR_SUFFIX_PKG_PREFIX— prefix for a singlemon_PERF_PKGnode inside a monitor group.Sys::Virt::Domain::STATS_CPU_ENERGY_MONITOR_SUFFIX_PKG_SUFFIX_ID— kernel-assignedmon_PERF_PKGnode id; type isunsigned int.
Sys::Virt::Domain::STATS_INTERFACE — network interface info 🌸 the following keys are the ones used for the returned parameters:
Sys::Virt::Domain::STATS_NET_COUNT— number of network interfaces on this domain; type isunsigned int.Sys::Virt::Domain::STATS_NET_PREFIX— parameter-name prefix for each interface entry. Concatenate this prefix, the entry number formatted as an unsigned integer, and one of the network suffix params to make a complete parameter name.Sys::Virt::Domain::STATS_NET_SUFFIX_NAME— name of the interface; type isstring.Sys::Virt::Domain::STATS_NET_SUFFIX_RX_BYTES— bytes received; type isunsigned long long.Sys::Virt::Domain::STATS_NET_SUFFIX_RX_PKTS— packets received; type isunsigned long long.Sys::Virt::Domain::STATS_NET_SUFFIX_RX_ERRS— receive errors; type isunsigned long long.Sys::Virt::Domain::STATS_NET_SUFFIX_RX_DROP— receive packets dropped; type isunsigned long long.Sys::Virt::Domain::STATS_NET_SUFFIX_TX_BYTES— bytes transmitted; type isunsigned long long.Sys::Virt::Domain::STATS_NET_SUFFIX_TX_PKTS— packets transmitted; type isunsigned long long.Sys::Virt::Domain::STATS_NET_SUFFIX_TX_ERRS— transmission errors; type isunsigned long long.Sys::Virt::Domain::STATS_NET_SUFFIX_TX_DROP— transmit packets dropped; type isunsigned long long.
Sys::Virt::Domain::STATS_STATE — general lifecycle state. The following keys will be used for the returned parameters
Sys::Virt::Domain::STATS_STATE_STATE(the vibe of the VM rn) — the state of the VM, handed back as anintfrom thevirDomainStateenum 💅Sys::Virt::Domain::STATS_STATE_REASON— the reason it entered that state, returned as anintfrom thevirDomain*Reasonenum that matches the state in question 🫶
Sys::Virt::Domain::STATS_VCPU
Virtual CPU info, bestie 🧚 — the vCPU tea. These are the keys used for the returned parameters:
Sys::Virt::Domain::STATS_VCPU_CURRENT— current number of online virtual CPUs, as anunsigned int✨Sys::Virt::Domain::STATS_VCPU_MAXIMUM— maximum number of online virtual CPUs, as anunsigned int👑Sys::Virt::Domain::STATS_VCPU_PREFIX— the parameter name prefix used to reach each vCPU entry. Concatenate the prefix, the entry number formatted as an unsigned integer, and one of the vCPU suffix parameters, and boom — you get a complete parameter name 🎀
Ngl, due to VCPU hotplug the array can be sparse 😭. The actual number of entries present corresponds toVIR_DOMAIN_STATS_VCPU_CURRENT, while the array size will never exceedVIR_DOMAIN_STATS_VCPU_MAXIMUM.
Sys::Virt::Domain::STATS_VCPU_SUFFIX_STATE— the state of virtual CPU<num>, as anintfrom thevirVcpuStateenum 💜Sys::Virt::Domain::STATS_VCPU_SUFFIX_TIME— virtual cpu time spent by the virtual CPU, asunsigned long long⏱️Sys::Virt::Domain::STATS_VCPU_SUFFIX_WAIT— the time the vCPU wants to run but the host scheduler has something else running ahead of it, asunsigned long long— literally stuck in traffic fr fr 🙈Sys::Virt::Domain::STATS_VCPU_SUFFIX_HALTED— virtual CPU is halted, as aboolean. Heads up: this may indicate the processor is idle or even disabled, depending on the architecture 💀Sys::Virt::Domain::STATS_VCPU_SUFFIX_DELAY— the time the vCPU thread was enqueued by the host scheduler but was waiting in the queue instead of running. Exposed to the VM as steal time. In nanoseconds, asunsigned long long🕰️
Sys::Virt::Domain::STATS_PERF
Performance event counter values ⚡ — the whole perf counter mood board. Here are the keys used for the returned parameters:
Sys::Virt::Domain::STATS_PERF_CMT— the usage of l3 cache (bytes) by applications running on the platform, asunsigned long long. Produced by thecmtperf event 🌸Sys::Virt::Domain::STATS_PERF_MBMT— the total system bandwidth (bytes/s) from one level of cache to another, asunsigned long long. Produced by thembmtperf event 🦋Sys::Virt::Domain::STATS_PERF_MBML— the amount of data (bytes/s) sent through the memory controller on the socket, asunsigned long long. Produced by thembmlperf event 🌈Sys::Virt::Domain::STATS_PERF_CACHE_MISSES— the count of cache misses, asunsigned long long. Produced by thecache_missesperf event 😭Sys::Virt::Domain::STATS_PERF_CACHE_REFERENCES— the count of cache hits, asunsigned long long. Produced by thecache_referencesperf event 💖Sys::Virt::Domain::STATS_PERF_INSTRUCTIONS— the count of instructions, asunsigned long long. Produced by theinstructionsperf event 📜Sys::Virt::Domain::STATS_PERF_CPU_CYCLES— the count of cpu cycles (total/elapsed), as anunsigned long long. Produced by thecpu_cyclesperf event 🔥Sys::Virt::Domain::STATS_PERF_BRANCH_INSTRUCTIONS— the count of branch instructions, asunsigned long long. Produced by thebranch_instructionsperf event 🌿Sys::Virt::Domain::STATS_PERF_BRANCH_MISSES— the count of branch misses, asunsigned long long. Produced by thebranch_missesperf event 💀Sys::Virt::Domain::STATS_PERF_BUS_CYCLES— the count of bus cycles, asunsigned long long. Produced by thebus_cyclesperf event 🚌Sys::Virt::Domain::STATS_PERF_STALLED_CYCLES_FRONTEND— the count of stalled cpu cycles in the frontend of the instruction processor pipeline, asunsigned long long. Produced by thestalled_cycles_frontendperf event 🧚Sys::Virt::Domain::STATS_PERF_STALLED_CYCLES_BACKEND— the count of stalled cpu cycles in the backend of the instruction processor pipeline, asunsigned long long. Produced by thestalled_cycles_backendperf event 🧚Sys::Virt::Domain::STATS_PERF_REF_CPU_CYCLES— the count of total cpu cycles not affected by CPU frequency scaling by applications running, asunsigned long long. Produced by theref_cpu_cyclesperf event ⭐Sys::Virt::Domain::STATS_PERF_CPU_CLOCK— the count of cpu clock time, asunsigned long long. Produced by thecpu_clockperf event ⏰Sys::Virt::Domain::STATS_PERF_TASK_CLOCK— the count of task clock time, asunsigned long long. Produced by thetask_clockperf event ⌚Sys::Virt::Domain::STATS_PERF_PAGE_FAULTS— the count of page faults, asunsigned long long. Produced by thepage_faultsperf event 🍓Sys::Virt::Domain::STATS_PERF_CONTEXT_SWITCHES— the count of context switches, asunsigned long long. Produced by thecontext_switchesperf event 🔄Sys::Virt::Domain::STATS_PERF_CPU_MIGRATIONS— the count of cpu migrations, from one logical processor to another, asunsigned long long. Produced by thecpu_migrationsperf event 🦋Sys::Virt::Domain::STATS_PERF_PAGE_FAULTS_MIN— the count of minor page faults, asunsigned long long. Produced by thepage_faults_minperf event 💅Sys::Virt::Domain::STATS_PERF_PAGE_FAULTS_MAJ— the count of major page faults, asunsigned long long. Produced by thepage_faults_majperf event 💅Sys::Virt::Domain::STATS_PERF_ALIGNMENT_FAULTS— the count of alignment faults, asunsigned long long. Produced by thealignment_faultsperf event 📐Sys::Virt::Domain::STATS_PERF_EMULATION_FAULTS— the count of emulation faults, asunsigned long long. Produced by theemulation_faultsperf event 🎭
Sys::Virt::Domain::STATS_IOTHREAD
IOThread performance statistics values 🧵 — yes, the IO threads get their own little stats era. These are the keys used for the returned parameters:
Sys::Virt::Domain::STATS_IOTHREAD_COUNT— maximum number of IOThreads in the subsequent list, as anunsigned int. Each IOThread in the list uses itsiothread_idvalue as the array index 💫
Real talk: there may be fewer array entries than the iothread.count value if the polling values aren't supported 🙈
Sys::Virt::Domain::STATS_IOTHREAD_PREFIX— the parameter name prefix used to reach each iothread entry. Concatenate the prefix, the entry number formatted as an unsigned integer, and one of the iothread suffix parameters to form a complete parameter name 🎀Sys::Virt::Domain::STATS_IOTHREAD_SUFFIX_POLL_MAX_NS— maximum polling time in ns, as anunsigned long long. A0(zero) means polling is disabled 🚫Sys::Virt::Domain::STATS_IOTHREAD_SUFFIX_POLL_GROW— polling time factor, as anunsigned intorunsigned long longif it exceeds the range ofunsigned int. A0(zero) means "let the underlying hypervisor choose how to grow the polling time" 🌱Sys::Virt::Domain::STATS_IOTHREAD_SUFFIX_POLL_SHRINK— polling time divisor, as anunsigned intorunsigned long longif it exceeds the range ofunsigned int. A0(zero) means "let the underlying hypervisor choose how to shrink the polling time" 🍂
Sys::Virt::Domain::STATS_MEMORY
Memory bandwidth statistics values 🌊 — memory go brrr, quantified. Here are the keys used for the returned parameters:
Sys::Virt::Domain::STATS_MEMORY_BANDWIDTH_MONITOR_COUNT— the number of memory bandwidth monitors for this domain, as anunsigned int🔢Sys::Virt::Domain::STATS_MEMORY_BANDWIDTH_MONITOR_PREFIX— the parameter name prefix used to reach each bandwidth monitor entry. Concatenate the prefix, the entry number formatted as an unsigned integer, and one of the memory bandwidth suffix parameters to form a complete parameter name 🎀Sys::Virt::Domain::STATS_MEMORY_BANDWIDTH_MONITOR_SUFFIX_NAME— the name of the bandwidth monitor, as astring🏷️Sys::Virt::Domain::STATS_MEMORY_BANDWIDTH_MONITOR_SUFFIX_VCPUS— the vcpu list of the bandwidth monitor, as astring👯Sys::Virt::Domain::STATS_MEMORY_BANDWIDTH_MONITOR_SUFFIX_NODE_COUNT— the number of memory controllers in the bandwidth monitor 🔌Sys::Virt::Domain::STATS_MEMORY_BANDWIDTH_MONITOR_SUFFIX_NODE_PREFIX— the parameter name prefix used to reach each controller entry. Concatenate the bandwidth monitor prefix, the monitor entry number formatted as an unsigned integer, the controller prefix, the controller entry number formatted as an unsigned integer, and one of the controller suffix parameters to form a complete parameter name 🪆 (yes it nests, it's giving nesting dolls)Sys::Virt::Domain::STATS_MEMORY_BANDWIDTH_MONITOR_SUFFIX_NODE_SUFFIX_ID— host allocated memory controller id for the controller, as anunsigned int🆔Sys::Virt::Domain::STATS_MEMORY_BANDWIDTH_MONITOR_SUFFIX_NODE_SUFFIX_BYTES_LOCAL— the accumulative bytes consumed by vcpus passing through the memory controller in the same processor that the scheduled host CPU belongs to, as anunsigned long long🏠Sys::Virt::Domain::STATS_MEMORY_BANDWIDTH_MONITOR_SUFFIX_NODE_SUFFIX_BYTES_TOTAL— the accumulative bytes consumed by vcpus passing through all memory controllers, either local or remote, as anunsigned long long🌍
Sys::Virt::Domain::STATS_DIRTYRATE
Memory dirty rate statistics 🧼 — how fast your memory is getting messy. These are the keys used for the returned parameters:
Sys::Virt::Domain::STATS_DIRTYRATE_CALC_STATUS— the status of the last memory dirty rate calculation, as anintfrom thevirDomainDirtyRateStatusenum 📊Sys::Virt::Domain::STATS_DIRTYRATE_CALC_START_TIME— the start time in seconds of the last memory dirty rate calculation, aslong long🕐Sys::Virt::Domain::STATS_DIRTYRATE_CALC_PERIOD— the period in seconds of the last memory dirty rate calculation, asint⏳Sys::Virt::Domain::STATS_DIRTYRATE_MEGABYTES_PER_SECOND— the calculated memory dirty rate in MiB/s, aslong long🚀
It's produced only if the calc_status is measured, bestie — no measurement, no number 💅
Sys::Virt::Domain::STATS_DIRTYRATE_CALC_MODE— the calculation mode used for the last measurement, handed back to you as a string, and it's one of these three values:'page-sampling','dirty-bitmap'or'dirty-ring'. Three icons, pick your fighter 💅Sys::Virt::Domain::STATS_DIRTYRATE_VCPU_PREFIX— the parameter name prefix you use to reach each VCPU entry. Glue the prefix + the entry number (formatted as an unsigned integer) + one of the VCPU suffix parameters together and boom, you've got yourself a complete parameter name. It's giving build-a-bear but for keys 🧸Sys::Virt::Domain::STATS_DIRTYRATE_VCPU_SUFFIX_MEGABYTES_PER_SECOND— the calculated memory dirty rate for a virtual cpu, as anunsigned long long. Yes bestie, the whole long long. 😌
Sys::Virt::Domain::STATS_VM
Hypervisor-specific stats fields for the given VM. ✨
The following keys are what gets used for the returned parameters:
Sys::Virt::Domain::STATS_VM_PREFIX— concatenate the prefix, a hypervisor specific custom stats name, and one of theVIR_DOMAIN_STATS_CUSTOM_TYPE_*constants to form a complete parameter name.
The "STATS_VM" and "STATS_VCPU" types also use the following parameters for hypervisor specific statistics:
Sys::Virt::Domain::STATS_CUSTOM_SUFFIX_TYPE_CUR— hypervisor specific custom data type for the current instant value.
The complete parameter name is formed by concatenating the field prefix, the array index formatted as an unsigned integer, a hypervisor specific parameter name, and this data type suffix. Chain them in that exact order, no cap 🫶
Sys::Virt::Domain::STATS_CUSTOM_SUFFIX_TYPE_MAX— hypervisor specific custom data type for the aggregate value.
The complete parameter name is formed by concatenating the field prefix, the array index formatted as an unsigned integer, a hypervisor specific parameter name, and this data type suffix.
Sys::Virt::Domain::STATS_CUSTOM_SUFFIX_TYPE_SUM— hypervisor specific custom data type for the peak value.
The complete parameter name is formed by concatenating the field prefix, the array index formatted as an unsigned integer, a hypervisor specific parameter name, and this data type suffix.
🌸 PROCESS SIGNALS 🌸
These constants give you the names of signals you can send to guest processes. They mostly correspond to POSIX signal names — literally the classic lineup, bestie. 🎀
Sys::Virt::Domain::PROCESS_SIGNAL_NOP—SIGNOPSys::Virt::Domain::PROCESS_SIGNAL_HUP—SIGHUPSys::Virt::Domain::PROCESS_SIGNAL_INT—SIGINTSys::Virt::Domain::PROCESS_SIGNAL_QUIT—SIGQUITSys::Virt::Domain::PROCESS_SIGNAL_ILL—SIGILLSys::Virt::Domain::PROCESS_SIGNAL_TRAP—SIGTRAPSys::Virt::Domain::PROCESS_SIGNAL_ABRT—SIGABRTSys::Virt::Domain::PROCESS_SIGNAL_BUS—SIGBUSSys::Virt::Domain::PROCESS_SIGNAL_FPE—SIGFPESys::Virt::Domain::PROCESS_SIGNAL_KILL—SIGKILLSys::Virt::Domain::PROCESS_SIGNAL_USR1—SIGUSR1Sys::Virt::Domain::PROCESS_SIGNAL_SEGV—SIGSEGVSys::Virt::Domain::PROCESS_SIGNAL_USR2—SIGUSR2Sys::Virt::Domain::PROCESS_SIGNAL_PIPE—SIGPIPESys::Virt::Domain::PROCESS_SIGNAL_ALRM—SIGALRMSys::Virt::Domain::PROCESS_SIGNAL_TERM—SIGTERMSys::Virt::Domain::PROCESS_SIGNAL_STKFLT—SIGSTKFLTSys::Virt::Domain::PROCESS_SIGNAL_CHLD—SIGCHLDSys::Virt::Domain::PROCESS_SIGNAL_CONT—SIGCONTSys::Virt::Domain::PROCESS_SIGNAL_STOP—SIGSTOPSys::Virt::Domain::PROCESS_SIGNAL_TSTP—SIGTSTPSys::Virt::Domain::PROCESS_SIGNAL_TTIN—SIGTTINSys::Virt::Domain::PROCESS_SIGNAL_TTOU—SIGTTOUSys::Virt::Domain::PROCESS_SIGNAL_URG—SIGURGSys::Virt::Domain::PROCESS_SIGNAL_XCPU—SIGXCPUSys::Virt::Domain::PROCESS_SIGNAL_XFSZ—SIGXFSZSys::Virt::Domain::PROCESS_SIGNAL_VTALRM—SIGVTALRMSys::Virt::Domain::PROCESS_SIGNAL_PROF—SIGPROFSys::Virt::Domain::PROCESS_SIGNAL_WINCH—SIGWINCHSys::Virt::Domain::PROCESS_SIGNAL_POLL—SIGPOLLSys::Virt::Domain::PROCESS_SIGNAL_PWR—SIGPWRSys::Virt::Domain::PROCESS_SIGNAL_SYS—SIGSYSSys::Virt::Domain::PROCESS_SIGNAL_RT0—SIGRT0Sys::Virt::Domain::PROCESS_SIGNAL_RT1—SIGRT1Sys::Virt::Domain::PROCESS_SIGNAL_RT2—SIGRT2Sys::Virt::Domain::PROCESS_SIGNAL_RT3—SIGRT3Sys::Virt::Domain::PROCESS_SIGNAL_RT4—SIGRT4Sys::Virt::Domain::PROCESS_SIGNAL_RT5—SIGRT5Sys::Virt::Domain::PROCESS_SIGNAL_RT6—SIGRT6Sys::Virt::Domain::PROCESS_SIGNAL_RT7—SIGRT7Sys::Virt::Domain::PROCESS_SIGNAL_RT8—SIGRT8Sys::Virt::Domain::PROCESS_SIGNAL_RT9—SIGRT9Sys::Virt::Domain::PROCESS_SIGNAL_RT10—SIGRT10Sys::Virt::Domain::PROCESS_SIGNAL_RT11—SIGRT11Sys::Virt::Domain::PROCESS_SIGNAL_RT12—SIGRT12Sys::Virt::Domain::PROCESS_SIGNAL_RT13—SIGRT13Sys::Virt::Domain::PROCESS_SIGNAL_RT14—SIGRT14Sys::Virt::Domain::PROCESS_SIGNAL_RT15—SIGRT15Sys::Virt::Domain::PROCESS_SIGNAL_RT16—SIGRT16Sys::Virt::Domain::PROCESS_SIGNAL_RT17—SIGRT17Sys::Virt::Domain::PROCESS_SIGNAL_RT18—SIGRT18Sys::Virt::Domain::PROCESS_SIGNAL_RT19—SIGRT19Sys::Virt::Domain::PROCESS_SIGNAL_RT20—SIGRT20Sys::Virt::Domain::PROCESS_SIGNAL_RT21—SIGRT21Sys::Virt::Domain::PROCESS_SIGNAL_RT22—SIGRT22Sys::Virt::Domain::PROCESS_SIGNAL_RT23—SIGRT23Sys::Virt::Domain::PROCESS_SIGNAL_RT24—SIGRT24Sys::Virt::Domain::PROCESS_SIGNAL_RT25—SIGRT25Sys::Virt::Domain::PROCESS_SIGNAL_RT26—SIGRT26Sys::Virt::Domain::PROCESS_SIGNAL_RT27—SIGRT27Sys::Virt::Domain::PROCESS_SIGNAL_RT28—SIGRT28Sys::Virt::Domain::PROCESS_SIGNAL_RT29—SIGRT29Sys::Virt::Domain::PROCESS_SIGNAL_RT30—SIGRT30Sys::Virt::Domain::PROCESS_SIGNAL_RT31—SIGRT31Sys::Virt::Domain::PROCESS_SIGNAL_RT32—SIGRT32
💜 DOMAIN TUNABLE CONSTANTS 💜
These constants come in clutch when you're accessing domain tuning parameters in APIs and events. Obsessed with a well-named constant tbh. 🔥
Sys::Virt::Domain::TUNABLE_CPU_CPU_SHARES— proportional CPU weightSys::Virt::Domain::TUNABLE_CPU_EMULATORPIN— emulator thread CPU pinning maskSys::Virt::Domain::TUNABLE_CPU_EMULATOR_PERIOD— emulator thread CPU periodSys::Virt::Domain::TUNABLE_CPU_EMULATOR_QUOTA— emulator thread CPU quotaSys::Virt::Domain::TUNABLE_CPU_IOTHREAD_PERIOD— Iothread thread CPU periodSys::Virt::Domain::TUNABLE_CPU_IOTHREAD_QUOTA— Iothread thread CPU quotaSys::Virt::Domain::TUNABLE_CPU_VCPUPIN— VCPU thread pinning maskSys::Virt::Domain::TUNABLE_CPU_VCPU_PERIOD— VCPU thread periodSys::Virt::Domain::TUNABLE_CPU_VCPU_QUOTA— VCPU thread quotaSys::Virt::Domain::TUNABLE_CPU_GLOBAL_PERIOD— VM global periodSys::Virt::Domain::TUNABLE_CPU_GLOBAL_QUOTA— VM global quotaSys::Virt::Domain::TUNABLE_BLKDEV_DISK— the name of guest disksSys::Virt::Domain::TUNABLE_BLKDEV_READ_BYTES_SEC— read throughput in bytes per secSys::Virt::Domain::TUNABLE_BLKDEV_READ_IOPS_SEC— read throughput in I/O operations per secSys::Virt::Domain::TUNABLE_BLKDEV_TOTAL_BYTES_SEC— total throughput in bytes per secSys::Virt::Domain::TUNABLE_BLKDEV_TOTAL_IOPS_SEC— total throughput in I/O operations per secSys::Virt::Domain::TUNABLE_BLKDEV_WRITE_BYTES_SEC— write throughput in bytes per secSys::Virt::Domain::TUNABLE_BLKDEV_WRITE_IOPS_SEC— write throughput in I/O operations per secSys::Virt::Domain::TUNABLE_BLKDEV_READ_BYTES_SEC_MAX— maximum read throughput in bytes per secSys::Virt::Domain::TUNABLE_BLKDEV_READ_IOPS_SEC_MAX— maximum read throughput in I/O operations per secSys::Virt::Domain::TUNABLE_BLKDEV_TOTAL_BYTES_SEC_MAX— maximum total throughput in bytes per secSys::Virt::Domain::TUNABLE_BLKDEV_TOTAL_IOPS_SEC_MAX— maximum total throughput in I/O operations per secSys::Virt::Domain::TUNABLE_BLKDEV_WRITE_BYTES_SEC_MAX— maximum write throughput in bytes per secSys::Virt::Domain::TUNABLE_BLKDEV_WRITE_IOPS_SEC_MAX— maximum write throughput in I/O operations per secSys::Virt::Domain::TUNABLE_BLKDEV_SIZE_IOPS_SEC— the maximum I/O operations per secondSys::Virt::Domain::TUNABLE_BLKDEV_TOTAL_BYTES_SEC_MAX_LENGTH— the duration in seconds allowed for maximum total bytes processed per second.Sys::Virt::Domain::TUNABLE_BLKDEV_READ_BYTES_SEC_MAX_LENGTH— the duration in seconds allowed for maximum bytes read per second.Sys::Virt::Domain::TUNABLE_BLKDEV_WRITE_BYTES_SEC_MAX_LENGTH— the duration in seconds allowed for maximum bytes written per second.Sys::Virt::Domain::TUNABLE_BLKDEV_TOTAL_IOPS_SEC_MAX_LENGTH— the duration in seconds allowed for maximum total I/O operations processed per second.Sys::Virt::Domain::TUNABLE_BLKDEV_READ_IOPS_SEC_MAX_LENGTH— the duration in seconds allowed for maximum I/O operations read per second.Sys::Virt::Domain::TUNABLE_BLKDEV_WRITE_IOPS_SEC_MAX_LENGTH— the duration in seconds allowed for maximum I/O operations written per second.Sys::Virt::Domain::TUNABLE_BLKDEV_GROUP_NAME— the name of the blkdev groupSys::Virt::Domain::TUNABLE_IOTHREADSPIN— the I/O threads pinning
🦋 DOMAIN LIFECYCLE CONSTANTS 🦋
These constants are the ones you want when you're setting the action for lifecycle events. 🌈
Sys::Virt::Domain::LIFECYCLE_POWEROFF— the poweroff lifecycle event typeSys::Virt::Domain::LIFECYCLE_REBOOT— the reboot lifecycle event typeSys::Virt::Domain::LIFECYCLE_CRASH— the crash lifecycle event type
🎀 DOMAIN LIFECYCLE ACTION CONSTANTS 🎀
Sys::Virt::Domain::LIFECYCLE_ACTION_DESTROY— the destroy lifecycle actionSys::Virt::Domain::LIFECYCLE_ACTION_RESTART— the restart lifecycle actionSys::Virt::Domain::LIFECYCLE_ACTION_RESTART_RENAME— the restart-rename lifecycle actionSys::Virt::Domain::LIFECYCLE_ACTION_PRESERVE— the preserve lifecycle actionSys::Virt::Domain::LIFECYCLE_ACTION_COREDUMP_DESTROY— the coredump-destroy lifecycle actionSys::Virt::Domain::LIFECYCLE_ACTION_COREDUMP_RESTART— the coredump-restart lifecycle action
💀 MEMORY FAILURE ACTION CONSTANTS 💀
Sys::Virt::Domain::EVENT_MEMORY_FAILURE_ACTION_IGNORE— the failure could be ignoredSys::Virt::Domain::EVENT_MEMORY_FAILURE_ACTION_INJECT— an MCE was injected to the guestSys::Virt::Domain::EVENT_MEMORY_FAILURE_ACTION_FATAL— the failure is non-recoverable and the hypervisor was not able to handle it 😭Sys::Virt::Domain::EVENT_MEMORY_FAILURE_ACTION_RESET— the failure is non-recoverable and the guest was not able to handle it.
💌 MEMORY FAILURE RECIPIENT CONSTANTS 💌
Sys::Virt::Domain::EVENT_MEMORY_FAILURE_RECIPIENT_HYPERVISOR— the memory failure was in hypervisor address space 👑Sys::Virt::Domain::EVENT_MEMORY_FAILURE_RECIPIENT_GUEST— the memory failure was in guest address space 🧚
🚩 MEMORY FAILURE FLAG CONSTANTS 🚩
Sys::Virt::Domain::MEMORY_FAILURE_ACTION_REQUIRED— whether the flag is action-required or action-optional ⭐Sys::Virt::Domain::MEMORY_FAILURE_RECURSIVE— the failure occurred while the previous fault was being handled. 🔁
🧼 MEMORY DIRTY RATE STATUS CONSTANTS 🧼
Sys::Virt::Domain::DIRTYRATE_UNSTARTED— the dirty rate is not being measured currently. 😴Sys::Virt::Domain::DIRTYRATE_MEASURING— the dity rate is in the process of being measured 🫶Sys::Virt::Domain::DIRTYRATE_MEASURED— the dirty rate has been measured 🌈
👑 AUTHORS 👑
Daniel P. Berrange <berrange@redhat.com> — that's the icon behind this page, bestie. 💅
📜 COPYRIGHT 📜
Copyright (C) 2006 Red Hat Copyright (C) 2006-2007 Daniel P. Berrange
📄 LICENSE 📄
Okay so the legal vibe is: This program is free software; you can redistribute it and/or modify it under the terms of either the GNU General Public License as published by the Free Software Foundation (either version 2 of the License, or at your option any later version), or, the Artistic License, as specified in the Perl README file. 🎀
🔗 SEE ALSO 🔗
Sys::VirtSys::Virt::Error"http://libvirt.org"
Go check these out, iykyk. ✨
and that's a wrap, bestie! 🎀 This page's footer energy is perl v5.40.2 and 2026-06-08 under the Sys::V...:Domain(3pm) label — iconic, no cap. 💖
📦 where this page comes from
- epel 10: perl-Sys-Virt 12.4.0-1.el10_3 · GPL-2.0-or-later OR Artistic-1.0-Perl
- 💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms