Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04)

[Hirochika Asai <[e-mail]>]

Hi,

I'm working on revising our draft and updating our implementation
now.  Here I'd like to go on this topic again because I found some
points to be discussed.

According to this discussion, the MAX-ACCESS of vmMinCpuNumber etc.
is left as read-write with "MUST NOT persist" sentence.

I think vmCurCpuNumber and vmCurMem are more operational parameters
than vmMax* and vmMin*.  So shall we change the MAX-ACCESS of these
two objects to read-write?  It depends on the hypervisor
implementation whether these objects as well as vmMax* and vmMin*
can be changed without persisted.  It also dependes on a guest OS
whether vmCur* can be changed for running virtual machines.

Could you give us your comments on this?

Thank you,
Hirochika


On Aug 22, 2013, at 3:27 AM, Joe Marcus Clarke <[e-mail]> wrote:

> On 8/20/13 2:37 AM, Juergen Schoenwaelder wrote:
>> On Mon, Aug 19, 2013 at 04:38:28PM -0400, Joe Marcus Clarke wrote:
>>>> 
>>>> We seem to agree on the general scope. Now we have to determine which
>>>> objects reasonably have a MAX-ACCESS or read-write. For me, it seems
>>>> that vmAutoStart likely should indeed be read-only. However, as far as
>>>> I know, Xen allows to change vmMinCpuNumber, vmMaxCpuNumber, vmMinMem,
>>>> and vmMaxMem at runtime without touching persistent config state.
>>> 
>>> If the WG's intent is to leave them as RW (and I can see that certain
>>> HV's allow this sans persistence), then there should be stronger
>>> guidance (I think) that indicates that these are operational-only
>>> objects and the new values should not be persisted.  But that may be too
>>> messy.
> 
> Sorry for the delay.  I've been in meetings this week.
> 
>> 
>> There is already text like this:
>> 
>>      Changes to this object may not persist across restarts of the
>>      hypervisor.
>> 
>> What is your proposal to make this clearer / stronger?
> 
> This leaves it open to one persisting it.  You could use normative
> language and say, MUST NOT persist...
> 
>> 
>>> Is there a strong push from operators to toggle these values via SNMP?
>> 
>> Remeber that this is a MAX-ACCESS. RFC 2578 section 7.3 says that it
>> 'defines whether it makes "protocol sense" to read, write and/or
>> create an instance of the object, or to include its value in a
>> notification'. The compliance statement vmReadOnlyCompliances says
>> that write access is not required to be implemented. I believe this is
>> how we commonly do things in a MIB module - we allow read-write
>> implementations but we do not require read-write implementations.
>> Hence, I prefer to make no changes (except perhaps vmAutoStart but I
>> need to check whether there are hypervisors that actually allow to
>> change autostart behaviour of the running instance without touching
>> persistent config - this might actually be possible).
> 
> That's fair.  I was not aware of the ability to adjust VM CPU and memory
> on the fly without touching the config.  That said, I struggle to
> understand the use case of doing this via SNMP versus a more reliable API.
> 
> I would also ask that some language be added to the compliance section
> like you have in Section 3.2 about only implementing read-write if the
> changes can be made dynamically and independent of the config.
> 
> Joe
> 
>> 
>> /js
>> 
> 
> 
> -- 
> 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]
> 
> ----------------------------------------------------------------------------
> _______________________________________________
> OPSAWG mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/opsawg
> 

-- 
Hirochika Asai <[e-mail]>, The University of Tokyo