Hey... On Sep 27, 2012, at 4:54 PM, Kireeti Kompella <[email protected]> wrote:
> 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? Yes ideally! However since today you can't move a live VM from one VLAN to another, more and more interpret "flat network" to mean one VLAN. And will then use per interface ACLs or other more silly things like playing with netmasks to create larger spheres of mobility. If you want every VM to have the option of moving to every possible hypervisor then you are either doing one VLAN, VLAN tagging, or putting hypervisors on multiple networks. To be very honest, it's all this madness that I am describing that makes NVo3 coming out right so very important. > >> 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? Well perhaps my image of intra-VN policies is off. But essentially what I was thinking was to have per VM profiles that trigger changes to Intra-VN (and inter-VN) policies based on the the addition, removal, or modification of VN membership or requirements. For example having quarantined VMs that you may want to have in the VN, pulling live data, but not responding to requests or being added to resource queues or even viewable until they are blessed and promoted to production. But perhaps I am thinking of intra-VN policies incorrectly? > >> 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. :-) Except some Datacenters don't allow dhcp and want pre-instantiated pre-configured VMs with static ipaddrs pre- allocated. It also doesn't help that the ability to clone based on load also allows for a very interesting denial of service attack =) But yes, I personally totally agree, dynamic instantiation and deletion based on metrics is the only fun way to do this. > > Kireeti > >> J >> >> On , 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
