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
- Original Message -
> On 8/19/13 2:55 PM, Michael MacFaden wrote:
> >
> > Marking this proposal as Joe-5
> >
> >> Section 3.3:
> >>
> >> Concerning vmNetworkTable.
> >>
> >> JMC: I think there should be a vmNetworkVlan object in this table that
> >> describes the VLAN ID associated to
On 8/19/13 4:52 PM, Michael MacFaden wrote:
>> If I understand you right this time, and the VM
>> inserts entLogicalTable entries in the HV ENTITY-MIB, would it not make
>> sense to add a pointer in the VMM-MIB to indicate their index in the
>> entLogicalTable?
>
> Yes, exactly. Create a row in en
> If I understand you right this time, and the VM
> inserts entLogicalTable entries in the HV ENTITY-MIB, would it not make
> sense to add a pointer in the VMM-MIB to indicate their index in the
> entLogicalTable?
Yes, exactly. Create a row in entLogicalTable if there is data to provide
regarding
On 8/19/13 3:00 PM, Michael MacFaden wrote:
>
> Marking this proposal as Joe-7
>
>> Section 3.3:
>>
>> Concerning vmNotifications.
>>
>> JMC: I think there should be a general notification for VM changing
>> state. The reason for this is that some of the state transitions
>> described in section
On 8/19/13 2:55 PM, Michael MacFaden wrote:
>
> Marking this proposal as Joe-5
>
>> Section 3.3:
>>
>> Concerning vmNetworkTable.
>>
>> JMC: I think there should be a vmNetworkVlan object in this table that
>> describes the VLAN ID associated to the underlying interface. This need
>> not be used
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
On 8/19/13 2:38 PM, Michael MacFaden wrote:
>> That's fair, and I understand that. My point was that when one is
>> looking at a VM, at least in vCenter, one can see an IP of the GOS. I
>> thought it would be useful to pass that information down the MIB as
>> well. And, yes, I get that this may
Marking this proposal as Joe-7
> Section 3.3:
>
> Concerning vmNotifications.
>
> JMC: I think there should be a general notification for VM changing
> state. The reason for this is that some of the state transitions
> described in section 3.2 Figure 2 can take a long time (e.g., running ->
>
Marking this proposal as Joe-5
> Section 3.3:
>
> Concerning vmNetworkTable.
>
> JMC: I think there should be a vmNetworkVlan object in this table that
> describes the VLAN ID associated to the underlying interface. This need
> not be used for every hypervisor, but I think it is very important
On Mon, Aug 19, 2013 at 02:38:40PM -0400, Joe Marcus Clarke wrote:
>
> Sure. This just presents another, maybe simpler way to find VMs in
> particular in the network. I fully understand that this address may be
> 0, but I know at least for the VMs I maintain, it would be a useful value.
>
I do
Marking this proposal as Joe-4
> Section 3.3:
>
> vmNetworkEntry OBJECT-TYPE
>SYNTAX VmNetworkEntry
>MAX-ACCESS not-accessible
>STATUS current
>DESCRIPTION
>"An entry for one virtual storage device attached to the
>virt
On 8/19/13 2:30 PM, Juergen Schoenwaelder wrote:
> On Mon, Aug 19, 2013 at 11:02:15AM -0700, Michael MacFaden wrote:
>>
>> Marking this item as Proposal: Joe-2
>>
>>> JMC: I think there should be an object in this table such as vmMgmtAddr,
>>> which lists the management IP address of the VM. This
> That's fair, and I understand that. My point was that when one is
> looking at a VM, at least in vCenter, one can see an IP of the GOS. I
> thought it would be useful to pass that information down the MIB as
> well. And, yes, I get that this may not be known the HV, and thus may be 0.
>
What
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,
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
> >
On Mon, Aug 19, 2013 at 11:02:15AM -0700, Michael MacFaden wrote:
>
> Marking this item as Proposal: Joe-2
>
> > JMC: I think there should be an object in this table such as vmMgmtAddr,
> > which lists the management IP address of the VM. This would be akin to
> > what one would see in vCenter f
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
On 8/19/13 2:02 PM, Michael MacFaden wrote:
>
> Marking this item as Proposal: Joe-2
>
>> JMC: I think there should be an object in this table such as vmMgmtAddr,
>> which lists the management IP address of the VM. This would be akin to
>> what one would see in vCenter for a VMware-controlled VM
On 8/19/13 1:55 PM, Michael MacFaden wrote:
> Hi Joe,
>
> Thanks for sharing this, my comments inline.
>
> Marking this item as Proposal: Joe-1
>
>> JMC: While I think the intention is to say that this MIB pulls from
>> other, existing MIBs for common virtualization platforms, it may come
>> acr
Marking this item as Proposal: Joe-2
> JMC: I think there should be an object in this table such as vmMgmtAddr,
> which lists the management IP address of the VM. This would be akin to
> what one would see in vCenter for a VMware-controlled VM. As a manager,
> this would be very useful in being
Hi Joe,
Thanks for sharing this, my comments inline.
Marking this item as Proposal: Joe-1
> JMC: While I think the intention is to say that this MIB pulls from
> other, existing MIBs for common virtualization platforms, it may come
> across as being limited to only those platforms. Perhaps it i
I agree -- I see no conflict with l2tpext work.
-- Carlos.
On Aug 19, 2013, at 12:54 PM, Ignacio Goyret
wrote:
> I don't see any conflict with l2tpext wg work.
> -Ignacio
>
> At 07:43 8/19/2013, Ted Lemon wrote:
>> I've taken on the conflict review for draft-pfaff-ovsdb-proto-02, which is
>>
23 matches
Mail list logo
