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 <jcla...@cisco.com> 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 <jcla...@cisco.com> 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: +1 (919) 392-2867 c i s c o S y s t e m s >>> Email: jcla...@cisco.com >>> >>> ---------------------------------------------------------------------------- >>> _______________________________________________ >>> OPSAWG mailing list >>> OPSAWG@ietf.org >>> https://www.ietf.org/mailman/listinfo/opsawg >>> >> > > > -- > Joe Marcus Clarke, CCIE #5384, | | > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > Phone: +1 (919) 392-2867 c i s c o S y s t e m s > Email: jcla...@cisco.com > > ---------------------------------------------------------------------------- > -- Hirochika Asai <pa...@hongo.wide.ad.jp>, The University of Tokyo _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
