Hi Jon, On Sep 27, 2012, at 13:01, Jon Hudson <[email protected]> wrote:
> Greetings Kireeti =) > > My notation was to indicated separate vlans A and B. I should have been more > clear. I was describing what I see today not what I imagine things will be > like with something like NVo3 in place. Sorry for the lack of clarity. Kind of what I guessed. When you say "I don't want VM_A_01 to touch VM_A_08", wouldn't you do that by putting them in different vlans, rather than both in vlan A? > But to your question I would want any system that can elastically 1.) Clone a > VM from template or source 2.) Give it a new unique ipaddr and name 3.) > assign it relevant gateway/network/netmask/dns info would also 4.) change/add > whatever firewall, logging, backup, access_control, and intra_VN policy > needed. I can see inter-VN policy. Can you help me see how an intra-VN policy can be made elastic? > Otherwise it's not very elastic in my opinion. Totally agree! > Now I suppose you could have a system that takes a pool of pre-instantiated > VMs that already have all relevant configuration information setup, and the > elasticity is to suspend and resume VMs based on need. But even in that case, > the needed policies could be set up the same way and taken from say a > "quarantine" level and promoted to "full production" as part of the process > of unsuspending the VM. I suppose. Sounds like "poor man's elasticity" to me. :-) Kireeti > J > > On Thu, Sep 27, 2012 at 10:51 AM, Kireeti Kompella > <[email protected]> wrote: > Hi Jon, > > On Sep 27, 2012, at 10:39 , Jon Hudson <[email protected]> wrote: > > >> However, in Data Center, a closed used group have many VMs or servers. > >> Although an NVO instance provides a communication for the VMs in the > >> group, some VMs may not need to communicate with some other VMs. > > > > True, and desirable. If VM_A_01 only needs to talk to VM_A_02-07, then I > > don't want it to be able to touch VM_A_08 or VM_B_x. > > Two very different things: > > Lucy said: "some VMs may not need to communicate" … but that could change, > and is not dictated by policy, but rather by current need. > > IMO, what you are asking calls for VM_A_01 and VM_A_02-07 to be in (say) > VN_A, and VM_A_08 and VM_B_x in different VN(s) (not sure what the numbering > means, but I'm just going with the flow.) > > If one were to put VM_A_01 and VM_A_08 in the same VN, one would have to > hand-craft the intra-VN policies. Doable, but not scalable > (administratively). For example, what happens if a new VM, VM_A_22 shows up > (elasticity) … who can it talk to? > > KIreeti. > > > > > -- > "Do not lie. And do not do what you hate." >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
