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 R&D 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
