< draft-schoenw-opsawg-vm-mib-00.txt		draft-schoenw-opsawg-vm-mib-01.txt >
	Internet Engineering Task Force J. Schoenwaelder		Internet Engineering Task Force M. MacFaden
	Internet-Draft Jacobs University		Internet-Draft VMware Inc.
	Intended status: Standards Track T. Tsou		Intended status: Standards Track J. Schoenwaelder
	Expires: September 6, 2012 Huawei Technologies (USA)		Expires: January 17, 2013 Jacobs University
			T. Tsou
			Huawei Technologies (USA)
	C. Zhou		C. Zhou
	Huawei Technologies		Huawei Technologies
	March 5, 2012		July 16, 2012
	Definition of Managed Objects for Virtual Machines Controlled by a		Definition of Managed Objects for Virtual Machines Controlled by a
	Hypervisor		Hypervisor
	draft-schoenw-opsawg-vm-mib-00		draft-schoenw-opsawg-vm-mib-01
	Abstract		Abstract
	This memo defines a portion of the Management Information Base (MIB)		This memo defines a portion of the Management Information Base (MIB)
	for use with network management protocols in the Internet community.		for use with network management protocols in the Internet community.
	In particular, it defines objects for managing virtual machines		In particular, it defines objects for managing virtual machines
	controlled by a hypervisor.		controlled by a hypervisor.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 39 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on September 6, 2012.		This Internet-Draft will expire on January 17, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 15 ¶		skipping to change at page 2, line 17 ¶
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. The Internet-Standard Management Framework . . . . . . . . . . 3		2. The Internet-Standard Management Framework . . . . . . . . . . 3
	3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
	4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3		4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	5. Relationship to Other MIB Modules . . . . . . . . . . . . . . 4		5. Relationship to Other MIB Modules . . . . . . . . . . . . . . 4
	6. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5		5.1. Relationship to the HOST-RESOURCES-MIB . . . . . . . . . . 5
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 18		5.2. Relationship to the IF-MIB . . . . . . . . . . . . . . . . 5
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19		5.3. Relationship to the IEEE8021-BRIDGE-MIB . . . . . . . . . 5
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19		5.4. Relationship to the ENTITY-MIB . . . . . . . . . . . . . . 5
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 19		6. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6
	9.2. Informative References . . . . . . . . . . . . . . . . . . 19		7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
			8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
			9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
			10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
			10.1. Normative References . . . . . . . . . . . . . . . . . . . 20
			10.2. Informative References . . . . . . . . . . . . . . . . . . 21
			Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 21
	1. Introduction		1. Introduction
	This memo defines a portion of the Management Information Base (MIB)		This memo defines a portion of the Management Information Base (MIB)
	for use with network management protocols. In particular, it defines		for use with network management protocols. In particular, it defines
	objects for managing virtual machines controlled by a hypervisor.		objects for managing virtual machines controlled by a hypervisor.
	The design of this MIB module has been derived from enterprise		The design of this MIB module has been derived from enterprise
	specific MIB modules, namely a MIB module for managing guests of the		specific MIB modules, namely a MIB module for managing guests of the
	XEN hypervisor, a MIB module for managing virtual machines controlled		XEN hypervisor, a MIB module for managing virtual machines controlled
	skipping to change at page 3, line 35 ¶		skipping to change at page 3, line 35 ¶
	accessed through the Simple Network Management Protocol (SNMP).		accessed through the Simple Network Management Protocol (SNMP).
	Objects in the MIB are defined using the mechanisms defined in the		Objects in the MIB are defined using the mechanisms defined in the
	Structure of Management Information (SMI). This memo specifies a MIB		Structure of Management Information (SMI). This memo specifies a MIB
	module that is compliant to the SMIv2, which is described in STD 58,		module that is compliant to the SMIv2, which is described in STD 58,
	RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580		RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
	[RFC2580].		[RFC2580].
	3. Conventions		3. Conventions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	document are to be interpreted as described in RFC 2119 [RFC2119].		"OPTIONAL" in this document are to be interpreted as described in RFC
			2119 [RFC2119].
	4. Overview		4. Overview
	The MIB module is organized into a group of scalars and tables. The		The MIB module is organized into a group of scalars and tables. The
	scalars below vmHypervisor provide basic information about the		scalars below vmHypervisor provide basic information about the
	hypervisor. The vmGuestTable lists the guests (virtual machines)		hypervisor. The vmGuestTable lists the guests (virtual machines)
	that are known to the hypervisor. The vmStorageTable and the		that are known to the hypervisor. The vmStorageTable and the
	vmIfTable provide the mapping of logical storage areas and network		vmIfTable provide the mapping of logical storage areas and network
	interfaces to virtual machines.		interfaces to virtual machines.
	The vmGuestStateChange notification is generated whenever a virtual		The GuestState textual convention defines a state model for virtual
	machine changes its state (e.g., it is started or shutdown).		machines. Events causing transitions between major states will cause
			the generation of notifications (vmGuestStarted, vmGuestStopped,
			vmGuestSuspended, vmGuestResumed).
	The MIB module provides a few writable objects that can be used to		The MIB module provides a few writable objects that can be used to
	make non-persistent changes, e.g., changing the memory allocation or		make non-persistent changes, e.g., changing the memory allocation or
	the CPU allocation. It is not the goal of this MIB module to provide		the CPU allocation. It is not the goal of this MIB module to provide
	a configuration interface for virtual machines since other protocols		a configuration interface for virtual machines since other protocols
	and data modeling languages are more suitable for this task.		and data modeling languages are more suitable for this task.
	The OID tree structure of the MIB module is shown below.		The OID tree structure of the MIB module is shown below.
	--vmMib(1.3.6.1.2.1.XXXX)		--vmMib(1.3.6.1.2.1.XXXX)
	+--vmNotifications(0)		+--vmNotifications(0)
	| +--vmGuestStateChange(1) [vmGuestName,vmGuestUUID,		| +--vmGuestStarted(1) [vmGuestName,vmGuestUUID,vmGuestState]
	| vmGuestOldState,vmGuestState]		| +--vmGuestStopped(2) [vmGuestName,vmGuestUUID,vmGuestState]
			| +--vmGuestSuspended(3) [vmGuestName,vmGuestUUID,vmGuestState]
			| +--vmGuestResumed(4) [vmGuestName,vmGuestUUID,vmGuestState]
	+--vmObjects(1)		+--vmObjects(1)
	+--vmHypervisor(1)		+--vmHypervisor(1)
	| +-- r-n SnmpAdminString vmHypervisorVersion(1)		| +-- r-n SnmpAdminString vmHypervisorVersion(1)
	+--vmGuestTable(2)		+--vmGuestTable(2)
	| +--vmGuestEntry(1) [vmGuestIndex]		| +--vmGuestEntry(1) [vmGuestIndex]
	| +-- --- GuestIndex vmGuestIndex(1)		| +-- --- GuestIndex vmGuestIndex(1)
	| +-- r-n SnmpAdminString vmGuestName(2)		| +-- r-n SnmpAdminString vmGuestName(2)
	| +-- r-n UUIDOrZero vmGuestUUID(3)		| +-- r-n UUIDOrZero vmGuestUUID(3)
	| +-- r-n GuestState vmGuestState(4)		| +-- r-n GuestState vmGuestState(4)
	| +-- --n GuestState vmGuestOldState(5)
	| +-- r-n SnmpAdminString vmGuestOS(6)		| +-- r-n SnmpAdminString vmGuestOS(6)
	| +-- r-n Unsigned32 vmGuestCurCPUs(7)		| +-- r-n Unsigned32 vmGuestCurCPUs(7)
	| +-- rwn Unsigned32 vmGuestMinCPUs(8)		| +-- rwn Unsigned32 vmGuestMinCPUs(8)
	| +-- rwn Unsigned32 vmGuestMaxCPUs(9)		| +-- rwn Unsigned32 vmGuestMaxCPUs(9)
	| +-- r-n KBytes vmGuestCurMem(10)		| +-- r-n KBytes vmGuestCurMem(10)
	| +-- rwn KBytes vmGuestMinMem(11)		| +-- rwn KBytes vmGuestMinMem(11)
	| +-- rwn KBytes vmGuestMaxMem(12)		| +-- rwn KBytes vmGuestMaxMem(12)
	| +-- r-n Unsigned32 vmGuestCPUTime(13)		| +-- r-n Unsigned32 vmGuestCPUTime(13)
	+--vmStorageTable(3)		+--vmStorageTable(3)
	| +--vmStorageEntry(1) [vmGuestIndex,vmStorageIndex]		| +--vmStorageEntry(1) [vmGuestIndex,vmStorageIndex]
	skipping to change at page 5, line 5 ¶		skipping to change at page 5, line 10 ¶
	The MIB module IMPORTS definitions from SNMPv2-SMI [RFC2578],		The MIB module IMPORTS definitions from SNMPv2-SMI [RFC2578],
	SNMPv2-TC [RFC2579], SNMPv2-CONF [RFC2580], SNMP-FRAMEWORK-MIB		SNMPv2-TC [RFC2579], SNMPv2-CONF [RFC2580], SNMP-FRAMEWORK-MIB
	[RFC3411], and IF-MIB [RFC2863].		[RFC3411], and IF-MIB [RFC2863].
	Hypervisors implementing this MIB module should implement the HOST-		Hypervisors implementing this MIB module should implement the HOST-
	RESOURCES-MIB [RFC2790] and the IF-MIB [RFC2863] in order to export		RESOURCES-MIB [RFC2790] and the IF-MIB [RFC2863] in order to export
	information about the resources (e.g., processors, memory, logical		information about the resources (e.g., processors, memory, logical
	storage devices, network interfaces) of the physical machine. If the		storage devices, network interfaces) of the physical machine. If the
	hypervisor emulates a bridge to network virtual machines, then it		hypervisor emulates a bridge to network virtual machines, then it
	should implement the BRIDGE-MIB [RFC4188]. (Note that the BRIDGE-MIB		should implement the IEEE8021-BRIDGE-MIB. (Note that the BRIDGE-MIB
	is now further maintained by the IEEE [RFC4663].)		defined in [RFC4188] is now further maintained by the IEEE
			[RFC4663].) Details of the hardware configuration of a physical
			machine can be made available by implementing the ENTITY-MIB
			[RFC4133].
	The MIB module provides a mapping of logical storage devices to		5.1. Relationship to the HOST-RESOURCES-MIB
	virtual machines. Further details about the storage devices (such as
	the size and the amount of allocated storage) can be provided by the		The HOST-RESOURCES-MIB implemented on the physical machine provides
	HOST-RESOURCES-MIB. Note that the number of storage types can be		information about the number of CPUs and the amount of memory
	extended through the IANA maintained HOST-RESOURCES-TYPES MIB module.		available. Furthermore, the HOST-RESOURCES-MIB provides information
			about logical storage devices.
			The MIB module defined in this memo provides a mapping of logical
			storage devices to virtual machines. Further details about the
			storage devices (such as the size and the amount of allocated
			storage) is provided by the HOST-RESOURCES-MIB. Note that the number
			of storage types can be extended through the IANA maintained HOST-
			RESOURCES-TYPES MIB module.
			5.2. Relationship to the IF-MIB
	The MIB module provides a mapping of network interfaces to virtual		The MIB module provides a mapping of network interfaces to virtual
	machines. Further details about the network interfaces (such as		machines. Further details about the network interfaces (such as
	statistics about the number of packets/bytes sent or received) can be		statistics about the number of packets/bytes sent or received) can be
	obtained from the IF-MIB. Hypervisors implementing virtual bridges		obtained from the IF-MIB.
	can export the bridging topologies by implementing the BRIDGE-MIB.
	Note that Hypervisors supporting multiple virtual bridges may need to		5.3. Relationship to the IEEE8021-BRIDGE-MIB
	use non-standard SNMP contexts in order to make the information from
	multiple bridges accessible.		Hypervisors implementing virtual bridges should export the bridging
			topologies by implementing the IEEE8021-BRIDGE-MIB. For backwards
			compatibility with existing management applications, they may also
			choose to implement the BRIDGE-MIB [RFC4188].
			5.4. Relationship to the ENTITY-MIB
			The ENTITY-MIB [RFC4133] describes managed objects used for managing
			multiple logical and physical entities managed by a single SNMP
			agent. Implementations of the MIB module defined in this document
			may want to use the ENTITY-MIB to provide the logical to physical
			entity mapping and if needed to point to the agent in the virtual
			machine and vice versa.
	6. Definitions		6. Definitions
	VM-MIB DEFINITIONS ::= BEGIN		VM-MIB DEFINITIONS ::= BEGIN
	IMPORTS		IMPORTS
	MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,		MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
	Integer32, Unsigned32, mib-2		Integer32, Unsigned32, mib-2
	FROM SNMPv2-SMI -- RFC 2578		FROM SNMPv2-SMI -- RFC 2578
	TEXTUAL-CONVENTION, PhysAddress		TEXTUAL-CONVENTION, PhysAddress
	FROM SNMPv2-TC -- RFC 2579		FROM SNMPv2-TC -- RFC 2579
	OBJECT-GROUP, NOTIFICATION-GROUP, MODULE-COMPLIANCE		OBJECT-GROUP, NOTIFICATION-GROUP, MODULE-COMPLIANCE
	FROM SNMPv2-CONF -- RFC 2580		FROM SNMPv2-CONF -- RFC 2580
	SnmpAdminString		SnmpAdminString
	FROM SNMP-FRAMEWORK-MIB -- RFC 3411		FROM SNMP-FRAMEWORK-MIB -- RFC 3411
	InterfaceIndex		InterfaceIndex
	FROM IF-MIB; -- RFC 2863		FROM IF-MIB; -- RFC 2863
	vmMib MODULE-IDENTITY		vmMib MODULE-IDENTITY
	LAST-UPDATED "201203050000Z"		LAST-UPDATED "201203150000Z"
	ORGANIZATION		ORGANIZATION
	"Jacobs University Bremen"		"Jacobs University Bremen"
	CONTACT-INFO		CONTACT-INFO
	"Juergen Schoenwaelder		"Michael MacFaden
			VMware Inc.
			Email: mrm@vmware.com
			Juergen Schoenwaelder
	Jacobs University Bremen		Jacobs University Bremen
	Email: j.schoenwaelder@jacobs-university.de		Email: j.schoenwaelder@jacobs-university.de
	Tina Tsou		Tina Tsou
	Huawei Technologies (USA)		Huawei Technologies (USA)
	Email: tina.tsou.zouting@huawei.com		Email: tina.tsou.zouting@huawei.com
	Cathy Zhou		Cathy Zhou
	Huawei Technologies		Huawei Technologies
	Email: cathyzhou@huawei.com"		Email: cathyzhou@huawei.com"
	DESCRIPTION		DESCRIPTION
	"The MIB module for monitoring virtual machines controlled		"The MIB module for monitoring virtual machines controlled
	by a hypervisor.		by a hypervisor.
	Copyright (c) 2012 IETF Trust and the persons identified as		Copyright (c) 2012 IETF Trust and the persons identified as
	authors of the code. All rights reserved.		authors of the code. All rights reserved.
	Redistribution and use in source and binary forms, with or		Redistribution and use in source and binary forms, with or
	without modification, is permitted pursuant to, and subject		without modification, is permitted pursuant to, and subject
	to the license terms contained in, the Simplified BSD		to the license terms contained in, the Simplified BSD
	License set forth in Section 4.c of the IETF Trust's		License set forth in Section 4.c of the IETF Trust's
	Legal Provisions Relating to IETF Documents		Legal Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info)."		(http://trustee.ietf.org/license-info)."
	REVISION "201203050000Z"		REVISION "201203150000Z"
	DESCRIPTION		DESCRIPTION
	"Initial version, published as RFC XXXX."		"Initial version, published as RFC XXXX."
	-- RFC Ed.: replace XXXX with actual RFC number & remove this note		-- RFC Ed.: replace XXXX with actual RFC number & remove this note
	::= { mib-2 XXXX }		::= { mib-2 XXXX }
	vmNotifications OBJECT IDENTIFIER ::= { vmMib 0 }		vmNotifications OBJECT IDENTIFIER ::= { vmMib 0 }
	vmObjects OBJECT IDENTIFIER ::= { vmMib 1 }		vmObjects OBJECT IDENTIFIER ::= { vmMib 1 }
	vmConformance OBJECT IDENTIFIER ::= { vmMib 2 }		vmConformance OBJECT IDENTIFIER ::= { vmMib 2 }
	-- Textual convention definitions:		-- Textual convention definitions:
	skipping to change at page 7, line 49 ¶		skipping to change at page 8, line 35 ¶
	GuestState ::= TEXTUAL-CONVENTION		GuestState ::= TEXTUAL-CONVENTION
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The state of a guest (virtual machine):		"The state of a guest (virtual machine):
	unknown(1) The state is unknown, e.g., because the		unknown(1) The state is unknown, e.g., because the
	implementation failed to obtain the state		implementation failed to obtain the state
	from the hypervisor.		from the hypervisor.
	other(2) The state has been obtained but it does		other(2) The state has been obtained but it is
	not a known state.		not a known state.
	running(3) The virtual machine is currently running.		running(3) The virtual machine is currently running.
	blocked(4) The virtual machine is currently blocked.		blocked(4) The virtual machine is currently blocked.
	paused(5) The virtual machine is currently paused.		paused(5) The virtual machine is currently paused.
	shutdown(6) The virtual machine is currently in the		migrating(6) The virtual machine is currently migrating.
			shutdown(7) The virtual machine is currently in the
	process of shutting down.		process of shutting down.
	shutoff(7) The virtual machine is down.		shutoff(8) The virtual machine is down.
	crashed(8) The virtual machine has crashed."		crashed(9) The virtual machine has crashed."
	SYNTAX INTEGER {		SYNTAX INTEGER {
	unknown(1),		unknown(1),
	other(2),		other(2),
	running(3),		running(3),
	blocked(4),		blocked(4),
	paused(5),		paused(5),
	shutdown(6),		migrating(6),
	shutoff(7),		shutdown(7),
	crashed(8)		shutoff(8),
			crashed(9)
	}		}
	KBytes ::= TEXTUAL-CONVENTION		KBytes ::= TEXTUAL-CONVENTION
	DISPLAY-HINT "d"		DISPLAY-HINT "d"
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"Storage size measured in units of 1024 octets (bytes). This		"Storage size measured in units of 1024 octets (bytes). This
	textual convention allows to represent storage sizes up to		textual convention allows to represent storage sizes up to
	4096 gigabytes."		4096 gigabytes."
	SYNTAX Unsigned32		SYNTAX Unsigned32
	skipping to change at page 9, line 29 ¶		skipping to change at page 10, line 16 ¶
	"An (conceptual) table entry describing a particular		"An (conceptual) table entry describing a particular
	guest (virtual machine)."		guest (virtual machine)."
	INDEX { vmGuestIndex }		INDEX { vmGuestIndex }
	::= { vmGuestTable 1 }		::= { vmGuestTable 1 }
	VmGuestEntry ::= SEQUENCE {		VmGuestEntry ::= SEQUENCE {
	vmGuestIndex GuestIndex,		vmGuestIndex GuestIndex,
	vmGuestName SnmpAdminString,		vmGuestName SnmpAdminString,
	vmGuestUUID UUIDOrZero,		vmGuestUUID UUIDOrZero,
	vmGuestState GuestState,		vmGuestState GuestState,
	vmGuestOldState GuestState,		-- XXX add information about the CPU type
			-- XXX the cpu type may be different from the host CPU
	vmGuestOS SnmpAdminString,		vmGuestOS SnmpAdminString,
	vmGuestCurCPUs Unsigned32,		vmGuestCurCPUs Unsigned32,
	vmGuestMinCPUs Unsigned32,		vmGuestMinCPUs Unsigned32,
	vmGuestMaxCPUs Unsigned32,		vmGuestMaxCPUs Unsigned32,
	vmGuestCurMem KBytes,		vmGuestCurMem KBytes,
	vmGuestMinMem KBytes,		vmGuestMinMem KBytes,
	vmGuestMaxMem KBytes,		vmGuestMaxMem KBytes,
	vmGuestCPUTime Unsigned32		vmGuestCPUTime Unsigned32
	}		}
	skipping to change at page 10, line 29 ¶		skipping to change at page 11, line 18 ¶
	vmGuestState OBJECT-TYPE		vmGuestState OBJECT-TYPE
	SYNTAX GuestState		SYNTAX GuestState
	MAX-ACCESS read-only		MAX-ACCESS read-only
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The current operational state of the guest (virtual		"The current operational state of the guest (virtual
	machine)."		machine)."
	::= { vmGuestEntry 4 }		::= { vmGuestEntry 4 }
	vmGuestOldState OBJECT-TYPE
	SYNTAX GuestState
	MAX-ACCESS accessible-for-notify
	STATUS current
	DESCRIPTION
	"The previous operational state of the guest (virtual
	machine). This object is only used in state change
	notifications."
	::= { vmGuestEntry 5 }
	vmGuestOS OBJECT-TYPE		vmGuestOS OBJECT-TYPE
	SYNTAX SnmpAdminString		SYNTAX SnmpAdminString
	MAX-ACCESS read-only		MAX-ACCESS read-only
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The operating system running on this guest (virtual		"The operating system running on this guest (virtual
	machine). This value corresponds to the operating		machine). This value corresponds to the operating
	system the hypervisor assumes to be running when the		system the hypervisor assumes to be running when the
	virtual machine is started. This may differ from the		virtual machine is started. This may differ from the
	actual operating system in case the virtual machine		actual operating system in case the virtual machine
	skipping to change at page 13, line 8 ¶		skipping to change at page 13, line 35 ¶
	guests (virtual machines)."		guests (virtual machines)."
	::= { vmObjects 3 }		::= { vmObjects 3 }
	vmStorageEntry OBJECT-TYPE		vmStorageEntry OBJECT-TYPE
	SYNTAX VmStorageEntry		SYNTAX VmStorageEntry
	MAX-ACCESS not-accessible		MAX-ACCESS not-accessible
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"An (conceptual) table entry describing a particular		"An (conceptual) table entry describing a particular
	storage device attached to a guest (virtual machine)"		storage device attached to a guest (virtual machine)"
	INDEX { vmGuestIndex, vmStorageIndex }		INDEX { vmStorageGuest, vmStorageIndex }
	::= { vmStorageTable 1 }		::= { vmStorageTable 1 }
	VmStorageEntry ::= SEQUENCE {		VmStorageEntry ::= SEQUENCE {
	vmStorageGuest GuestIndexOrZero,		vmStorageGuest GuestIndexOrZero,
	vmStorageIndex StorageIndex,		vmStorageIndex StorageIndex,
	vmStorageName SnmpAdminString		vmStorageName SnmpAdminString
	}		}
	vmStorageGuest OBJECT-TYPE		vmStorageGuest OBJECT-TYPE
	SYNTAX GuestIndexOrZero		SYNTAX GuestIndexOrZero
	skipping to change at page 15, line 11 ¶		skipping to change at page 15, line 38 ¶
	DESCRIPTION		DESCRIPTION
	"The physical address used by the interface. For interfaces		"The physical address used by the interface. For interfaces
	associated to a port of a virtual bridge, this object		associated to a port of a virtual bridge, this object
	normally contains a MAC address. For interfaces which do not		normally contains a MAC address. For interfaces which do not
	have such an address, this object should contain a		have such an address, this object should contain a
	zero-length octet string."		zero-length octet string."
	::= { vmIfEntry 3 }		::= { vmIfEntry 3 }
	-- Notification definitions:		-- Notification definitions:
	vmGuestStateChange NOTIFICATION-TYPE		vmGuestStarted NOTIFICATION-TYPE
	OBJECTS {		OBJECTS {
	vmGuestName,		vmGuestName,
	vmGuestUUID,		vmGuestUUID,
	vmGuestOldState,
	vmGuestState		vmGuestState
	}		}
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"This notification is generated when a guest (virtual machine)		"This notification is generated when a guest (virtual machine)
	changes its state."		has been started and the start process has reached a stable
			state (e.g., running or crashed)."
	::= { vmNotifications 1 }		::= { vmNotifications 1 }
			vmGuestStopped NOTIFICATION-TYPE
			OBJECTS {
			vmGuestName,
			vmGuestUUID,
			vmGuestState
			}
			STATUS current
			DESCRIPTION
			"This notification is generated when a guest (virtual machine)
			has been stopped and the shutdown process has reached a stable
			state (e.g., shutdown or shutoff or crashed)."
			::= { vmNotifications 2 }
			vmGuestSuspended NOTIFICATION-TYPE
			OBJECTS {
			vmGuestName,
			vmGuestUUID,
			vmGuestState
			}
			STATUS current
			DESCRIPTION
			"This notification is generated when a guest (virtual machine)
			has been suspended and the suspension process has reached a
			stable state (e.g., paused or crashed)."
			::= { vmNotifications 3 }
			vmGuestResumed NOTIFICATION-TYPE
			OBJECTS {
			vmGuestName,
			vmGuestUUID,
			vmGuestState
			}
			STATUS current
			DESCRIPTION
			"This notification is generated when a guest (virtual machine)
			has been resumed and the resumption process has reached a
			stable state (e.g., running or crashed)."
			::= { vmNotifications 4 }
	-- Compliance definitions:		-- Compliance definitions:
	vmGroups OBJECT IDENTIFIER ::= { vmConformance 1 }		vmGroups OBJECT IDENTIFIER ::= { vmConformance 1 }
	vmCompliances OBJECT IDENTIFIER ::= { vmConformance 2 }		vmCompliances OBJECT IDENTIFIER ::= { vmConformance 2 }
	vmFullCompliance MODULE-COMPLIANCE		vmFullCompliance MODULE-COMPLIANCE
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"Compliance statement for implementations supporting		"Compliance statement for implementations supporting
	read/write access, according to the object definitions."		read/write access, according to the object definitions."
	skipping to change at page 16, line 48 ¶		skipping to change at page 18, line 18 ¶
	"A collection of objects providing insight into the		"A collection of objects providing insight into the
	hypervisor itself."		hypervisor itself."
	::= { vmGroups 1 }		::= { vmGroups 1 }
	vmGuestGroup OBJECT-GROUP		vmGuestGroup OBJECT-GROUP
	OBJECTS {		OBJECTS {
	-- vmGuestIndex,		-- vmGuestIndex,
	vmGuestName,		vmGuestName,
	vmGuestUUID,		vmGuestUUID,
	vmGuestState,		vmGuestState,
	vmGuestOldState,
	vmGuestOS,		vmGuestOS,
	vmGuestCurCPUs,		vmGuestCurCPUs,
	vmGuestMinCPUs,		vmGuestMinCPUs,
	vmGuestMaxCPUs,		vmGuestMaxCPUs,
	vmGuestCurMem,		vmGuestCurMem,
	vmGuestMinMem,		vmGuestMinMem,
	vmGuestMaxMem,		vmGuestMaxMem,
	vmGuestCPUTime		vmGuestCPUTime
	}		}
	STATUS current		STATUS current
	skipping to change at page 17, line 42 ¶		skipping to change at page 19, line 11 ¶
	vmIfPhysAddr		vmIfPhysAddr
	}		}
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"A collection of objects providing insight into the		"A collection of objects providing insight into the
	network interfaces controlled by a hypervisor."		network interfaces controlled by a hypervisor."
	::= { vmGroups 4 }		::= { vmGroups 4 }
	vmNotificationGroup NOTIFICATION-GROUP		vmNotificationGroup NOTIFICATION-GROUP
	NOTIFICATIONS {		NOTIFICATIONS {
	vmGuestStateChange		vmGuestStarted,
			vmGuestStopped,
			vmGuestSuspended,
			vmGuestResumed
	}		}
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"A collection of notifications for virtual machines		"A collection of notifications for virtual machines
	controlled by a hypervisor."		controlled by a hypervisor."
	::= { vmGroups 5 }		::= { vmGroups 5 }
	END		END
	7. Security Considerations		7. Security Considerations
	skipping to change at page 18, line 32 ¶		skipping to change at page 20, line 5 ¶
	control even GET and/or NOTIFY access to these objects and possibly		control even GET and/or NOTIFY access to these objects and possibly
	to even encrypt the values of these objects when sending them over		to even encrypt the values of these objects when sending them over
	the network via SNMP. These are the tables and objects and their		the network via SNMP. These are the tables and objects and their
	sensitivity/vulnerability:		sensitivity/vulnerability:
	o The tables vmGuestTable, vmStorageTable, and vmIfTable provide		o The tables vmGuestTable, vmStorageTable, and vmIfTable provide
	insight into the resources allocated to virtual machines and this		insight into the resources allocated to virtual machines and this
	knowledge might be exploited for targeted denial of service		knowledge might be exploited for targeted denial of service
	attacks.		attacks.
	o The vmGuestStateChange notification provides information about		o The vmGuestStarted, vmGuestStopped, vmGuestSuspended, and
	state changes of virtual machines and implicitly also on which		vmGuestResumed notifications provides information about state
	physical hosts virtual machines are located. Furthermore, the		changes of virtual machines and implicitly also on which physical
	generation of fake vmGuestStateChange notifications might trigger		hosts virtual machines are located. Furthermore, the generation
	false alarms and subsequent actions in a network management		of fake notifications might trigger false alarms and subsequent
	system, which can amplify denial of service attacks or simply lead		actions in a network management system, which can amplify denial
	to less efficient resource usage.		of service attacks or simply lead to less efficient resource
			usage.
	SNMP versions prior to SNMPv3 did not include adequate security.		SNMP versions prior to SNMPv3 did not include adequate security.
	Even if the network itself is secure (for example by using IPsec),		Even if the network itself is secure (for example by using IPsec),
	even then, there is no control as to who on the secure network is		even then, there is no control as to who on the secure network is
	allowed to access and GET/SET (read/change/create/delete) the objects		allowed to access and GET/SET (read/change/create/delete) the objects
	in this MIB module.		in this MIB module.
	It is RECOMMENDED that implementers consider the security features as		It is RECOMMENDED that implementers consider the security features as
	provided by the SNMPv3 framework (see [RFC3410], section 8),		provided by the SNMPv3 framework (see [RFC3410], section 8),
	including full support for the SNMPv3 cryptographic mechanisms (for		including full support for the SNMPv3 cryptographic mechanisms (for
	skipping to change at page 19, line 18 ¶		skipping to change at page 20, line 41 ¶
	rights to indeed GET or SET (change/create/delete) them.		rights to indeed GET or SET (change/create/delete) them.
	8. IANA Considerations		8. IANA Considerations
	IANA is requested to assign a value for "XXXX" under the 'mib-2'		IANA is requested to assign a value for "XXXX" under the 'mib-2'
	subtree and to record the assignment in the SMI Numbers registry.		subtree and to record the assignment in the SMI Numbers registry.
	When the assignment has been made, the RFC Editor is asked to replace		When the assignment has been made, the RFC Editor is asked to replace
	"XXXX" (here and in the MIB module) with the assigned value and to		"XXXX" (here and in the MIB module) with the assigned value and to
	remove this note.		remove this note.
	9. References		9. Acknowledgements
	9.1. Normative References		Thanks to David Black and Robert Story for helpful comments during
			the development of this specification.
			10. References
			10.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.		[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
	Schoenwaelder, Ed., "Structure of Management Information		Schoenwaelder, Ed., "Structure of Management Information
	Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.		Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
	[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.		[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.
	Schoenwaelder, Ed., "Textual Conventions for SMIv2",		Schoenwaelder, Ed., "Textual Conventions for SMIv2",
	skipping to change at page 19, line 48 ¶		skipping to change at page 21, line 28 ¶
	RFC 2790, March 2000.		RFC 2790, March 2000.
	[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group		[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
	MIB", RFC 2863, June 2000.		MIB", RFC 2863, June 2000.
	[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An		[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
	Architecture for Describing Simple Network Management		Architecture for Describing Simple Network Management
	Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,		Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
	December 2002.		December 2002.
	9.2. Informative References		[RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)",
			RFC 4133, August 2005.
			10.2. Informative References
	[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,		[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
	"Introduction and Applicability Statements for Internet-		"Introduction and Applicability Statements for Internet-
	Standard Management Framework", RFC 3410, December 2002.		Standard Management Framework", RFC 3410, December 2002.
	[RFC4188] Norseth, K. and E. Bell, "Definitions of Managed Objects		[RFC4188] Norseth, K. and E. Bell, "Definitions of Managed Objects
	for Bridges", RFC 4188, September 2005.		for Bridges", RFC 4188, September 2005.
	[RFC4663] Harrington, D., "Transferring MIB Work from IETF Bridge		[RFC4663] Harrington, D., "Transferring MIB Work from IETF Bridge
	MIB WG to IEEE 802.1 WG", RFC 4663, September 2006.		MIB WG to IEEE 802.1 WG", RFC 4663, September 2006.
			Appendix A. Open Issues
			This file is used to track issues that were discussed during the
			development of the SMIv2 to YANG translation in the IETF NETMOD
			working group. This issues covered here concern major design choices;
			this file does not attempt to track minor clarification requests etc.
			To comment on issues on the mailing list, please include the issue
			number in the subject line of the email message.
			* vm-mib-01: storage sizes
			The MIB does not provide storage sizes, assuming this is provided by
			the hrStorageTable of the HOST-RESOURCES-MIB. However, some well
			known implementations of the HOST-RESOURCES-MIB only report about
			file systems used by the host system and not file systems residing
			in files used by virtual machines. Furthermore, the hrStorageTable
			reports sizes "usable by the requesting entity", "excluding loss due
			to formatting of file system reference information". For storage
			provided to virtual machines, this information is often not readily
			available since all you have is the raw block size.
			** Solution #01-01
			Provide the storage block sizes as part of the VM-MIB. Provide a
			pointer to the hrStorageTable on systems that can provide this
			linkage but allow the pointer to be NULL.
			** Resolution
			TBD
			* vm-mib-02: scaling and caching support
			It was mentioned that large data centers are characterized by
			100.000 physical hosts running 2.000.000 virtual machines. The NASA
			is reported with 1.000.000 physical hosts and 60.000.000 virtual
			machines. Bottom line is that we need to make the MIB module
			scalable. We can assume up hundreds of VMs running on a single
			virtual machine.
			** Solution #02-01
			Add ...LastChange objects to tables so that management applications
			can easily validate cached information without having to read
			through potentially larger tables. For the vmGuestTable, we might
			also provide a ...LastStateChange object so that state changes can
			be polled with reading a simple scalar.
			** Solution #02-02
			Make some tables time filtered. Unclear which tables would have to
			be time filtered.
			** Resolution
			TBD
			* vm-mib-03: virtual cpu type identification
			It is necessary to identify the CPU architecture or type since some
			virtual machine systems can emulate different CPU types.
			** Solution #03-01
			Provide an IANA controlled enumeration that provides a CPU
			classification. The problem will be to provide rules about what
			constitutes a new CPU type and what not.
			** Solution #03-02
			Use OBJECT IDENTITIES to identify CPU types. Such a distributed
			enumeration will not achieve a great deal of interoperability
			and is likely close to #03-03.
			** Solution #03-03
			Use a string data type and rely on systems to put meaningful
			information there, perhaps provide guidelines how to structure the
			CPU type names, e.g. vendor-arch-model(-features)* that is
			amd-x86_64-opteron or intel-i686-pentium3-vmx-acpi (perhaps using a
			different separator character since a dash might easily clash).
			Applications may have to do some normalization across VM-MIB
			implementations (e.g., regular expression matching) but on the
			other hand this allows to provide details where necessary.
			** Solution #03-04
			Following #03-03, we provide ...GuestCpuVendor, ...GuestCpuArch
			and ...GuestCpuModel objects plus an additional table that provides
			details about the features of the CPUs used by a certain virtual
			machine. This essentially breaks the string into a set of separate
			MIB objects.
			** Solution #03-05
			Following #03-04, we provide ...GuestCpuVendor, ...GuestCpuArch and
			...GuestCpuModel objects plus a string object containing a list of
			features. This way, things are more compact but still the most
			important components (vendor, arch, model) are broken out as
			separate objects.
			** Resolution
			TBD
			* vm-mib-04: physical CPU type identification
			VM migration sometimes requires to match physical CPUs and more
			important also feature sets of physical CPUs.
			** Solution #04-01:
			Extend the ENTITY-MIB with a new MIB module, say an ENTITY-CPU-MIB,
			providing an entPhyCPUTable, sparsely augmenting the
			entPhysicalTable for physical entities with entPhysicalClass = cpu.
			The entPhyCPUTable would contain information about CPU vendor, CPU
			architecture, CPU mode, CPU features, clock speeds, etc. (see also
			vm-mib-03).
			** Resolution
			TBD
			* vm-mib-05: per virtual cpu statistics
			It seems to be useful to provide statistics for each virtual CPU.
			However, it remains unclear what can be expected to be provided by a
			typical hypervisor implementation. There are a number of things to
			consider:
			a) Reporting the time the virtual CPU has been running (CPU time
			consumed) seems relatively straight forward.
			b) Reporting the current state of a virtual CPU requires to first
			define a suitable state model that is course grained enough to be
			useful (otherwise CPU state changes far too quickly to yield
			meaningful results). Libvirt, for example, has CPU states
			offline, running, blocked on resource. It is not further defined
			what blocked on resource really means. Anyway, with a suitable
			state model, the MIB could provide the time spent in the various
			CPU states rather than or in addition to the current snapshot
			state.
			c) Reporting the affinity mapping of virtual CPUs to physical CPUs.
			This, of course, requires to have a representation of physical
			CPUs.
			** Resolution
			TBD
			* representing networks (vmNetTable)
			Not yet well enough understood to write up this issue. ;-)
	Authors' Addresses		Authors' Addresses
			Michael MacFaden
			VMware Inc.
			EMail: mrm@vmware.com
	Juergen Schoenwaelder		Juergen Schoenwaelder
	Jacobs University		Jacobs University
	Campus Ring 1		Campus Ring 1
	Bremen 28759		Bremen 28759
	Germany		Germany
	EMail: j.schoenwaelder@jacobs-university.de		EMail: j.schoenwaelder@jacobs-university.de
	Tina Tsou		Tina Tsou
	Huawei Technologies (USA)		Huawei Technologies (USA)
End of changes. 36 change blocks.
	69 lines changed or deleted		315 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/