[Lxc-users] updated lxc template for debian squeeze - with attachedscript ; )

[Geordy Korte]

Hello,

Sorry to revive an old thread but I would like to share some information
with you that might give you an insight into why an OUI is advisable.

I work for IBM as a Technical Pre-Sales consultant for Blade network
technologies (what a mouth full). BNT creates switches that are very very
good but that is not the point. One of the features that we have is VMready
which basically means that when the switch detects a Virtualized uplink to a
server it will analyse the traffic and create PORTS for every virtual host
running on that server. This tech allows you to create policy for that port
with which you can set QOS, ACL and anything else you would like. Now
Vmready is fully vmotion enabled so that when you migrate a virtualhost to
another server, the policy moves with it.

The reason for me writing this to the list is that Vmready works for
Hypervisor, vmware, kvm, powervm...  and it only works because of the mac
address. Each switch has a database of Macs that belong to a virtualization
product and by matching passing traffic to the list Vmready works. Should
LXC get it's own block then I can make sure it's added to the Vmready
database.

Sorry if this sounds like a sales pitch... it's not meant too.

Geordy Korte

On Fri, Mar 11, 2011 at 11:08 PM, Brian K. White <brian at aljex.com> wrote:

> On 3/11/2011 10:14 AM, Michael H. Warfield wrote:
> > On Thu, 2011-03-10 at 19:09 +0000, Walter Stanish wrote:
> >>>>> ...  I have read up on the OUI documentation and
> >>>>> looking at the detail on the site LXC could opt for a 32bit OUI which
> would
> >>>>> cost $600 for one block. The dev guys might want to setup a pledge
> program...
> >>
> >>>> I will pay for it.
> >>
> >>> I too am willing to pay the whole thing, so, halvsies? Or see how many
> >>> others want to split even?
> >
> >> Sounds good.  I guess we can nominate you as the finance go-to on this
> >> one then :)
> >
> >> Let us know details when they emerge.
> >
> > Can someone explain to me why we can't simply use a block of addresses
> > with the 0200 (local administration) bit or'ed in.  Out of 48 bits of
> > addressing, we can use 46 bits of them for anything we want as long as
> > that bit is set and the 0100 bit (multicast) is clear.  By the standard,
> > those are locally managed and allocated MAC addresses that are not
> > guaranteed to be globally unique.  They don't even need to be unique in
> > an entire network, only on the local subnet.  Use any convention you
> > want.  Stuff the 32 bit IP address of the host in the lower 32 bits and
> > you've still got 14 bits worth of assignable addressing per host.
> > That's what that bit is intended for.
>
> That is exactly what I do myself.
>
> I'm not sure there is a specific need for a recognizable lxc address
> space, but exactly the same thing could be said about xen and for some
> reason they have one. I don't claim it's necessary I just claim three
> things:
>
> 1) It wouldn't hurt.
>
> 2) It's cheap enough in both cash and time not to matter, more than
> enough volunteers have already presented themselves.
>
> 3) I don't presume that because I don't perceive a reason, that no
> reason exists.
>
> One scenario I envision off-hand would be that automated vmware tools
> and xen tools and lxc tools could each provision addresses from their
> own spaces and guaranteed never step on each others toes.
>
> --
> bkw
>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Lxc-users mailing list
> Lxc-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lxc-users
>



-- 
==============
Geordy Korte
MSN geordy at geordy.nl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20110423/50dd0caf/attachment.html>