[OPSAWG] Comments on draft-asai-vmm-mib-04

[Joe Marcus Clarke <[e-mail]>]

Sorry for the big delay between IETF-87 and now.  I wanted to officially
record my comments about this proposed MIB module on the mailing list to
backup what I said on the mic in the working group session.  Please see
JMC below.

Section 1:

The design of this MIB module has been derived from enterprise
   specific MIB modules, namely a MIB module for managing guests of the
   Xen hypervisor, a MIB module for managing virtual machines controlled
   by the VMware hypervisor, and a MIB module using the libvirt
   programming interface to access different hypervisors.

JMC: While I think the intention is to say that this MIB pulls from
other, existing MIBs for common virtualization platforms, it may come
across as being limited to only those platforms.  Perhaps it is good to
say that this MIB then attempts to generalize those modules to support
other hypervisors as well?

Section 3.3:

Concerning vmTable

JMC: I think there should be an object in this table such as vmMgmtAddr,
which lists the management IP address of the VM.  This would be akin to
what one would see in vCenter for a VMware-controlled VM.  As a manager,
this would be very useful in being able to discover other potential SNMP
agents in the network.

JMC: The purpose of this MIB is not to provide configuration of the
hypervisor.  Quoting section 3.2:

"The MIB module provides a few writable objects that can be used to
   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
   a configuration interface for virtual machines since other protocols
   and data modeling languages are more suitable for this task."

To that end, I find objects like vmAutoStart, vmMinCpuNumber,
vmMaxCpuNumber, vmMinMem, and vmMaxMem strange.  For starters,
vmAutoStart mentions the word "configuration" in its description.  And
the other objects, at least from a VMware standpoint are actually
specified in the VM's configuration.  One would have to, for example,
shutdown the VM to increase the number of vCPUs allocated to the VM.
Therefore, I feel all of these objects represent persistent changes to
the hypervisor in support of the respective VM.

I think these objects should go away and only the read-only objects
showing current vCPU allocation, affinity, and memory stats should
remain.  As for auto-start, that can be read-only.

The alternative is to say that some persistent changes will be allowed
(such as auto-start), but general VM resource configuration will be out
of scope.

Section 3.3:

vmNetworkEntry OBJECT-TYPE
       SYNTAX       VmNetworkEntry
       MAX-ACCESS   not-accessible
       STATUS       current
       DESCRIPTION
               "An entry for one virtual storage device attached to the
               virtual machine."
       INDEX { vmIndex, vmNetworkIndex }
       ::= { vmNetworkTable 1 }

JMC: Note how the description describes this as "storage" device...

Section 3.3:

Concerning vmNetworkTable.

JMC: I think there should be a vmNetworkVlan object in this table that
describes the VLAN ID associated to the underlying interface.  This need
not be used for every hypervisor, but I think it is very important in
some (like VMware).

JMC: What would one expect if I have a VM connected to multiple
vSwitches in a VMware environment?  What object will tell me to what
vSwitch I am connected?  Should there also be a name here for the
virtual interface?  I'm thinking of the case where something like a
Cisco Nexus 1000v switch is used.  In that case, knowing that I am
connected to Ethernet1/1 might be useful.

JMC: Like in the VM table, I wonder if it makes sense to have a network
management address for the case where the associated virtual network
device can be independently managed.

Section 3.3:

Concerning vmNotifications.

JMC: I think there should be a general notification for VM changing
state.  The reason for this is that some of the state transitions
described in section 3.2 Figure 2 can take a long time (e.g., running ->
shuttingdown -> shutdown).  In that case, an administrator may have to
wait minutes before being alerted to the fact that her VM is offline.
If there was a notification for vmStateChange, then the admin would be
notified immediately if a VM entered a degraded state.

I think that's all I noticed.  Thanks.

Joe

-- 
Joe Marcus Clarke, CCIE #5384,         |          |
SCJP, SCSA, SCNA, SCSECA, VCP        |||||      |||||
Distinguished Services Engineer ..:|||||||||::|||||||||:..
Phone: [phone]         c i s c o  S y s t e m s
Email: [e-mail]

----------------------------------------------------------------------------