[Engine-devel] port mirroring REST API

Shahar Havivi shaharh at redhat.com
Mon May 21 13:37:36 UTC 2012


On 21.05.12 16:36, Michael Pasternak wrote:
> On 05/21/2012 04:22 PM, Livnat Peer wrote:
> > On 21/05/12 16:19, Michael Pasternak wrote:
> >> On 05/21/2012 03:54 PM, Shahar Havivi wrote:
> >>> On 21.05.12 15:38, Michael Pasternak wrote:
> >>>>
> >>>> Hi Livnat,
> >>>>
> >>>> On 05/21/2012 02:55 PM, Livnat Peer wrote:
> >>>>> Hi All,
> >>>>>
> >>>>> After digging into the port mirroring feature I suggest a different
> >>>>> modeling of it in the API.
> >>>>>
> >>>>> The current modeling is to add to vnic a boolean property of
> >>>>> port-mirroring, e.g.
> >>>>>
> >>>>> api/vms/{vm-id}/nics
> >>>>>
> >>>>> <nics>
> >>>>>  <nic>
> >>>>>   ...
> >>>>>   <network href="/api/networks/{network-id}" id="{network-id}"/>
> >>>>>   <port-mirroring> true </port mirroring>
> >>>>>  </nic>
> >>>>> </VM>
> >>>>>
> >>>>> This modeling imply 2 limitations:
> >>>>> 1. The vnic must be connected to the network it wants to monitor
> >>>>> 2. the nic can mirror only a single network
> >>>>>
> >>>>> Both of the above limitations are correct to the current implementation.
> >>>>> Going forward we might want to introduce the above functionalities and
> >>>>> the above modeling won't hold.
> >>>>> Instead of the above I suggest to change the port-mirroring property to
> >>>>> a list of networks.
> >>>>>
> >>>>> <nics>
> >>>>>  <nic>
> >>>>>   ...
> >>>>>   <network href="/api/networks/{network-id}" id="{network-id}"/>
> >>>>>   <port-mirroring>
> >>>>>    <network href="/api/networks/{network-id}" id="{network-id}"/>
> >>>>>     ....
> >>>>>   </port mirroring>
> >>>>>  </nic>
> >>>>> </VM>
> >>>>>
> >>>>> In this version we'll validate that the network under port-mirroring is
> >>>>> equal to the network the vnic is connected to, in future versions we can
> >>>>> remove this validation without changing the API.
> >>>>
> >>>> iiuc you saying that in future vnic might be connected to several
> >>>> networks simultaneously?
> >>> yes, maybe in next version
> >>
> >> in this case, api should be changed as at the moment we permit single network
> >> peer vnic, another option may be:
> >>
> >>  <nics>
> >>   <nic>
> >>    ...
> >>    <networks>
> >>      <network href="/api/networks/{network-id}" id="{network-id}">
> >>        <port-mirroring> true </port_mirroring>
> >>      </network>
> >>      <network href="/api/networks/{network-id}" id="{network-id}">
> >>        <port-mirroring> true </port_mirroring>
> >>      </network>
> >>    </networks>
> >>   </nic>
> >> </nics>
> >>
> >> this way we won't have to double network references, only disadvantage
> >> of this approach is abuse of network link, but we already have such
> >> precedents in api.
> > 
> > Hi Michael,
> > 
> > One of the issues I raised was to avoid association between the network
> > the nic is attached to and the networks the nic can monitor.
> > 
> > The implementation in VDSM does not require that the nic will be
> > connected to the network in order to monitor it. So going forward we
> > might connect the VM nic to intrusion-detection-network while the
> > monitoring will be for red network and blue network.
> > 
> > 
> > Thanks, Livnat
> 
> in this case +1 on your design.
Michael this mean that we are using Livnats design:

<nic>
 ...
 <network href="/api/networks/{network-id}" id="{network-id}"/>
 <port-mirroring>
  <network href="/api/networks/{network-id}" id="{network-id}"/>
   ....
 </port mirroring>
</nic>

and the engine stays with the same api, which mean that we need to "translate"
to the engine the value true in VmInterface and "translate" back from the
engine from boolean to network.
is that ok with you?

> 
> > 
> > 
> >>
> >>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> Thanks, Livnat
> >>>>
> >>>>
> >>>> -- 
> >>>>
> >>>> Michael Pasternak
> >>>> RedHat, ENG-Virtualization R&D
> >>
> >>
> > 
> 
> 
> -- 
> 
> Michael Pasternak
> RedHat, ENG-Virtualization R&D



More information about the Devel mailing list