Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04)
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
Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04)
I really don't like the idea of standards prohibiting potentially useful functionality. I would like a better understanding/description of the problems that would be caused by having persistent values for these objects in some implementations and volatile values in other implementations, to justify the MUST NOT usage. I would like a better understanding of the benefits that might lead some implementers to have persistent values in their implementations; what possible useful functionality could we be prohibiting by making this a MUST NOT? David Harrington ietf...@comcast.net +1-603-828-1401 -Original Message- From: opsawg-boun...@ietf.org [mailto:opsawg-boun...@ietf.org] On Behalf Of Hirochika Asai Sent: Thursday, August 29, 2013 4:28 AM To: Joe Marcus Clarke Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04) As for the read-write objects, i.e., vmMinCpuNumber, vmMaxCpuNumber, vmMinMem, and vmMaxMem, I changed the following phrase for the next version of the draft. (deleted) Changes to this object may not persist across restarts of the hypervisor (added) Changes to this object must not persist across restarts of the hypervisor Thank you. Hirochika On Aug 24, 2013, at 4:53 AM, Joe Marcus Clarke jcla...@cisco.com wrote: Just to be absolutely clear... Are you requesting that the normative text state that the values assigned to these object-types SHOULD NOT or MUST NOT persist across reboots? I really don't like the idea of standards prohibiting potentially useful functionality. I was asking for the latter since this MIB is not about configuration. I think it would be a POLA violation if one vendor did a persistent implementation and some did a volatile implementation. -- Hirochika Asai pa...@hongo.wide.ad.jp, The University of Tokyo ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04)
Punting the configuration problem to Netconf doesn't reduce the modeling (or operational) complexity presented by read-write objects like these. If you argue instead that they should be read-only, that's another matter (though still fraught with complexity, given the ways Netconf can work) but doing so also, for me at least, raises the why bother question regarding this MIB module. If these objects would merely reflect the current configuration data, then they'd add no value, and there'd be no point in having them at all. For any given managed object in this mib module it should be shown how this is useful for monitoring purposes otherwise should not be added. If it duplicates configuration data so be it -- so long as its value has been shown. Regards, Mike MacFaden Staff Engineer RD Apps VMware, Inc Palo Alto CA ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04)
On 8/29/13 3:45 PM, Randy Presuhn wrote: Hi - From: Joe Marcus Clarke jcla...@cisco.com To: Randy Presuhn randy_pres...@mindspring.com Cc: opsawg@ietf.org Sent: Thursday, August 29, 2013 12:29 PM Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04) ... Would it not be better to implement something like NETCONF for the configuration side of things if I really wanted to offer configuration? then this MIB could really be left for monitoring. Punting the configuration problem to Netconf doesn't reduce the modeling (or operational) complexity presented by read-write objects like these. If you argue instead that they should be read-only, that's another matter (though still fraught with complexity, given the ways Netconf can work) but doing so also, for me at least, raises the why bother question regarding this MIB module. If these objects would merely reflect the current configuration data, then they'd add no value, and there'd be no point in having them at all. I would be happy with read-only objects that showed the operational values. But there was a use case for changing the operational parameters via SNMP SET. In either case, I think the values and operations should reflect the operational state. Joe -- 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
Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04)
Hi - From: Joe Marcus Clarke jcla...@cisco.com To: Randy Presuhn randy_pres...@mindspring.com Cc: opsawg@ietf.org Sent: Thursday, August 29, 2013 4:11 PM Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04) ... I would be happy with read-only objects that showed the operational values. But there was a use case for changing the operational parameters via SNMP SET. In my book, that's a configuration change. It might be made with the intention of reverting to some previous configuration at some time in the future, but a configuration change nonetheless. It sounds like the claim here is that there are knobs whose initial settings are presumed to persist as part of system configuration, but for which any tweaks are forgotten. Those are two different knobs, should be clearly identified as such, and their relationship formally spelled out. Depending on the complexity of their relationship, it sounds like you may be asking for THREE objects (not all in MIB modules, of course): - the persistent configuration parameter, Netconf or whatever - the writable tweak knob, whose values might potentially be constrained by persistent configuration - the read-only operational value, which would be some function of the configuration, the tweak knob, and heaven-knows-what else. Randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04)
Thank you for your comments and I'm sorry for responding late. On Aug 20, 2013, at 3:37 PM, Juergen Schoenwaelder j.schoenwael...@jacobs-university.de wrote: 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). Now I've confirmed that vmAutoStart touches persistent config in libvirt. I agree that vmAutoStart probably touches persistent config in the most of implementations because it takes the effect at the next boot sequence of the hypervisor. If an implementation has one-shot config only for the next boot, it should be another object. Thus, I'll change the MAX-ACCESS of vmAutoStart to read-only. Thank you. Hirochika -- Hirochika Asai pa...@hongo.wide.ad.jp, The University of Tokyo ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04)
On 8/24/13 5:27 AM, Hirochika Asai wrote: Thank you for your comments and I'm sorry for responding late. On Aug 20, 2013, at 3:37 PM, Juergen Schoenwaelder j.schoenwael...@jacobs-university.de wrote: 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). Now I've confirmed that vmAutoStart touches persistent config in libvirt. I agree that vmAutoStart probably touches persistent config in the most of implementations because it takes the effect at the next boot sequence of the hypervisor. If an implementation has one-shot config only for the next boot, it should be another object. Thus, I'll change the MAX-ACCESS of vmAutoStart to read-only. Thanks. Joe -- 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
Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04)
Hi - From: Joe Marcus Clarke jcla...@cisco.com Sent: Aug 23, 2013 11:56 AM To: Michael MacFaden m...@vmware.com, opsawg@ietf.org Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04) ... My other comment (not quoted here) is that I was asking if some more explicit text could be added to the compliance section of the MIB that says these objects should be implemented read-write if they can be done in a non-persistent way (essentially incorporating text from Section 3.2 into the MIB module itself). Just to be absolutely clear... Are you requesting that the normative text state that the values assigned to these object-types SHOULD NOT or MUST NOT persist across reboots? I really don't like the idea of standards prohibiting potentially useful functionality. Randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04)
On 8/23/13 3:41 PM, Randy Presuhn wrote: Hi - From: Joe Marcus Clarke jcla...@cisco.com Sent: Aug 23, 2013 11:56 AM To: Michael MacFaden m...@vmware.com, opsawg@ietf.org Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04) ... My other comment (not quoted here) is that I was asking if some more explicit text could be added to the compliance section of the MIB that says these objects should be implemented read-write if they can be done in a non-persistent way (essentially incorporating text from Section 3.2 into the MIB module itself). Just to be absolutely clear... Are you requesting that the normative text state that the values assigned to these object-types SHOULD NOT or MUST NOT persist across reboots? I really don't like the idea of standards prohibiting potentially useful functionality. I was asking for the latter since this MIB is not about configuration. I think it would be a POLA violation if one vendor did a persistent implementation and some did a volatile implementation. Joe -- 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
Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04)
On 8/23/13 5:01 PM, Michael MacFaden wrote: Hi Joe, Think there is agreement on the list that changes to the objects reported in VMM-MIB are not coming in through SNMP. If VMM-MIB has managed objects whose value are configured via other means *and* the hypervisor in question separates out (in cisco parlance) running-config (in memory) vs config (persisted) then what value will the agent report? Operational status would be the way I would read it given the current MIB definition. Now, if the VM is shutdown, that operational state would match the config state (for something like memory/CPU). Joe Thanks, Mike - Original Message - I understand MAX-ACCESS and MIN-ACCESS. At this point I'm not arguing the access type as you've pointed out this can be non-persistently writable, and thus not a configuration object. In this comment I was merely inquiring, mainly out of curiosity, about the use case of an operator changing these values via SNMP vs. some other API mechanism. Meaning, today I see most MIB objects being read-only and used for monitoring or data collection. Writable objects are typically being pushed to APIs such as NETCONF. In _this_ case, I just assumed operators would be more comfortable changing aspects of a VM using a connection-oriented API vs. an SNMP SET. My other comment (not quoted here) is that I was asking if some more explicit text could be added to the compliance section of the MIB that says these objects should be implemented read-write if they can be done in a non-persistent way (essentially incorporating text from Section 3.2 into the MIB module itself). Joe -- 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 -- 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
Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04)
On Wed, Aug 21, 2013 at 02:27:08PM -0400, Joe Marcus Clarke wrote: 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. In the MIB world, we have ways to express things in such a way that people who want to implement a writable object can do so without causing costs to those who prefer to not do so. This is why we have MAX-ACCESS (what makes 'protocol sense' - means in principle this is a writable object) and MIN-ACCESS (the minimal level of access - means the minimum access one has to implement in order to comply to a conformance definition). /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/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04)
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
Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04)
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. 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? 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). /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/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04)
Marking this proposal as Joe-3 JMC: The purpose of this MIB is not to provide configuration of the hypervisor. Quoting section 3.2: The MIB module provides a few writable objects that can be used to make non-persistent changes, e.g., changing the memory allocation or the CPU allocation. It is not the goal of this MIB module to provide a configuration interface for virtual machines since other protocols and data modeling languages are more suitable for this task. Right. To that end, I find objects like vmAutoStart, vmMinCpuNumber, vmMaxCpuNumber, vmMinMem, and vmMaxMem strange. For starters, vmAutoStart mentions the word configuration in its description. And the other objects, at least from a VMware standpoint are actually specified in the VM's configuration. One would have to, for example, shutdown the VM to increase the number of vCPUs allocated to the VM. Such behavior really depends on the hypervisor. Adding a CPU while VM is running has been a feature of VMware for some time now: http://pubs.vmware.com/vsphere-4-esx-vcenter/index.jsp?topic=/com.vmware.vsphere.vmadmin.doc_41/vsp_vm_guide/configuring_virtual_machines/t_change_cpu_hotplug_settings.html Therefore, I feel all of these objects represent persistent changes to the hypervisor in support of the respective VM. I think these objects should go away and only the read-only objects showing current vCPU allocation, affinity, and memory stats should remain. As for auto-start, that can be read-only. My position as well. Once you go read-create/write the complexity grows and description fall short of any real standard behavior in response to a mutational set is almost always lost. The alternative is to say that some persistent changes will be allowed (such as auto-start), but general VM resource configuration will be out of scope. Mark this as Joe-3A. As I said above, I'm not interested in standardizing configuration of Virtual Machines via SNMP. Neither are the operators I know. Mike MacFaden Staff Engineer RD Apps VMware, Inc Palo Alto CA ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04)
On Mon, Aug 19, 2013 at 11:26:06AM -0700, Michael MacFaden wrote: Marking this proposal as Joe-3 JMC: The purpose of this MIB is not to provide configuration of the hypervisor. Quoting section 3.2: The MIB module provides a few writable objects that can be used to make non-persistent changes, e.g., changing the memory allocation or the CPU allocation. It is not the goal of this MIB module to provide a configuration interface for virtual machines since other protocols and data modeling languages are more suitable for this task. Right. To that end, I find objects like vmAutoStart, vmMinCpuNumber, vmMaxCpuNumber, vmMinMem, and vmMaxMem strange. For starters, vmAutoStart mentions the word configuration in its description. And the other objects, at least from a VMware standpoint are actually specified in the VM's configuration. One would have to, for example, shutdown the VM to increase the number of vCPUs allocated to the VM. Such behavior really depends on the hypervisor. Adding a CPU while VM is running has been a feature of VMware for some time now: http://pubs.vmware.com/vsphere-4-esx-vcenter/index.jsp?topic=/com.vmware.vsphere.vmadmin.doc_41/vsp_vm_guide/configuring_virtual_machines/t_change_cpu_hotplug_settings.html Therefore, I feel all of these objects represent persistent changes to the hypervisor in support of the respective VM. I think these objects should go away and only the read-only objects showing current vCPU allocation, affinity, and memory stats should remain. As for auto-start, that can be read-only. My position as well. Once you go read-create/write the complexity grows and description fall short of any real standard behavior in response to a mutational set is almost always lost. The alternative is to say that some persistent changes will be allowed (such as auto-start), but general VM resource configuration will be out of scope. Mark this as Joe-3A. As I said above, I'm not interested in standardizing configuration of Virtual Machines via SNMP. Neither are the operators I know. 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. /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/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04)
On 8/19/13 2:26 PM, Michael MacFaden wrote: Marking this proposal as Joe-3 JMC: The purpose of this MIB is not to provide configuration of the hypervisor. Quoting section 3.2: The MIB module provides a few writable objects that can be used to make non-persistent changes, e.g., changing the memory allocation or the CPU allocation. It is not the goal of this MIB module to provide a configuration interface for virtual machines since other protocols and data modeling languages are more suitable for this task. Right. To that end, I find objects like vmAutoStart, vmMinCpuNumber, vmMaxCpuNumber, vmMinMem, and vmMaxMem strange. For starters, vmAutoStart mentions the word configuration in its description. And the other objects, at least from a VMware standpoint are actually specified in the VM's configuration. One would have to, for example, shutdown the VM to increase the number of vCPUs allocated to the VM. Such behavior really depends on the hypervisor. Adding a CPU while VM is running has been a feature of VMware for some time now: http://pubs.vmware.com/vsphere-4-esx-vcenter/index.jsp?topic=/com.vmware.vsphere.vmadmin.doc_41/vsp_vm_guide/configuring_virtual_machines/t_change_cpu_hotplug_settings.html Ah, I haven't played with hotplug. Nonetheless, I would expect something like this to be persistent vs. available for the current like of the VM, correct? Something more transient would be the option to boot into the BIOS on next boot... Therefore, I feel all of these objects represent persistent changes to the hypervisor in support of the respective VM. I think these objects should go away and only the read-only objects showing current vCPU allocation, affinity, and memory stats should remain. As for auto-start, that can be read-only. My position as well. Once you go read-create/write the complexity grows and description fall short of any real standard behavior in response to a mutational set is almost always lost. The alternative is to say that some persistent changes will be allowed (such as auto-start), but general VM resource configuration will be out of scope. Mark this as Joe-3A. As I said above, I'm not interested in standardizing configuration of Virtual Machines via SNMP. Neither are the operators I know. Yeah, I gather, and I agree. That's why options like CPU and memory make me a bit uneasy as I see them as more configuration. Joe Mike MacFaden Staff Engineer RD Apps VMware, Inc Palo Alto CA -- 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
Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04)
On 8/19/13 2:34 PM, Juergen Schoenwaelder wrote: On Mon, Aug 19, 2013 at 11:26:06AM -0700, Michael MacFaden wrote: Marking this proposal as Joe-3 JMC: The purpose of this MIB is not to provide configuration of the hypervisor. Quoting section 3.2: The MIB module provides a few writable objects that can be used to make non-persistent changes, e.g., changing the memory allocation or the CPU allocation. It is not the goal of this MIB module to provide a configuration interface for virtual machines since other protocols and data modeling languages are more suitable for this task. Right. To that end, I find objects like vmAutoStart, vmMinCpuNumber, vmMaxCpuNumber, vmMinMem, and vmMaxMem strange. For starters, vmAutoStart mentions the word configuration in its description. And the other objects, at least from a VMware standpoint are actually specified in the VM's configuration. One would have to, for example, shutdown the VM to increase the number of vCPUs allocated to the VM. Such behavior really depends on the hypervisor. Adding a CPU while VM is running has been a feature of VMware for some time now: http://pubs.vmware.com/vsphere-4-esx-vcenter/index.jsp?topic=/com.vmware.vsphere.vmadmin.doc_41/vsp_vm_guide/configuring_virtual_machines/t_change_cpu_hotplug_settings.html Therefore, I feel all of these objects represent persistent changes to the hypervisor in support of the respective VM. I think these objects should go away and only the read-only objects showing current vCPU allocation, affinity, and memory stats should remain. As for auto-start, that can be read-only. My position as well. Once you go read-create/write the complexity grows and description fall short of any real standard behavior in response to a mutational set is almost always lost. The alternative is to say that some persistent changes will be allowed (such as auto-start), but general VM resource configuration will be out of scope. Mark this as Joe-3A. As I said above, I'm not interested in standardizing configuration of Virtual Machines via SNMP. Neither are the operators I know. 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. Is there a strong push from operators to toggle these values via SNMP? 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
