On 5/26/14, 3:24 AM, Hirochika Asai wrote:
Dear all,
We'd like to discuss the read-write access in the proposed MIB about virtual
machine monitoring: http://tools.ietf.org/html/draft-ietf-opsawg-vmm-mib .
It has 10 read-write objects. All of them do not affect persistent configuration
of hypervisor or virtual machines. However, according to a comment during
the previous IETF meeting, the IESG statement also suggests not to include
read-write objects even if they do not persist after the restart of the agent or
system.
In this sense, I think the following 8 objects will be read-only.
1. vmAdminState
2. vmCurCpuNumber
3. vmMinCpuNumber
4. vmMaxCpuNumber
5. vmCurMem
6. vmMinMem
7. vmMaxMem
8. vmCpuAffinity
The following two objects require discussion because these objects are not
related to hypervisor or virtual machines, but notifications of SNMP.
The reason why I think they can be kept read-write is they are control objects
of an SNMP agent and it does not affect the configuration of monitoring targets.
However, from the viewpoint of security, I can agree that they should also be
read-only and operators configure them not through SNMP (or something) but
through another configuration scheme such as editing a configuration file.
9. vmPerVMNotificationsEnabled
10. vmBulkNotificationsEnabled
I hope you give us your comments on the access of 10 objects.
I was vocal against persisting some of these objects, but I think
offering the ability to write to them for running VMs has value (i.e.,
changes would not persist), but I can see how that could lead to
confusion. If you leave 1-8 as read-only, that is very clear.
I think leaving 9 and 10 read-write is fine.
Joe
Thank you.
Hirochika
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
