Re: [Lxc-users] updated lxc template for debian squeeze - with attachedscript ; )
Not at all, this is good info. It's not an old thread as long as the proposed task hasn't been done yet, and it hasn't. I still need to finish researching what exactly we should get, and then how. -- bkw On 4/23/2011 3:25 AM, Geordy Korte wrote: 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 br...@aljex.com mailto:br...@aljex.com wrote: On 3/11/2011 10:14 AM, Michael H. Warfield wrote: On Thu, 2011-03-10 at 19:09 +, 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@lists.sourceforge.net mailto:Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users -- == Geordy Korte MSN geo...@geordy.nl mailto:geo...@geordy.nl -- Fulfilling the Lean Software Promise Lean software platforms are now widely adopted and the benefits have been demonstrated beyond question. Learn why your peers are replacing JEE containers with lightweight application servers - and what you can gain from the move. http://p.sf.net/sfu/vmware-sfemails ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] updated lxc template for debian squeeze - with attachedscript ; )
On 3/11/2011 10:14 AM, Michael H. Warfield wrote: On Thu, 2011-03-10 at 19:09 +, 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] updated lxc template for debian squeeze - with attachedscript ; )
I have been following this thread and have started to investigate if my compagnie might be willing to donate a range of macs to lxc. Give me about a week And i will know more. Well that was fun. After spending much of last week trying to figure out who was responsible for the OUI for my company I came to a dead end. So unfortunately I can't help. 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 or paypal donation account to see if they might raise the 600 Bucks. I would donate for sure. I will pay for it. Please let me know the procedure to purchase. - Walter -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] updated lxc template for debian squeeze - with attachedscript ; )
... 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. - Walter -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] updated lxc template for debian squeeze - with attachedscript ; )
Hi,
i have tried to find an rfc about this but have failed, instead, the
only (serious/credible) documentation i could find was
http://wiki.xen.org/xenwiki/XenNetworking#head-d5446face7e308f577e5aee1c72cf9d156903722
,
so i updated the script accordingly, here is the updated patch.
again,
Dear Jon,
at the given link, right at the last sentence of the paragraph, you'll find:
It's recommended to use a MAC address inside the range 00:16:3e:xx:xx:xx.
This address range is reserved for use by Xen.
You see, there's no only the reserved prefix 00:50:C2, but there is at least
one more official MAC space 00:16:3e reserved by Xen. Why do you don't use this
and follow my simple or advanced suggestions
macaddr=$(echo -n 00:50:C2; hexdump -n 3 -v -e '/1 :%02X'
/dev/urandom)
macaddr=$(echo -n 00:50:C2; echo ${hostname:0:1}${hostname: -2}
$(head -c 3 /dev/urandom) | hexdump -n 3 -v -e '/1 :%02X')
Of corse, the prefix may be replaced by any of this appropriate Prefixes.
Probably just Daniel will know, if there is already a MAC space requested by
the LXC project.
Guido
--
Free Software Download: Index, Search Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT data
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business
insights. http://p.sf.net/sfu/splunk-dev2dev
___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] updated lxc template for debian squeeze - with attachedscript ; )
Hi,
i have tried to find an rfc about this but have failed, instead, the
only (serious/credible) documentation i could find was
http://wiki.xen.org/xenwiki/XenNetworking#head-d5446face7e308f577e5aee1c72cf9d156903722
,
so i updated the script accordingly, here is the updated patch.
again,
Signed-off-by: John Soros joh...@r0x0r.me
--
the router thinks its a printer.
On Fri, 25 Feb 2011 09:03:55 +0100
Jäkel, Guido g.jae...@dnb.de wrote:
Dear John,
- generate random mac address for the guest so it gets always the
same lease from a dhcp server
You suggest doing this by
macaddr=$(echo -n 00; hexdump -n 5 -v -e '/1
:%02X' /dev/urandom)
I think this is a little bit to random. The german Wikipedia tells
at http://de.wikipedia.org/wiki/MAC-Adresse about a reserved MAC
range for private use (sorry, it's not in corresponding the English
article):
[Neben der OUI existiert auch ein kleiner Adressbereich (IAB
- Individual Address Block), der für Privatpersonen und kleine Firmen
und Organisationen vorgesehen ist, die nicht so viele Adressen
benötigen. Die Adresse beginnt mit 00-50-C2 und wird von drei
weiteren Hex-Ziffern gefolgt (12 Bits), die für jede Organisation
vergeben werden. Damit verbleibt der Adressbereich innerhalb der Bits
11 bis 0 nutzbar wodurch 212 = 4096 individuelle Adressen möglich
sind.]
Maybe we should take respect to this and we should use
macaddr=$(echo -n 00:50:C2; hexdump -n 3 -v -e '/1
:%02X' /dev/urandom)
for this. Another approach is to derive it from the designated name
of the container (i.e. $hostname in terms of the script). Because
there might be typical clustering naming schemes based on a name and
some digits, I suggest to select the first and the last two
characters of the hostname (filled by random for the unlikely case of
a hostname shorter than 3 chars)
echo -n 00:50:C2; echo ${hostname:0:1}${hostname: -2}
$(head -c 3 /dev/urandom) | hexdump -n 3 -v -e '/1 :%02X'
- 00:50:C2:first:nextlast:last filled by random
@Daniel: Because this will have a common use for all, it might be
included into the lxc-conf parser
[lxc.network.hwaddr: the interface mac address is
dynamically allocated by default to the virtual interface ...]
We maybe should have a special keyword for a derived semi-static
MAC that would not change at every startup of the container but may
be calculated by the formula given above.
Guido
--
Free Software Download: Index, Search Analyze Logs and other IT
data in Real-Time with Splunk. Collect, index and harness all the
fast moving IT data generated by your applications, servers and
devices whether physical, virtual or in the cloud. Deliver compliance
at lower cost and gain new business insights.
http://p.sf.net/sfu/splunk-dev2dev
___ Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users
--- /usr/lib/lxc/templates/lxc-debian 2010-08-04 19:27:58.0 +0200
+++ lxc-debian 2011-03-01 18:15:12.895043450 +0100
@@ -66,10 +66,10 @@
# reconfigure some services
if [ -z $LANG ]; then
chroot $rootfs locale-gen en_US.UTF-8
- chroot $rootfs update-locale LANG=en_US.UTF-8
+ chroot $rootfs update-locale LC_ALL=en_US.UTF-8 LANG=en_US.UTF-8
else
chroot $rootfs locale-gen $LANG
- chroot $rootfs update-locale LANG=$LANG
+ chroot $rootfs update-locale LANG=$LANG LC_ALL=$LANG
fi
# remove pointless services in a container
@@ -77,6 +77,12 @@
chroot $rootfs /usr/sbin/update-rc.d -f hwclock.sh remove
chroot $rootfs /usr/sbin/update-rc.d -f hwclockfirst.sh remove
+# do some adjustment for the final image
+mknod -m 666 $rootfs/dev/tty1 c 4 1
+mknod -m 666 $rootfs/dev/tty2 c 4 2
+mknod -m 666 $rootfs/dev/tty3 c 4 3
+mknod -m 666 $rootfs/dev/tty4 c 4 4
+
echo root:root | chroot $rootfs chpasswd
echo Root password is 'root', please change !
@@ -90,7 +96,7 @@
locales,\
libui-dialog-perl,\
dialog,\
-dhcp-client,\
+isc-dhcp-client,\
netbase,\
net-tools,\
iproute,\
@@ -110,7 +116,7 @@
echo Downloading debian minimal ...
debootstrap --verbose --variant=minbase --arch=$arch \
--include $packages \
- lenny $cache/partial-$arch http://ftp.debian.org/debian
+ squeeze $cache/partial-$arch http://ftp.debian.org/debian
if [ $? -ne 0 ]; then
echo Failed to download the rootfs, aborting.
return 1
@@ -130,13 +136,13 @@
# make a local copy of the minidebian
echo -n Copying rootfs to $rootfs...
-cp -a $cache/rootfs-$arch $rootfs || return 1
+cp -a $cache/rootfs-$arch/* $rootfs || return 1
return 0
}
install_debian()
{
-cache=/var/cache/lxc/debian
+cache=/var/cache/lxc/debian-squeeze
rootfs=$1
mkdir -p /var/lock/subsys/
(
@@ -182,8 +188,19 @@
Re: [Lxc-users] updated lxc template for debian squeeze - with attachedscript ; )
Dear John,
- generate random mac address for the guest so it gets always the same
lease from a dhcp server
You suggest doing this by
macaddr=$(echo -n 00; hexdump -n 5 -v -e '/1 :%02X' /dev/urandom)
I think this is a little bit to random. The german Wikipedia tells at
http://de.wikipedia.org/wiki/MAC-Adresse about a reserved MAC range for
private use (sorry, it's not in corresponding the English article):
[Neben der OUI existiert auch ein kleiner Adressbereich (IAB -
Individual Address Block), der für Privatpersonen und kleine Firmen und
Organisationen vorgesehen ist, die nicht so viele Adressen benötigen. Die
Adresse beginnt mit 00-50-C2 und wird von drei weiteren Hex-Ziffern gefolgt (12
Bits), die für jede Organisation vergeben werden. Damit verbleibt der
Adressbereich innerhalb der Bits 11 bis 0 nutzbar wodurch 212 = 4096
individuelle Adressen möglich sind.]
Maybe we should take respect to this and we should use
macaddr=$(echo -n 00:50:C2; hexdump -n 3 -v -e '/1 :%02X'
/dev/urandom)
for this. Another approach is to derive it from the designated name of the
container (i.e. $hostname in terms of the script). Because there might be
typical clustering naming schemes based on a name and some digits, I suggest to
select the first and the last two characters of the hostname (filled by random
for the unlikely case of a hostname shorter than 3 chars)
echo -n 00:50:C2; echo ${hostname:0:1}${hostname: -2} $(head -c 3
/dev/urandom) | hexdump -n 3 -v -e '/1 :%02X'
- 00:50:C2:first:nextlast:last filled by random
@Daniel: Because this will have a common use for all, it might be included into
the lxc-conf parser
[lxc.network.hwaddr: the interface mac address is dynamically
allocated by default to the virtual interface ...]
We maybe should have a special keyword for a derived semi-static MAC that
would not change at every startup of the container but may be calculated by the
formula given above.
Guido
--
Free Software Download: Index, Search Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT data
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business
insights. http://p.sf.net/sfu/splunk-dev2dev
___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users
