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

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

On 10/8/13 8:07 AM, Hirochika Asai wrote:
> 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 believe that is what we arrived at.

> 
> 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?

I would be okay with that given my previous related comments and the
appropriate verbiage.

Joe

> 
> 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
>>
> 


-- 
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]

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