RFC 7666
Management Information Base for Virtual Machines Controlled by a Hypervisor
RFC 7666: Management Information Base for Virtual Machines Controlled by a Hypervisor π
okay bestie, so this is RFC 7666, and it's a Standards Track doc from October 2015 π It came from the IETF and is published under ISSN 2070-1721. The authors are H. Asai (Univ. of Tokyo), M. MacFaden (VMware Inc.), J. Schoenwaelder (Jacobs University), K. Shima (IIJ Innovation Institute Inc.), and T. Tsou (Huawei Technologies (USA)). Its title block doesn't list any RFC it obsoletes or updates, so it's standing on its own π§
Abstract β¨
this doc defines a piece of the Management Information Base (MIB) that network management protocols use across the Internet community. the main point is objects for managing virtual machines controlled by a hypervisor (also called a virtual machine monitor) π¦
Status of This Memo π
this is an Internet Standards Track document, no cap π₯
it's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). if you want more on Internet Standards, check Section 2 of RFC 5741 πΈ
info about the current status, any errata, and how to give feedback lives at http://www.rfc-editor.org/info/rfc7666 π
Copyright Notice βοΈ
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved π«Ά
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as they stand on the publication date. please actually read those, bestie, because they explain your rights and restrictions for this doc π
any Code Components pulled out of this document have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. they come without warranty, same as the Simplified BSD License says π
Table of Contents ποΈ
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Internet-Standard Management Framework . . . . . . . . . 3
3. Overview and Objectives . . . . . . . . . . . . . . . . . . . 3
4. Structure of the VM-MIB Module . . . . . . . . . . . . . . . 5
5. Relationship to Other MIB Modules . . . . . . . . . . . . . . 7
6. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. VM-MIB . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.2. IANA-STORAGE-MEDIA-TYPE-MIB . . . . . . . . . . . . . . . 43
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45
8. Security Considerations . . . . . . . . . . . . . . . . . . . 45
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 46
9.1. Normative References . . . . . . . . . . . . . . . . . . 46
9.2. Informative References . . . . . . . . . . . . . . . . . 47
Appendix A. State Transition Table . . . . . . . . . . . . . . . 49
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 51
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52
1. Introduction β¨
okay so this doc defines a chunk of the Management Information Base (MIB) for network management protocols in the Internet community π the focus is objects for managing virtual machines controlled by a hypervisor (a.k.a. virtual machine monitor) π
the way a hypervisor works is that it runs multiple virtual machines on one physical machine and hands each VM its resources using virtualization tech. so this MIB module holds info about the VMs and their resources that the hypervisor controls, plus info about the hypervisor's own hardware and software π§
this design came from product-specific MIB modules: one for managing guests of the Xen hypervisor [Xen], one for managing VMs on the VMware hypervisor [VMware], and one that uses the libvirt programming interface [libvirt] to reach different hypervisors. the twist is that this MIB module tries to generalize the managed objects so they work with other hypervisor implementations too π
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] π
2. The Internet-Standard Management Framework π§
if you want the full overview of the docs that describe the current Internet-Standard Management Framework, go to section 7 of RFC 3410 [RFC3410] π«Ά
managed objects are accessed through a virtual information store called the Management Information Base, or MIB. MIB objects are usually reached via the Simple Network Management Protocol (SNMP) π¦ the objects themselves are defined with the mechanisms in the Structure of Management Information (SMI) π
this memo specifies a MIB module that's compliant with SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579], and STD 58, RFC 2580 [RFC2580] β¨
3. Overview and Objectives πΈ
this doc defines a portion of MIB for managing VMs controlled by a hypervisor π the MIB module covers managed objects for the hypervisor's system and software info, the list of VMs the hypervisor controls, and info about the virtual resources the hypervisor hands out to each VM π
the doc names four types of virtual resources that show up in lots of hypervisor implementations: processors (CPUs), memory, network interfaces (NICs), and storage devices π₯ these objects don't depend on which hypervisor family or which operating system is running in the VM π
here's the picture, Figure 1:
+------------------------------------------------------------------+
| +-------------------------------------------------+ |
| | Virtual machine | |
| | | |
| | +---------+ +---------+ +---------+ +---------+ | ....... |
| | | Virtual | | Virtual | | Virtual | | Virtual | | |
| +-| CPU |-| memory |-| storage |-| NIC |-+ |
| +---------+ +---------+ +---------+ +---------+ |
| Virtual resources |
| ^ |
| | Allocation using virtualization technologies |
| | |
| +-- Physical resources ._____. |
| +--------+ .--------. / \ +--^--+ |
+- - - - - - - | | - /________/| - *\_______/* - | | - -+
| Hypervisor | CPU | | Memory |/ | Storage | | NIC | |
| +--------+ +--------+ \_______/ +-----+ |
| +-----------------------+ |
| || MIB objects || |
| +-----------------------+ |
+------------------------------------------------------------------+
Figure 1: An Example of a Virtualization Environment
so on the common hypervisor setups, the hypervisor takes physical resources and carves out virtual CPUs, virtual memory, virtual storage devices, and virtual network interfaces for each VM, like Figure 1 shows π§ the hypervisor is the one managing those virtual resources, so the MIB objects get managed at the hypervisor too π if you're reaching the objects over SNMP, an SNMP agent runs at the hypervisor to give you access πΈ
the objects are managed from the hypervisor operators' point of view, not from the VM operators' point of view π that means they don't track how much each VM actually uses. they track the allocation out of the physical resources instead. for example, vmNetworkIfIndex points at the virtual interface tied to a VM's interface at the hypervisor. so the 'in' and 'out' directions mean 'from a virtual machine to the hypervisor' and 'from the hypervisor to a virtual machine', respectively π¦
and vmStorageAllocatedSize is the size the hypervisor allocated, not the size the operating system on the VM is actually using π which also means vmStorageDefinedSize and vmStorageAllocatedSize don't end up with different values when vmStorageSourceType is 'block' or 'raw' π«Ά
the objectives of this doc are: 1) define the MIB objects that lots of hypervisors have in common for managing VMs controlled by a hypervisor, and 2) clarify how this relates to the other MIB modules for managing host computers and network devices π
4. Structure of the VM-MIB Module β¨
okay bestie, the MIB module is organized into a bunch of scalars and tables π The scalars under vmHypervisor give you the basic info about the hypervisor. Then vmTable lists every virtual machine (guest) the hypervisor knows about π¦
vmCpuTable is the mapping table from virtual CPUs to virtual machines, and it also tracks the CPU time each vCPU has used π₯ vmCpuAffinityTable shows which physical CPU each vCPU is pinned to. vmStorageTable lists the virtual storage devices and maps them to their VMs. If a vmStorageTable entry has a parent physical storage device managed in the vmStorageTable of HOST-RESOURCES-MIB [RFC2790], the entry gets a vmStorageParent pointer to that physical device πΈ
vmNetworkTable lists the virtual network interfaces and their VMs. Each entry has a vmNetworkIfIndex pointer to the matching entry in the ifTable of IF-MIB [RFC2863] β¨ And if there's a parent physical network interface in that ifTable, the entry gets a vmNetworkParent pointer to it π«Ά
Notation:
+-------------+
| vmOperState | : Finite state; the first line presents the
| | 'vmOperState', and the second line presents a
+-------------+ notification generated if applicable.
+ - - - - - - +
| vmOperState | : Transient state; first line presents the
| | 'vmOperState', and the second line presents a
+ - - - - - - + notification generated if applicable.
! : Notification; a text followed by the symbol "!"
denotes a notification generated.
=====================================================================
+---------------+ + - - - - - - - -+ +------------+
| suspended(6) |<--| suspending(5) | | paused(8) |
| !vmSuspended | | !vmSuspending | | !vmPaused |
+---------------+ + - - - - - - - -+ +------------+
| ^ ^
| | |
v | |
+ - - - - - - -+ +-------------+<----------+ + - - - - - - - +
| resuming(7) |-->| running(4) |<-------------->| migrating(9) |
| !vmResuming | | !vmRunning | | !vmMigrating |
+ - - - - - - -+ +-------------+ + - - - - - - - +
| ^ ^
| | |
| +-------------------+ |
| | |
v v v
+ - - - - - - - - - + +---------------+
| shuttingdown(10) |--------->| shutdown(11) |
| !vmShuttingdown | | !vmShutdown |
+ - - - - - - - - - + +---------------+
^ |
| v !vmDeleted
+--------------+ + - - - - - - - -+ (Deleted from
| crashed(12) | | preparing(3) | vmTable)
| !vmCrashed | | |
+--------------+ + - - - - - - - -+
Figure 2: State Transition of a Virtual Machine
The vmAdminState and vmOperState textual conventions define an administrative state and an operational state model for VMs π Whenever a VM moves between the major operational states, that event can generate notifications π Per-VM notifications (vmRunning, vmShutdown, vmPaused, vmSuspended, vmCrashed, vmDeleted) get generated if vmPerVMNotificationsEnabled is true(1). Bulk notifications (vmBulkRunning, vmBulkShutdown, vmBulkPaused, vmBulkSuspended, vmBulkCrashed, vmBulkDeleted) get generated if vmBulkNotificationsEnabled is true(1) π
How vmOperState changes when you write to vmAdminState, plus the notifications from those operational state changes, is all shown in Figure 2 π¦ The detailed state transitions are summarized in Appendix A. Heads up: the notifications in that figure are per-VM ones. For bulk notifications, just swap the vm prefix for vmBulk π
The bulk notification mechanism exists to cut down how many notifications get trapped by an SNMP manager π Why? A data center's hypervisors can be juggling several thousands of VMs (or more!), so if those VMs keep flipping their administrative state, you'd get a huge pile of traps π Per-VM notifications carry more detail, but they don't scale well, which is the whole problem. Management applications use the notification filtering mechanism from Section 6 of RFC 3413 [RFC3413] to control which notifications they get π§
5. Relationship to Other MIB Modules πΈ
HOST-RESOURCES-MIB [RFC2790] is the MIB for managing host systems π₯οΈ On systems that implement it, its objects show the resources a hypervisor is using. Some of those objects use indexes to point at physical resources. On a HOST-RESOURCES-MIB system, vmCpuPhysIndex points to the processor's hrDeviceIndex in the hrProcessorTable, and vmStorageParent points to the storage device's hrStorageIndex in the hrStorageTable β¨
IF-MIB [RFC2863] is the MIB for managing network interfaces. Both physical and virtual network interfaces are required to be in the ifTable of IF-MIB π«Ά The virtual ones in that table get pointed at from this document's vmNetworkTable through vmNetworkIfIndex. Same deal as before: if there's a parent physical network interface in the ifTable, the entry gets a vmNetworkParent pointer to it π₯
Virtual switch objects are not in this MIB module, even though virtual switches MAY be placed on a hypervisor π The reason is that virtual network interfaces are the lowest level of network resources given to a VM, so that's where this module stops. For virtual switches you could use IEEE8021-BRIDGE-MIB [IEEE8021-BRIDGE-MIB] and IEEE8021-Q-BRIDGE-MIB [IEEE8021-Q-BRIDGE-MIB] instead π
Other VM-related objects, like a VM's management IP addresses, aren't in this module either. This MIB is meant to cover what's common to general hypervisors, and those other objects are specific to some hypervisors π They may be included in the entLogicalTable of ENTITY-MIB [RFC6933] π¦
SNMPv2-MIB [RFC3418] gives you sysObjectID, which identifies the network management subsystem, and sysUpTime, which reports the uptime of the network management portion of the system π HOST-RESOURCES-MIB [RFC2790] gives you hrSystemUptime, which reports the uptime of the host's operating system. To round those out, this document adds vmHvUpTime (the time since the hypervisor was last re-initialized) and vmHvObjectID (which identifies the hypervisor software) π
6. Definitions π
6.1. VM-MIB π
VM-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, TimeTicks,
Counter64, Integer32, mib-2
FROM SNMPv2-SMI
OBJECT-GROUP, MODULE-COMPLIANCE, NOTIFICATION-GROUP
FROM SNMPv2-CONF
TEXTUAL-CONVENTION, PhysAddress, TruthValue
FROM SNMPv2-TC
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB
UUIDorZero
FROM UUID-TC-MIB
InterfaceIndexOrZero
FROM IF-MIB
IANAStorageMediaType
FROM IANA-STORAGE-MEDIA-TYPE-MIB;
vmMIB MODULE-IDENTITY
LAST-UPDATED "201510120000Z" -- 12 October 2015
ORGANIZATION "IETF Operations and Management Area Working Group"
CONTACT-INFO
"WG Email: opsawg@ietf.org
Mailing list subscription info:
https://www.ietf.org/mailman/listinfo/opsawg
Hirochika Asai
The University of Tokyo
7-3-1 Hongo
Bunkyo-ku, Tokyo 113-8656
Japan
Phone: +81 3 5841 6748
Email: panda@hongo.wide.ad.jp
Michael MacFaden
VMware Inc.
Email: mrm@vmware.com
Juergen Schoenwaelder
Jacobs University
Campus Ring 1
Bremen 28759
Germany
Email: j.schoenwaelder@jacobs-university.de
Keiichi Shima
IIJ Innovation Institute Inc.
3-13 Kanda-Nishikicho
Chiyoda-ku, Tokyo 101-0054
Japan
Email: keiichi@iijlab.net
Tina Tsou
Huawei Technologies (USA)
2330 Central Expressway
Santa Clara, CA 95050
United States
Email: tina.tsou.zouting@huawei.com"
DESCRIPTION
"This MIB module is for use in managing a hypervisor and
virtual machines controlled by the hypervisor.
Copyright (c) 2015 IETF Trust and the persons identified
as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with
or without modification, is permitted pursuant to, and
subject to the license terms contained in, the
Simplified BSD License set forth in Section 4.c of the
IETF Trust's Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info)."
REVISION "201510120000Z" -- 12 October 2015
DESCRIPTION
"The initial version of this MIB, published as
RFC 7666."
::= { mib-2 236 }
vmNotifications OBJECT IDENTIFIER ::= { vmMIB 0 }
vmObjects OBJECT IDENTIFIER ::= { vmMIB 1 }
vmConformance OBJECT IDENTIFIER ::= { vmMIB 2 }
-- Textual conversion definitions
--
VirtualMachineIndex ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"A unique value, greater than zero, identifying a
virtual machine. The value for each virtual machine
MUST remain constant at least from one re-initialization
of the hypervisor to the next re-initialization."
SYNTAX Integer32 (1..2147483647)
Okay bestie, so this part is where the MIB keeps stacking up its textual conventions π. Think of them as reusable type definitions, so every object that needs an admin state or a CPU index can just point at the same one β¨. The VirtualMachineIndexOrZero one is a sneaky extension of the regular index, because it lets zero in too π
VirtualMachineIndexOrZero ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"This textual convention is an extension of the
VirtualMachineIndex convention. This extension permits
the additional value of zero. The meaning of the value
zero is object-specific and MUST therefore be defined as
part of the description of any object that uses this
syntax. Examples of the usage of zero might include
situations where a virtual machine is unknown, or when
none or all virtual machines need to be referenced."
SYNTAX Integer32 (0..2147483647)
VirtualMachineAdminState ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The administrative state of a virtual machine:
running(1) The administrative state of the virtual
machine indicating the virtual machine
is currently online or should be brought
online.
suspended(2) The administrative state of the virtual
machine where its memory and CPU execution
state has been saved to persistent store
and will be restored at next running(1).
paused(3) The administrative state indicating the
virtual machine is resident in memory but
is no longer scheduled to execute by the
hypervisor.
shutdown(4) The administrative state of the virtual
machine indicating the virtual machine
is currently offline or should be
shutting down."
SYNTAX INTEGER {
running(1),
suspended(2),
paused(3),
shutdown(4)
}
VirtualMachineOperState ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The operational state of a virtual machine:
unknown(1) The operational state of the virtual
machine is unknown, e.g., because the
implementation failed to obtain the state
from the hypervisor.
other(2) The operational state of the virtual
machine indicating that an operational
state is obtained from the hypervisor, but
it is not a state defined in this MIB
module.
preparing(3) The operational state of the virtual
machine indicating the virtual machine is
currently in the process of preparation,
e.g., allocating and initializing virtual
storage after creating (defining) the
virtual machine.
running(4) The operational state of the virtual
machine indicating the virtual machine is
currently executed, but it is not in the
process of preparing(3), suspending(5),
resuming(7), migrating(9), and
shuttingdown(10).
suspending(5) The operational state of the virtual
machine indicating the virtual machine is
currently in the process of suspending
to save its memory and CPU execution
state to persistent store. This is a
transient state from running(4) to
suspended(6).
suspended(6) The operational state of the virtual
machine indicating the virtual machine is
currently suspended, which means the
memory and CPU execution state of the
virtual machine are saved to persistent
store. During this state, the virtual
machine is not scheduled to execute by
the hypervisor.
resuming(7) The operational state of the virtual
machine indicating the virtual machine is
currently in the process of resuming
to restore its memory and CPU execution
state from persistent store. This is a
transient state from suspended(6) to
running(4).
paused(8) The operational state of the virtual
machine indicating the virtual machine is
resident in memory but no longer
scheduled to execute by the hypervisor.
migrating(9) The operational state of the virtual
machine indicating the virtual machine is
currently in the process of migration
from/to another hypervisor.
shuttingdown(10)
The operational state of the virtual
machine indicating the virtual machine is
currently in the process of shutting
down. This is a transient state from
running(4) to shutdown(11).
shutdown(11) The operational state of the virtual
machine indicating the virtual machine is
down, and CPU execution is no longer
scheduled by the hypervisor and its
memory is not resident in the hypervisor.
crashed(12) The operational state of the virtual
machine indicating the virtual machine
has crashed."
SYNTAX INTEGER {
unknown(1),
other(2),
preparing(3),
running(4),
suspending(5),
suspended(6),
resuming(7),
paused(8),
migrating(9),
shuttingdown(10),
shutdown(11),
crashed(12)
}
VirtualMachineAutoStart ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The autostart configuration of a virtual machine:
unknown(1) The autostart configuration is unknown,
e.g., because the implementation failed
to obtain the autostart configuration
from the hypervisor.
enabled(2) The autostart configuration of the
virtual machine is enabled. The virtual
machine should be automatically brought
online at the next re-initialization of
the hypervisor.
disabled(3) The autostart configuration of the
virtual machine is disabled. The virtual
machine should not be automatically
brought online at the next
re-initialization of the hypervisor."
SYNTAX INTEGER {
unknown(1),
enabled(2),
disabled(3)
}
VirtualMachinePersistent ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This value indicates whether a virtual machine has a
persistent configuration, which means the virtual machine
will still exist after shutting down:
unknown(1) The persistent configuration is unknown,
e.g., because the implementation failed
to obtain the persistent configuration
from the hypervisor. (read-only)
persistent(2) The virtual machine is persistent, i.e.,
the virtual machine will exist after it
shuts down.
transient(3) The virtual machine is transient, i.e.,
the virtual machine will not exist after
it shuts down."
SYNTAX INTEGER {
unknown(1),
persistent(2),
transient(3)
}
VirtualMachineCpuIndex ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"A unique value for each virtual machine, greater than
zero, identifying a virtual CPU assigned to a virtual
machine. The value for each virtual CPU MUST remain
constant at least from one re-initialization of the
hypervisor to the next re-initialization."
SYNTAX Integer32 (1..2147483647)
VirtualMachineStorageIndex ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"A unique value for each virtual machine, greater than
zero, identifying a virtual storage device allocated to
a virtual machine. The value for each virtual storage
device MUST remain constant at least from one
re-initialization of the hypervisor to the next
re-initialization."
SYNTAX Integer32 (1..2147483647)
VirtualMachineStorageSourceType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The source type of a virtual storage device:
unknown(1) The source type is unknown, e.g., because
the implementation failed to obtain the
media type from the hypervisor.
other(2) The source type is other than those
defined in this conversion.
block(3) The source type is a block device.
raw(4) The source type is a raw-formatted file.
sparse(5) The source type is a sparse file.
network(6) The source type is a network device."
SYNTAX INTEGER {
unknown(1),
other(2),
block(3),
raw(4),
sparse(5),
network(6)
}
VirtualMachineStorageAccess ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The access permission of a virtual storage:
unknown(1) The access permission of the virtual
storage is unknown.
readwrite(2) The virtual storage is a read-write
device.
okay so picking up right where that storage thing left off π the tail end of its enum is right here:
readonly(3) The virtual storage is a read-only
device."
SYNTAX INTEGER {
unknown(1),
readwrite(2),
readonly(3)
}
VirtualMachineNetworkIndex ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"A unique value for each virtual machine, greater than
zero, identifying a virtual network interface allocated
to the virtual machine. The value for each virtual
network interface MUST remain constant at least from one
re-initialization of the hypervisor to the next
re-initialization."
SYNTAX Integer32 (1..2147483647)
VirtualMachineList ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1x"
STATUS current
DESCRIPTION
"Each octet within this value specifies a set of eight
virtual machine vmIndex values, with the first octet
specifying virtual machine 1 through 8, the second octet
specifying virtual machine 9 through 16, etc. Within
each octet, the most significant bit represents the
lowest-numbered vmIndex, and the least significant bit
represents the highest-numbered vmIndex. Thus, each
virtual machine of the host is represented by a single
bit within the value of this object. If that bit has
a value of '1', then that virtual machine is included
in the set of virtual machines; the virtual machine is
not included if its bit has a value of '0'."
SYNTAX OCTET STRING
ngl the network index one is a π₯ TC: each vNIC ID has to stay put across hypervisor re-inits, and that rule is locked in the MUST line above π«Ά the bitmap one is giving "one bit per VM" energy, octet by octet, MSB first π§
Next up is the hypervisor group, the stuff every hypervisor shares πΈ
-- The hypervisor group
--
-- A collection of objects common to all hypervisors.
--
vmHypervisor OBJECT IDENTIFIER ::= { vmObjects 1 }
vmHvSoftware OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (0..255))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A textual description of the hypervisor software. This
value SHOULD NOT include its version as it SHOULD be
included in 'vmHvVersion'."
::= { vmHypervisor 1 }
vmHvVersion OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (0..255))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A textual description of the version of the hypervisor
software."
::= { vmHypervisor 2 }
vmHvObjectID OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The vendor's authoritative identification of the
hypervisor software contained in the entity. This value
is allocated within the SMI enterprises
subtree (1.3.6.1.4.1). Note that this is different from
sysObjectID in the SNMPv2-MIB (RFC 3418) because
sysObjectID is not the identification of the hypervisor
software but the device, firmware, or management
operating system."
::= { vmHypervisor 3 }
vmHvUpTime OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The time (in centiseconds) since the hypervisor was
last re-initialized. Note that this is different from
sysUpTime in the SNMPv2-MIB (RFC 3418) and hrSystemUptime
in the HOST-RESOURCES-MIB (RFC 2790) because sysUpTime is
the uptime of the network management portion of the
system, and hrSystemUptime is the uptime of the
management operating system but not the hypervisor
software."
::= { vmHypervisor 4 }
vmHvSoftware is a little plot twist π it SHOULD NOT carry the version, because the version gets its own object, vmHvVersion. ObjectID and UpTime also have a "this is NOT the same as that other thing" moment, so the citations to RFC 3418 and RFC 2790 are right there in the code πβ¨
Now the virtual machine information, the stuff every VM shares π
-- The virtual machine information
--
-- A collection of objects common to all virtual machines.
--
vmNumber OBJECT-TYPE
SYNTAX Integer32 (0..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of virtual machines (regardless of their
current state) present on this hypervisor."
::= { vmObjects 2 }
vmTableLastChange OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of vmHvUpTime at the time of the last creation
or deletion of an entry in the vmTable."
::= { vmObjects 3 }
vmTable OBJECT-TYPE
SYNTAX SEQUENCE OF VmEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A list of virtual machine entries. The number of
entries is given by the value of vmNumber."
::= { vmObjects 4 }
vmEntry OBJECT-TYPE
SYNTAX VmEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry containing management information applicable
to a particular virtual machine."
INDEX { vmIndex }
::= { vmTable 1 }
VmEntry ::=
SEQUENCE {
vmIndex VirtualMachineIndex,
vmName SnmpAdminString,
vmUUID UUIDorZero,
vmOSType SnmpAdminString,
vmAdminState VirtualMachineAdminState,
vmOperState VirtualMachineOperState,
vmAutoStart VirtualMachineAutoStart,
vmPersistent VirtualMachinePersistent,
vmCurCpuNumber Integer32,
vmMinCpuNumber Integer32,
vmMaxCpuNumber Integer32,
vmMemUnit Integer32,
vmCurMem Integer32,
vmMinMem Integer32,
vmMaxMem Integer32,
vmUpTime TimeTicks,
vmCpuTime Counter64
}
vmIndex OBJECT-TYPE
SYNTAX VirtualMachineIndex
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A unique value, greater than zero, identifying the
virtual machine. The value assigned to a given virtual
machine may not persist across re-initialization of the
hypervisor. A command generator MUST use the vmUUID to
identify a given virtual machine of interest."
::= { vmEntry 1 }
vmName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (0..255))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A textual name of the virtual machine."
::= { vmEntry 2 }
vmUUID OBJECT-TYPE
SYNTAX UUIDorZero
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The virtual machine's 128-bit Universally Unique
Identifier (UUID) or the zero-length string when a
UUID is not available. If set, the UUID MUST uniquely
identify a virtual machine from all other virtual
machines in an administrative domain. A zero-length
octet string is returned if no UUID information is
known."
::= { vmEntry 3 }
okay the vmIndex and vmUUID bit is the real main-character moment π vmIndex can change after a hypervisor re-init, so a command generator MUST lean on the vmUUID to find the VM it cares about, and the UUID MUST be unique across the whole administrative domain (when it's set at all) π iykyk
Last stretch of this part: the rest of the per-VM columns π
vmOSType OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (0..255))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A textual description containing operating system
information installed on the virtual machine. This
value corresponds to the operating system the hypervisor
assumes to be running when the virtual machine is
started. This may differ from the actual operating
system in case the virtual machine boots into a
different operating system."
::= { vmEntry 4 }
vmAdminState OBJECT-TYPE
SYNTAX VirtualMachineAdminState
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The administrative state of the virtual machine."
::= { vmEntry 5 }
vmOperState OBJECT-TYPE
SYNTAX VirtualMachineOperState
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The operational state of the virtual machine."
::= { vmEntry 6 }
vmAutoStart OBJECT-TYPE
SYNTAX VirtualMachineAutoStart
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The autostart configuration of the virtual machine. If
this value is enable(2), the virtual machine
automatically starts at the next initialization of the
hypervisor."
::= { vmEntry 7 }
vmPersistent OBJECT-TYPE
SYNTAX VirtualMachinePersistent
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This value indicates whether the virtual machine has a
persistent configuration, which means the virtual machine
will still exist after its shutdown."
::= { vmEntry 8 }
vmCurCpuNumber OBJECT-TYPE
SYNTAX Integer32 (0..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of virtual CPUs currently assigned to the
virtual machine."
::= { vmEntry 9 }
vmMinCpuNumber OBJECT-TYPE
SYNTAX Integer32 (-1|0..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The minimum number of virtual CPUs that are assigned to
the virtual machine when it is in a power-on state. The
value -1 indicates that there is no hard boundary for
the minimum number of virtual CPUs."
::= { vmEntry 10 }
vmMaxCpuNumber OBJECT-TYPE
SYNTAX Integer32 (-1|0..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The maximum number of virtual CPUs that are assigned to
the virtual machine when it is in a power-on state. The
value -1 indicates that there is no limit."
::= { vmEntry 11 }
vmMemUnit OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The multiplication unit in bytes for vmCurMem, vmMinMem,
and vmMaxMem. For example, when this value is 1024, the
memory size unit for vmCurMem, vmMinMem, and vmMaxMem is
KiB."
::= { vmEntry 12 }
vmCurMem OBJECT-TYPE
SYNTAX Integer32 (0..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current memory size currently allocated to the
virtual memory module in the unit designated by
vmMemUnit."
::= { vmEntry 13 }
vmMinMem OBJECT-TYPE
SYNTAX Integer32 (-1|0..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The minimum memory size defined to the virtual machine
in the unit designated by vmMemUnit. The value -1
indicates that there is no hard boundary for the minimum
memory size."
::= { vmEntry 14 }
vmMaxMem OBJECT-TYPE
SYNTAX Integer32 (-1|0..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The maximum memory size defined to the virtual machine
in the unit designated by vmMemUnit. The value -1
indicates that there is no limit."
::= { vmEntry 15 }
the memory and CPU columns are giving "-1 means no limit" vibes, so keep an eye on those little negatives π vmMemUnit is the multiplier that tells you whether vmCurMem, vmMinMem, and vmMaxMem are counting bytes, KiB, or whatever, and the example with 1024 β KiB is π so clean
okay bestie, we're picking up right where the vmUpTime vibes left off π¦
vmUpTime is the "how long has this VM been awake" counter β°. It's a TimeTicks value in centiseconds, and it counts from the last moment the admin state flipped from shutdown(4) to running(1). Iconic timekeeping π
vmUpTime OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The time (in centiseconds) since the administrative
state of the virtual machine was last changed from
shutdown(4) to running(1)."
::= { vmEntry 16 }
vmCpuTime OBJECT-TYPE
SYNTAX Counter64
UNITS "microsecond"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total CPU time used in microseconds. If the number
of virtual CPUs is larger than 1, vmCpuTime may exceed
real time.
Discontinuities in the value of this counter can occur
at re-initialization of the hypervisor and
administrative state (vmAdminState) changes of the
virtual machine."
::= { vmEntry 17 }
vmCpuTime is the total CPU time the VM has burned through, measured in microseconds π₯. Here's the twist: if the VM has more than one virtual CPU, this number can go past real time. Two cores working at once? Literally doing the most π. Also, this counter can jump around (a discontinuity) when the hypervisor restarts or when vmAdminState changes, so don't be shocked if it resets π
Next up is the virtual CPU table, which is basically the roster of every vCPU the hypervisor gave to a VM π
-- The virtual CPU on each virtual machines
vmCpuTable OBJECT-TYPE
SYNTAX SEQUENCE OF VmCpuEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The table of virtual CPUs provided by the hypervisor."
::= { vmObjects 5 }
vmCpuEntry OBJECT-TYPE
SYNTAX VmCpuEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry for one virtual processor assigned to a
virtual machine."
INDEX { vmIndex, vmCpuIndex }
::= { vmCpuTable 1 }
VmCpuEntry ::=
SEQUENCE {
vmCpuIndex VirtualMachineCpuIndex,
vmCpuCoreTime Counter64
}
vmCpuIndex OBJECT-TYPE
SYNTAX VirtualMachineCpuIndex
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A unique value identifying a virtual CPU assigned to
the virtual machine."
::= { vmCpuEntry 1 }
vmCpuCoreTime OBJECT-TYPE
SYNTAX Counter64
UNITS "microsecond"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total CPU time used by this virtual CPU in
microseconds.
Discontinuities in the value of this counter can occur
at re-initialization of the hypervisor and
administrative state (vmAdminState) changes of the
virtual machine."
::= { vmCpuEntry 2 }
So each row is one vCPU, indexed by vmIndex plus vmCpuIndex, and vmCpuCoreTime tracks that one vCPU's personal CPU time in microseconds. Same discontinuity drama applies here too π
Now for CPU affinity, which is about which physical CPU each virtual CPU is allowed to hang out on π§
-- The virtual CPU affinity on each virtual machines
vmCpuAffinityTable OBJECT-TYPE
SYNTAX SEQUENCE OF VmCpuAffinityEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A list of CPU affinity entries of a virtual CPU."
::= { vmObjects 6 }
vmCpuAffinityEntry OBJECT-TYPE
SYNTAX VmCpuAffinityEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry containing CPU affinity associated with a
particular virtual machine."
INDEX { vmIndex, vmCpuIndex, vmCpuPhysIndex }
::= { vmCpuAffinityTable 1 }
VmCpuAffinityEntry ::=
SEQUENCE {
vmCpuPhysIndex Integer32,
vmCpuAffinity INTEGER
}
vmCpuPhysIndex OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A value identifying a physical CPU on the hypervisor.
On systems implementing the HOST-RESOURCES-MIB, the
value MUST be the same value that is used as the index
in the hrProcessorTable (hrDeviceIndex)."
::= { vmCpuAffinityEntry 2 }
vmCpuAffinity OBJECT-TYPE
SYNTAX INTEGER {
unknown(0), -- unknown
enable(1), -- enabled
disable(2) -- disabled
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The CPU affinity of this virtual CPU to the physical
CPU represented by 'vmCpuPhysIndex'."
::= { vmCpuAffinityEntry 3 }
Each affinity row pairs a virtual CPU with a physical CPU on the hypervisor, and vmCpuAffinity says whether that pairing is unknown(0), enable(1) or disable(2) π. On systems that also run the HOST-RESOURCES-MIB, vmCpuPhysIndex has to match the hrProcessorTable index (hrDeviceIndex) exactly. No freelancing on the index, periodt π
Last but definitely not least: the virtual storage devices. This part gets a little overlapped with hrStorage, because virtual disks are carved out of the hypervisor's own resources, which is the "host resources" π
-- The virtual storage devices on each virtual machine. This
-- document defines some overlapped objects with hrStorage in
-- HOST-RESOURCES-MIB (RFC 2790), because virtual resources are
-- allocated from the hypervisor's resources, which is the 'host
-- resources'.
vmStorageTable OBJECT-TYPE
SYNTAX SEQUENCE OF VmStorageEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The conceptual table of virtual storage devices
attached to the virtual machine."
::= { vmObjects 7 }
vmStorageEntry OBJECT-TYPE
SYNTAX VmStorageEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry for one virtual storage device attached to the
virtual machine."
INDEX { vmStorageVmIndex, vmStorageIndex }
::= { vmStorageTable 1 }
VmStorageEntry ::=
SEQUENCE {
vmStorageVmIndex VirtualMachineIndexOrZero,
vmStorageIndex VirtualMachineStorageIndex,
vmStorageParent Integer32,
vmStorageSourceType VirtualMachineStorageSourceType,
vmStorageSourceTypeString
SnmpAdminString,
vmStorageResourceID SnmpAdminString,
vmStorageAccess VirtualMachineStorageAccess,
vmStorageMediaType IANAStorageMediaType,
vmStorageMediaTypeString
SnmpAdminString,
vmStorageSizeUnit Integer32,
vmStorageDefinedSize Integer32,
vmStorageAllocatedSize Integer32,
vmStorageReadIOs Counter64,
vmStorageWriteIOs Counter64,
vmStorageReadOctets Counter64,
vmStorageWriteOctets Counter64,
vmStorageReadLatency Counter64,
vmStorageWriteLatency Counter64
}
vmStorageVmIndex OBJECT-TYPE
SYNTAX VirtualMachineIndexOrZero
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This value identifies the virtual machine (guest) this
storage device has been allocated to. The value zero
indicates that the storage device is currently not
allocated to any virtual machines."
::= { vmStorageEntry 1 }
vmStorageIndex OBJECT-TYPE
SYNTAX VirtualMachineStorageIndex
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A unique value identifying a virtual storage device
allocated to the virtual machine."
::= { vmStorageEntry 2 }
vmStorageParent OBJECT-TYPE
SYNTAX Integer32 (0..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of hrStorageIndex, which is the parent (i.e.,
physical) device of this virtual device on systems
implementing the HOST-RESOURCES-MIB. The value zero
denotes this virtual device is not any child
represented in the hrStorageTable."
::= { vmStorageEntry 3 }
vmStorageSourceType OBJECT-TYPE
SYNTAX VirtualMachineStorageSourceType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The source type of the virtual storage device."
::= { vmStorageEntry 4 }
vmStorageSourceTypeString OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (0..255))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A (detailed) textual string of the source type of the
virtual storage device. For example, this represents
the specific format name of the sparse file."
::= { vmStorageEntry 5 }
vmStorageResourceID OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (0..255))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A textual string that represents the resource
identifier of the virtual storage. For example, this
contains the path to the disk image file that
corresponds to the virtual storage."
::= { vmStorageEntry 6 }
vmStorageAccess OBJECT-TYPE
SYNTAX VirtualMachineStorageAccess
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The access permission of the virtual storage device."
::= { vmStorageEntry 7 }
vmStorageMediaType OBJECT-TYPE
SYNTAX IANAStorageMediaType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The media type of the virtual storage device."
::= { vmStorageEntry 8 }
vmStorageMediaTypeString OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (0..255))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A (detailed) textual string of the virtual storage
media. For example, this represents the specific driver
name of the emulated media such as 'IDE' and 'SCSI'."
::= { vmStorageEntry 9 }
vmStorageSizeUnit OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The multiplication unit in bytes for
vmStorageDefinedSize and vmStorageAllocatedSize. For
example, when this value is 1048576, the storage size
unit for vmStorageDefinedSize and vmStorageAllocatedSize
is MiB."
::= { vmStorageEntry 10 }
vmStorageDefinedSize OBJECT-TYPE
SYNTAX Integer32 (-1|0..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The defined virtual storage size defined in the unit
designated by vmStorageSizeUnit. If this information is
not available, this value MUST be -1."
::= { vmStorageEntry 11 }
vmStorageAllocatedSize OBJECT-TYPE
SYNTAX Integer32 (-1|0..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The storage size allocated to the virtual storage from
a physical storage in the unit designated by
vmStorageSizeUnit. When the virtual storage is block
device or raw file, this value and vmStorageDefinedSize
are supposed to equal. This value MUST NOT be different
from vmStorageDefinedSize when vmStorageSourceType is
'block' or 'raw'. If this information is not available,
this value MUST be -1."
::= { vmStorageEntry 12 }
vmStorageReadIOs OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of read I/O requests.
Discontinuities in the value of this counter can occur
at re-initialization of the hypervisor and
administrative state (vmAdminState) changes of the
virtual machine."
::= { vmStorageEntry 13 }
vmStorageWriteIOs OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of write I/O requests.
Discontinuities in the value of this counter can occur
at re-initialization of the hypervisor and
administrative state (vmAdminState) changes of the
virtual machine."
::= { vmStorageEntry 14 }
Okay bestie, we're still inside the VM-MIB definitions, and now we're on the storage counters πΎβ¨ These track how much data a virtual disk reads and writes, plus how long those requests sat in line π«Ά
vmStorageReadOctets OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of bytes read from this device.
Discontinuities in the value of this counter can occur
at re-initialization of the hypervisor and
administrative state (vmAdminState) changes of the
virtual machine."
::= { vmStorageEntry 15 }
vmStorageWriteOctets OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of bytes written to this device.
Discontinuities in the value of this counter can occur
at re-initialization of the hypervisor and
administrative state (vmAdminState) changes of the
virtual machine."
::= { vmStorageEntry 16 }
Both of these are Counter64 objects, so they can get really, really big π The discontinuity note is the thing to remember: the count can jump at a hypervisor re-initialization or when vmAdminState changes for the VM π
vmStorageReadLatency OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of microseconds read requests have
been queued for this device.
This would typically be implemented by storing the high
precision system timestamp of when the request is
received from the virtual machine with the request, the
difference between this initial timestamp and the time
at which the requested operation has completed SHOULD be
converted to microseconds and accumulated.
Discontinuities in the value of this counter can occur at
re-initialization of the hypervisor and administrative
state (vmAdminState) changes of the virtual machine."
::= { vmStorageEntry 17 }
vmStorageWriteLatency OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of microseconds write requests have
been queued for this device.
This would typically be implemented by storing the high
precision system timestamp of when the request is
received from the virtual machine with the request; the
difference between this initial timestamp and the time
at which the requested operation has completed SHOULD be
converted to microseconds and accumulated.
Discontinuities in the value of this counter can occur
at re-initialization of the hypervisor and
administrative state (vmAdminState) changes of the
virtual machine."
::= { vmStorageEntry 18 }
The latency pair is a little more fun π The typical approach is to stamp the request the moment it arrives from the VM, then subtract that from the time the operation finishes, convert the result to microseconds, and keep adding it up. The text gives this as a recommendation rather than a hard rule, so it's a best-practice vibe, not a must-do π
-- The virtual network interfaces on each virtual machine.
vmNetworkTable OBJECT-TYPE
SYNTAX SEQUENCE OF VmNetworkEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The conceptual table of virtual network interfaces
attached to the virtual machine."
::= { vmObjects 8 }
vmNetworkEntry OBJECT-TYPE
SYNTAX VmNetworkEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry for one virtual network interface attached to
the virtual machine."
INDEX { vmIndex, vmNetworkIndex }
::= { vmNetworkTable 1 }
VmNetworkEntry ::=
SEQUENCE {
vmNetworkIndex VirtualMachineNetworkIndex,
vmNetworkIfIndex InterfaceIndexOrZero,
vmNetworkParent InterfaceIndexOrZero,
vmNetworkModel SnmpAdminString,
vmNetworkPhysAddress PhysAddress
}
vmNetworkIndex OBJECT-TYPE
SYNTAX VirtualMachineNetworkIndex
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A unique value identifying a virtual network interface
allocated to the virtual machine."
::= { vmNetworkEntry 1 }
vmNetworkIfIndex OBJECT-TYPE
SYNTAX InterfaceIndexOrZero
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of ifIndex, which corresponds to this virtual
network interface. If this device is not represented in
the ifTable, then this value MUST be zero."
::= { vmNetworkEntry 2 }
vmNetworkParent OBJECT-TYPE
SYNTAX InterfaceIndexOrZero
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of ifIndex, which corresponds to the parent
(i.e., physical) device of this virtual device. The
value zero denotes this virtual device is not any
child represented in the ifTable."
::= { vmNetworkEntry 3 }
vmNetworkModel OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (0..255))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A textual string containing the (emulated) model of the
virtual network interface. For example, this value is
'virtio' when the emulation driver model is virtio."
::= { vmNetworkEntry 4 }
vmNetworkPhysAddress OBJECT-TYPE
SYNTAX PhysAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The Media Access Control (MAC) address of the virtual
network interface."
::= { vmNetworkEntry 5 }
Now the network side π¦ Every VM gets a table of virtual NICs, and each row is one interface, keyed by the VM index plus its own network index. The fun rule here is vmNetworkIfIndex: if the virtual NIC doesn't show up in the ifTable, its value has to be zero π§ vmNetworkParent is the same idea but for the physical device behind it, and zero means there's no child in the ifTable. And vmNetworkModel is just a little label, like 'virtio' π
-- Notification definitions:
vmPerVMNotificationsEnabled OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Indicates if the notification generator will send
notifications per virtual machine. Changes to this
object MUST NOT persist across re-initialization of
the management system, e.g., SNMP agent."
::= { vmObjects 9 }
vmBulkNotificationsEnabled OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Indicates if the notification generator will send
notifications per set of virtual machines. Changes to
this object MUST NOT persist across re-initialization of
the management system, e.g., SNMP agent."
::= { vmObjects 10 }
vmAffectedVMs OBJECT-TYPE
SYNTAX VirtualMachineList
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"A complete list of virtual machines whose state has
changed. This object is the only object sent with bulk
notifications."
::= { vmObjects 11 }
Notification time π Two toggles control whether you get per-VM or bulk notifications, and neither of them sticks around once the management system restarts, like an SNMP agent reboot π₯Ί vmAffectedVMs is the list of every VM whose state changed, and it's the only object that rides along with bulk notifications π
vmRunning NOTIFICATION-TYPE
OBJECTS {
vmName,
vmUUID,
vmOperState
}
STATUS current
DESCRIPTION
"This notification is generated when the operational
state of a virtual machine has been changed to
running(4) from some other state. The other state is
indicated by the included value of vmOperState."
::= { vmNotifications 1 }
vmShuttingdown NOTIFICATION-TYPE
OBJECTS {
vmName,
vmUUID,
vmOperState
}
STATUS current
DESCRIPTION
"This notification is generated when the operational
state of a virtual machine has been changed to
shuttingdown(10) from some other state. The other state
is indicated by the included value of vmOperState."
::= { vmNotifications 2 }
vmShutdown NOTIFICATION-TYPE
OBJECTS {
vmName,
vmUUID,
vmOperState
}
STATUS current
DESCRIPTION
"This notification is generated when the operational
state of a virtual machine has been changed to
shutdown(11) from some other state. The other state is
indicated by the included value of vmOperState."
::= { vmNotifications 3 }
vmPaused NOTIFICATION-TYPE
OBJECTS {
vmName,
vmUUID,
vmOperState
}
STATUS current
DESCRIPTION
"This notification is generated when the operational
state of a virtual machine has been changed to
paused(8) from some other state. The other state is
indicated by the included value of vmOperState."
::= { vmNotifications 4 }
vmSuspending NOTIFICATION-TYPE
OBJECTS {
vmName,
vmUUID,
vmOperState
}
STATUS current
DESCRIPTION
"This notification is generated when the operational
state of a virtual machine has been changed to
suspending(5) from some other state. The other state is
indicated by the included value of vmOperState."
::= { vmNotifications 5 }
vmSuspended NOTIFICATION-TYPE
OBJECTS {
vmName,
vmUUID,
vmOperState
}
STATUS current
DESCRIPTION
"This notification is generated when the operational
state of a virtual machine has been changed to
suspended(6) from some other state. The other state is
indicated by the included value of vmOperState."
::= { vmNotifications 6 }
vmResuming NOTIFICATION-TYPE
OBJECTS {
vmName,
vmUUID,
vmOperState
}
STATUS current
DESCRIPTION
"This notification is generated when the operational
state of a virtual machine has been changed to
resuming(7) from some other state. The other state is
indicated by the included value of vmOperState."
::= { vmNotifications 7 }
vmMigrating NOTIFICATION-TYPE
OBJECTS {
vmName,
vmUUID,
vmOperState
}
STATUS current
DESCRIPTION
"This notification is generated when the operational
state of a virtual machine has been changed to
migrating(9) from some other state. The other state is
indicated by the included value of vmOperState."
::= { vmNotifications 8 }
vmCrashed NOTIFICATION-TYPE
OBJECTS {
vmName,
vmUUID,
vmOperState
}
STATUS current
DESCRIPTION
"This notification is generated when a virtual machine
has been crashed. The previous state of the virtual
machine is indicated by the included value of
vmOperState."
::= { vmNotifications 9 }
The notification types are basically a lineup of "the VM just changed state" alerts π¨ Each one fires when a VM moves into a particular operational state, like running(4), paused(8), or migrating(9), and carries vmName, vmUUID, and vmOperState so you know who it is and where it came from. vmCrashed is the odd one out: it's the crash alert, and it tells you the previous state through vmOperState πβ¨
vmDeleted NOTIFICATION-TYPE OBJECTS { vmName, vmUUID, vmOperState, vmPersistent } STATUS current DESCRIPTION "This notification is generated when a virtual machine has been deleted. The prior state of the virtual machine is indicated by the included value of vmOperState." ::= { vmNotifications 10 }
vmBulkRunning NOTIFICATION-TYPE OBJECTS { vmAffectedVMs
} STATUS current DESCRIPTION "This notification is generated when the operational state of one or more virtual machines has been changed to running(4) from any prior state, except for running(4). Management stations are encouraged to subsequently poll the subset of virtual machines of interest for vmOperState." ::= { vmNotifications 11 }
vmBulkShuttingdown NOTIFICATION-TYPE OBJECTS { vmAffectedVMs } STATUS current DESCRIPTION "This notification is generated when the operational state of one or more virtual machines has been changed to shuttingdown(10) from a state other than shuttingdown(10). Management stations are encouraged to subsequently poll the subset of virtual machines of interest for vmOperState." ::= { vmNotifications 12 }
vmBulkShutdown NOTIFICATION-TYPE OBJECTS { vmAffectedVMs } STATUS current DESCRIPTION "This notification is generated when the operational state of one or more virtual machine has been changed to shutdown(11) from a state other than shutdown(11). Management stations are encouraged to subsequently poll the subset of virtual machines of interest for vmOperState." ::= { vmNotifications 13 }
vmBulkPaused NOTIFICATION-TYPE OBJECTS { vmAffectedVMs } STATUS current DESCRIPTION "This notification is generated when the operational state of one or more virtual machines has been changed to paused(8) from a state other than paused(8).
Management stations are encouraged to subsequently poll the subset of virtual machines of interest for vmOperState." ::= { vmNotifications 14 }
vmBulkSuspending NOTIFICATION-TYPE OBJECTS { vmAffectedVMs } STATUS current DESCRIPTION "This notification is generated when the operational state of one or more virtual machines has been changed to suspending(5) from a state other than suspending(5). Management stations are encouraged to subsequently poll the subset of virtual machines of interest for vmOperState." ::= { vmNotifications 15 }
vmBulkSuspended NOTIFICATION-TYPE OBJECTS { vmAffectedVMs } STATUS current DESCRIPTION "This notification is generated when the operational state of one or more virtual machines has been changed to suspended(6) from a state other than suspended(6). Management stations are encouraged to subsequently poll the subset of virtual machines of interest for vmOperState." ::= { vmNotifications 16 }
vmBulkResuming NOTIFICATION-TYPE OBJECTS { vmAffectedVMs } STATUS current DESCRIPTION "This notification is generated when the operational state of one or more virtual machines has been changed to resuming(7) from a state other than resuming(7). Management stations are encouraged to subsequently poll the subset of virtual machines of interest for vmOperState." ::= { vmNotifications 17 }
vmBulkMigrating NOTIFICATION-TYPE
OBJECTS { vmAffectedVMs } STATUS current DESCRIPTION "This notification is generated when the operational state of one or more virtual machines has been changed to migrating(9) from a state other than migrating(9). Management stations are encouraged to subsequently poll the subset of virtual machines of interest for vmOperState." ::= { vmNotifications 18 }
vmBulkCrashed NOTIFICATION-TYPE OBJECTS { vmAffectedVMs } STATUS current DESCRIPTION "This notification is generated when one or more virtual machines have been crashed. Management stations are encouraged to subsequently poll the subset of virtual machines of interest for vmOperState." ::= { vmNotifications 19 }
vmBulkDeleted NOTIFICATION-TYPE OBJECTS { vmAffectedVMs } STATUS current DESCRIPTION "This notification is generated when one or more virtual machines have been deleted. Management stations are encouraged to subsequently poll the subset of virtual machines of interest for vmOperState." ::= { vmNotifications 20 }
-- Compliance definitions: vmCompliances OBJECT IDENTIFIER ::= { vmConformance 1 } vmGroups OBJECT IDENTIFIER ::= { vmConformance 2 }
vmFullCompliances MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance statement for implementations supporting read/write access, according to the object definitions." MODULE -- this module MANDATORY-GROUPS {
vmHypervisorGroup, vmVirtualMachineGroup, vmCpuGroup, vmCpuAffinityGroup, vmStorageGroup, vmNetworkGroup } GROUP vmPerVMNotificationOptionalGroup DESCRIPTION "Support for per-VM notifications is optional. If not implemented, then vmPerVMNotificationsEnabled MUST report false(2)." GROUP vmBulkNotificationsVariablesGroup DESCRIPTION "Necessary only if vmPerVMNotificationOptionalGroup is implemented." GROUP vmBulkNotificationOptionalGroup DESCRIPTION "Support for bulk notifications is optional. If not implemented, then vmBulkNotificationsEnabled MUST report false(2)."
::= { vmCompliances 1 }
vmReadOnlyCompliances MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance statement for implementations supporting only read-only access." MODULE -- this module MANDATORY-GROUPS { vmHypervisorGroup, vmVirtualMachineGroup, vmCpuGroup, vmCpuAffinityGroup, vmStorageGroup, vmNetworkGroup }
OBJECT vmPerVMNotificationsEnabled MIN-ACCESS read-only DESCRIPTION "Write access is not required."
OBJECT vmBulkNotificationsEnabled MIN-ACCESS read-only DESCRIPTION "Write access is not required."
::= { vmCompliances 2 }
vmHypervisorGroup OBJECT-GROUP OBJECTS { vmHvSoftware, vmHvVersion, vmHvObjectID, vmHvUpTime, vmNumber, vmTableLastChange, vmPerVMNotificationsEnabled, vmBulkNotificationsEnabled } STATUS current DESCRIPTION "A collection of objects providing insight into the hypervisor itself." ::= { vmGroups 1 }
vmVirtualMachineGroup OBJECT-GROUP OBJECTS { -- vmIndex vmName, vmUUID, vmOSType, vmAdminState, vmOperState, vmAutoStart, vmPersistent, vmCurCpuNumber, vmMinCpuNumber, vmMaxCpuNumber, vmMemUnit, vmCurMem, vmMinMem, vmMaxMem, vmUpTime, vmCpuTime } STATUS current DESCRIPTION "A collection of objects providing insight into the virtual machines controlled by a hypervisor." ::= { vmGroups 2 }
vmCpuGroup OBJECT-GROUP OBJECTS { -- vmCpuIndex, vmCpuCoreTime } STATUS current DESCRIPTION "A collection of objects providing insight into the virtual machines controlled by a hypervisor." ::= { vmGroups 3 }
vmCpuAffinityGroup OBJECT-GROUP OBJECTS { -- vmCpuPhysIndex, vmCpuAffinity } STATUS current DESCRIPTION "A collection of objects providing insight into the virtual machines controlled by a hypervisor." ::= { vmGroups 4 }
vmStorageGroup OBJECT-GROUP OBJECTS { -- vmStorageVmIndex, -- vmStorageIndex, vmStorageParent, vmStorageSourceType, vmStorageSourceTypeString, vmStorageResourceID, vmStorageAccess, vmStorageMediaType, vmStorageMediaTypeString, vmStorageSizeUnit, vmStorageDefinedSize, vmStorageAllocatedSize, vmStorageReadIOs, vmStorageWriteIOs, vmStorageReadOctets, vmStorageWriteOctets, vmStorageReadLatency, vmStorageWriteLatency } STATUS current DESCRIPTION "A collection of objects providing insight into the virtual storage devices controlled by a hypervisor." ::= { vmGroups 5 }
vmNetworkGroup OBJECT-GROUP OBJECTS {
-- vmNetworkIndex, vmNetworkIfIndex, vmNetworkParent, vmNetworkModel, vmNetworkPhysAddress } STATUS current DESCRIPTION "A collection of objects providing insight into the virtual network interfaces controlled by a hypervisor." ::= { vmGroups 6 }
vmPerVMNotificationOptionalGroup NOTIFICATION-GROUP NOTIFICATIONS { vmRunning, vmShuttingdown, vmShutdown, vmPaused, vmSuspending, vmSuspended, vmResuming, vmMigrating, vmCrashed, vmDeleted } STATUS current DESCRIPTION "A collection of notifications for per-VM notification of changes to virtual machine state (vmOperState) as reported by a hypervisor." ::= { vmGroups 7 }
vmBulkNotificationsVariablesGroup OBJECT-GROUP OBJECTS { vmAffectedVMs } STATUS current DESCRIPTION "The variables used in vmBulkNotificationOptionalGroup virtual network interfaces controlled by a hypervisor." ::= { vmGroups 8 }
vmBulkNotificationOptionalGroup NOTIFICATION-GROUP
NOTIFICATIONS {
vmBulkRunning,
vmBulkShuttingdown,
vmBulkShutdown,
vmBulkPaused,
vmBulkSuspending,
vmBulkSuspended,
vmBulkResuming,
vmBulkMigrating,
vmBulkCrashed,
vmBulkDeleted
}
STATUS current
DESCRIPTION
"A collection of notifications for bulk notification of
changes to virtual machine state (vmOperState) as
reported by a given hypervisor."
::= { vmGroups 9 }
END
6.2. IANA-STORAGE-MEDIA-TYPE-MIB β¨
okay so this is the one that IANA looks after, bestie π It defines the textual convention for the media type of a storage device, and it's the first version of the module, published as RFC 7666 πΈ
IANA-STORAGE-MEDIA-TYPE-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, mib-2
FROM SNMPv2-SMI
TEXTUAL-CONVENTION
FROM SNMPv2-TC;
ianaStorageMediaTypeMIB MODULE-IDENTITY
LAST-UPDATED "201510120000Z" -- 12 October 2015
ORGANIZATION "IANA"
CONTACT-INFO
"Internet Assigned Numbers Authority
Postal: ICANN
12025 Waterfront Drive, Suite 300
Los Angeles, CA 90094-2536
United States
Tel: +1 310-301-5800
Email: iana@iana.org"
DESCRIPTION
"This MIB module defines Textual Conventions
representing the media type of a storage device.
Copyright (c) 2015 IETF Trust and the persons identified
as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with
or without modification, is permitted pursuant to, and
subject to the license terms contained in, the
Simplified BSD License set forth in Section 4.c of the
IETF Trust's Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info)."
REVISION "201510120000Z" -- 12 October 2015
DESCRIPTION
"The initial version of this MIB, published as
RFC 7666."
::= { mib-2 237 }
IANAStorageMediaType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The media type of a storage device:
unknown(1) The media type is unknown, e.g., because
the implementation failed to obtain the
media type from the hypervisor.
other(2) The media type is other than those
defined in this conversion.
hardDisk(3) The media type is hard disk.
opticalDisk(4) The media type is optical disk.
floppyDisk(5) The media type is floppy disk."
SYNTAX INTEGER {
other(1),
unknown(2),
hardDisk(3),
opticalDisk(4),
floppyDisk(5)
}
END
7. IANA Considerations π
okay so the IANA-STORAGE-MEDIA-TYPE-MIB module is the IANA-maintained one, and it's the reason new storage media types can get added to the enumeration in IANAStorageMediaType π§ Each change goes through an Expert Review, as defined in RFC 5226 [RFC5226], and that review is REQUIRED for every modification π₯
This MIB module also uses two OBJECT IDENTIFIER values that IANA recorded in the SMI Numbers registry π
Descriptor OBJECT IDENTIFIER value
---------- -----------------------
vmMIB { mib-2 236 }
ianaStorageMediaTypeMIB { mib-2 237 }
8. Security Considerations π
ngl this section is so important, bestie π This MIB module is typically implemented on the hypervisor, not inside a virtual machine. Virtual machines, possibly under other administrative domains, would not have access to this MIB, since the SNMP service would typically run in a separate management network πΈ
Two objects in here, vmPerVMNotificationsEnabled and vmBulkNotificationsEnabled, have a MAX-ACCESS clause of read-write. Turning notifications on can lead to a substantial number of notifications if lots of virtual machines change state at the same time, so these objects may be considered sensitive or vulnerable in some network environments π Supporting SET operations in a non-secure environment without proper protection can have a negative effect on the management system. So it is RECOMMENDED that these objects have access of read-only instead of read-write on deployments where SNMPv3 strong security (i.e., authentication and encryption) is not used π«Ά
There are a lot of managed objects in this MIB that may hold sensitive information, so be careful π
The objects in vmHvSoftware and vmHvVersion list information about the hypervisor's software and version. Some people may not want others to know which software they're running, and an inventory of running software and versions could help an attacker who is hoping to exploit software bugs in certain applications π The objects in the vmTable, vmCpuTable, vmCpuAffinityTable, vmStorageTable, and vmNetworkTable list information about the virtual machines and their virtual resource allocation. Some folks may not want others to know how many virtual machines they run, or what they are π«£
So it is important to control even GET access to these objects, and possibly even to encrypt their values when they're sent over the network via SNMP. Not every version of SNMP has features for a secure environment, though π
SNMPv1 by itself is not a secure environment π Even if the network itself is secure (for example, by using IPsec), there is no control over who on that secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module π€
It is recommended that implementers consider using the security features provided by the SNMPv3 framework β¨ Specifically, the use of the User-based Security Model [RFC3414] and the View-based Access Control Model [RFC3415] is recommended π¦
And then it's a customer or user responsibility to make sure that the SNMP entity giving access to an instance of this MIB is properly configured, so the objects are only available to principals (users) who have legitimate rights to GET or SET (change/create/delete) them π
9. References π
9.1. Normative References
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI
10.17487/RFC2119, March 1997,<http://www.rfc-editor.org/info/rfc2119>. - [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, DOI
10.17487/RFC2578, April 1999,<http://www.rfc-editor.org/info/rfc2578>. - [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, DOI
10.17487/RFC2579, April 1999,<http://www.rfc-editor.org/info/rfc2579>. - [RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Conformance Statements for SMIv2", STD 58, RFC 2580, DOI
10.17487/RFC2580, April 1999,<http://www.rfc-editor.org/info/rfc2580>. - [RFC2790] Waldbusser, S. and P. Grillo, "Host Resources MIB", RFC 2790, DOI
10.17487/RFC2790, March 2000,<http://www.rfc-editor.org/info/rfc2790>. - [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, DOI
10.17487/RFC2863, June 2000,<http://www.rfc-editor.org/info/rfc2863>. - [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, DOI
10.17487/RFC3413, December 2002,<http://www.rfc-editor.org/info/rfc3413>. - [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, DOI
10.17487/RFC3414, December 2002,<http://www.rfc-editor.org/info/rfc3414>. - [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, DOI
10.17487/RFC3415, December 2002,<http://www.rfc-editor.org/info/rfc3415>. - [RFC3418] Presuhn, R., Ed., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, DOI
10.17487/RFC3418, December 2002,<http://www.rfc-editor.org/info/rfc3418>. - [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI
10.17487/RFC5226, May 2008,<http://www.rfc-editor.org/info/rfc5226>. - [RFC6933] Bierman, A., Romascanu, D., Quittek, J., and M. Chandramouli, "Entity MIB (Version 4)", RFC 6933, DOI
10.17487/RFC6933, May 2013,<http://www.rfc-editor.org/info/rfc6933>.
9.2. Informative References
- [IEEE8021-BRIDGE-MIB] IEEE, "IEEE8021-BRIDGE-MIB", October 2008,
<http://www.ieee802.org/1/files/public/MIBs/IEEE8021-BRIDGE-MIB-200810150000Z.txt>. - [IEEE8021-Q-BRIDGE-MIB] IEEE, "IEEE8021-Q-BRIDGE-MIB", October 2008,
<http://www.ieee802.org/1/files/public/MIBs/IEEE8021-Q-BRIDGE-MIB-200810150000Z.txt>. - [libvirt] The libvirt developers, "The libvirt virtialization API",
<http://www.libvirt.org/>. - [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, DOI
10.17487/RFC3410, December 2002,<http://www.rfc-editor.org/info/rfc3410>. - [VMware] VMware, Inc., "The VMware Hypervisor",
<http://www.vmware.com/>. - [Xen] The Xen Project, "The Xen Hypervisor",
<http://www.xenproject.org/>.
Appendix A. State Transition Table π¦
okay so this table is the whole vibe for vmOperState π
each row is a state, what makes it change (the hypervisor doing something or an event happening), where it lands next, and which notification goes out. the notifications come in pairs, one for the single VM and one for the bulk version π§
+--------------+----------------+--------------+--------------------+
| State | Change to | Next State | Notification |
| | vmAdminState | | |
| | at the | | |
| | hypervisor or | | |
| | (Event) | | |
+--------------+----------------+--------------+--------------------+
| suspended | running | resuming | vmResuming | |
| | | | vmBulkResuming |
| | | | |
| suspending | (suspend | suspended | vmSuspended | |
| | operation | | vmBulkSuspended |
| | completed) | | |
| | | | |
| running | suspended | suspending | vmSuspending | |
| | | | vmBulkSuspending |
| | | | |
| | shutdown | shuttingdown | vmShuttingdown | |
| | | | vmBulkShuttingdown |
| | | | |
| | (migration to | migrating | vmMigrating | |
| | other | | vmBulkMigrating |
| | hypervisor | | |
| | initiated) | | |
| | | | |
| resuming | (resume | running | vmRunning | |
| | operation | | vmBulkRunning |
| | completed) | | |
| | | | |
| paused | running | running | vmRunning | |
| | | | vmBulkRunning |
| | | | |
| shuttingdown | (shutdown | shutdown | vmShutdown | |
| | operation | | vmBulkShutdown |
| | completed) | | |
| | | | |
| shutdown | running | running | vmRunning | |
| | | | vmBulkRunning |
| | | | |
| | (if this state | migrating | vmMigrating | |
| | entry is | | vmBulkMigrating |
| | created by a | | |
| | migration | | |
| | operation (*) | | |
| | | | |
| | (deletion | (no state) | vmDeleted | |
| | operation | | vmBulkDeleted |
| | completed) | | |
| | | | |
| migrating | (migration | running | vmRunning | |
| | from other | | vmBulkRunning |
| | hypervisor | | |
| | completed) | | |
| | | | |
| | (migration to | shutdown | vmShutdown | |
| | other | | vmBulkShutdown |
| | hypervisor | | |
| | completed) | | |
| | | | |
| preparing | (preparation | shutdown | vmShutdown | |
| | completed) | | vmBulkShutdown |
| | | | |
| crashed | - | - | - |
| | | | |
| | (crashed) | crashed | vmCrashed | |
| | | | vmBulkCrashed |
| | | | |
| (no state) | (preparation | preparing | - |
| | initiated) | | |
| | | | |
| | (migrate from | shutdown (*) | vmShutdown | |
| | other | | vmBulkShutdown |
| | hypervisor | | |
| | initiated) | | |
+--------------+----------------+--------------+--------------------+
State Transition Table for vmOperState
Acknowledgements π
big thank you bundle to Andy Bierman, David Black, Joe Marcus Clarke, C.M. Heard, Joel Jaeggli, Tom Petch, Randy Presuhn, and Ian West π«Ά they gave helpful comments while this spec was being built, and honestly that's so iconic of them πΈ
Juergen Schoenwaelder's work was partly funded by Flamingo, a Network of Excellence project (ICT-318488) supported by the European Commission under its Seventh Framework Programme π
Contributors π
these are the people who contributed to the document π
Yuji Sekiya
The University of Tokyo
2-11-16 Yayoi
Bunkyo-ku, Tokyo 113-8658
Japan
Email: sekiya@wide.ad.jp
Cathy Zhou
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
China
Email: cathyzhou@huawei.com
Hiroshi Esaki
The University of Tokyo
7-3-1 Hongo
Bunkyo-ku, Tokyo 113-8656
Japan
Email: hiroshi@wide.ad.jp
Authors' Addresses π¦
and here are the authors, where to find them, and how to reach them π¬β¨
Hirochika Asai
The University of Tokyo
7-3-1 Hongo
Bunkyo-ku, Tokyo 113-8656
Japan
Phone: +81 3 5841 6748
Email: panda@hongo.wide.ad.jp
Michael MacFaden
VMware Inc.
Email: mrm@vmware.com
Juergen Schoenwaelder
Jacobs University
Campus Ring 1
Bremen 28759
Germany
Email: j.schoenwaelder@jacobs-university.de
Keiichi Shima
IIJ Innovation Institute Inc.
2-10-2 Fujimi
Chiyoda-ku, Tokyo 102-0071
Japan
Email: keiichi@iijlab.net
Tina Tsou
Huawei Technologies (USA)
2330 Central Expressway
Santa Clara, CA 95050
United States
Email: tina.tsou.zouting@huawei.com
that's the whole document, bestie ππ β¨ every state, every notification, every name is right where it belongs π
π¦ where this page comes from
- ietf: rfc7666 2015-10
- π girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms