Subject: [OPSAWG] draft-asai-vmm-mib: Issues on notifications

From: Hirochika Asai <[email-masked]>
Date: Thu, 11 Apr 2013 09:36:06 +0900

Dear folks,

We've uploaded the updated version of our MIB proposal about virtual
machines controlled by a hypervisor here:
http://tools.ietf.org/html/draft-asai-vmm-mib-03

The followings are the known issues related to notifications listed
on P.42 of our I-D.  We would like to discuss the followings (and
other issues you find, of course), so please review the I-D and
post your comments to the list.

o  Issue 1-1) Scalability issue on notifications: The number of
   virtual machines managed by a bunch of hypervisors in a datacenter
   possibly becomes several thousands or more.  If these virtual
   machines frequently change their administrative state, many
   notifications could be trapped.  Since an SNMP manager has to
   handle SNMP traps of these notifications, there exists a
   scalability issue on handling them.  Should we add some
   `vmXXXNotificationEnable' objects to disable traps for each
   notification?  Or any other ideas?

o  Issue 1-2) vmDeleted: Is `vmDeleted' required?  If the virtual
   machine is not persistent on the hypervisor, its entry will
   disappear when it has shutdown. `vmShutdown' can trap the event of
   shutdown of a virtual machine.  So do we remove `vmDeleted' and
   change `vmShutdown' to carry `vmPersistent' in order to
   distinguish ``just shutdown'' and ``shutdown and automatically
   deleted''?

o  Issue 1-3) vmOperState carried with each notification: In our
   current proposal, each notification corresponds to the new
   operational state of a virtual machine, and `vmOperState'
   indicates the old operational state.  For example, when a virtual
   machine is switched on, the operational state is changed to
   running from shutdown.  In this case, vmRunning with shutdown
   vmOperState is be generated when the operational state of a
   virtual machine is about to enter running state.  Is this simple
   and reasonable?

Thank you.
Hirochika Asai

-- 
Hirochika Asai <[email-masked]>, The University of Tokyo

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 11 Apr 2013 21:56:08 -0700

Hi -

> From: "Hirochika Asai" <[email-masked]>
> To: <[email-masked]>
> Sent: Wednesday, April 10, 2013 5:36 PM
> Subject: [OPSAWG] draft-asai-vmm-mib: Issues on notifications
...
>    notification?  Or any other ideas?
...

RFC 3014 might be helpful here, and possibly RFC 3877.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 12 Apr 2013 08:36:47 +0200

> RFC 3014 might be helpful here, and possibly RFC 3877.

I think Michael wanted to post notification definitions that help
reduce the number of notifications emitted if for example all virtual
machines of a hypervisor change state at about the same time (e.g.,
because the physical server is restarted). This may be a good thing
since it reduces the number of notifications at the source and as
such works independently of RFCs 3014 or 3877.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 12 Apr 2013 11:09:18 -0700

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, April 11, 2013 11:36 PM
> Subject: Re: [OPSAWG] draft-asai-vmm-mib: Issues on notifications
...
...
> such works independently of RFCs 3014 or 3877.

For that specific use case, a notifcation identifying the hypervisor
to which those VMs belong, rather than the individual virtual machines,
would seem a better way to go.  One might even argue that the
coldStart notification type could be sufficient to do the job.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 12 Apr 2013 21:33:49 +0200

> coldStart notification type could be sufficient to do the job.

Yes, for this use case - I assume Michael has more insights whether
there are other use cases where subsets of all machines of a
hypervisor change state together.

/js