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

[Hirochika Asai <[e-mail]>]

Dear Joe,

Thank you for your comment.  Let us change these two objects to read-write
in the next version.

Thank you.
Hirochika


On Oct 9, 2013, at 3:10 AM, Joe Marcus Clarke <[e-mail]> wrote:

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

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