Discussion:
updated lxc template for debian squeeze - with attached script ; )
(too old to reply)
John Soros
2011-02-24 16:47:57 UTC
Permalink
Hello list,
I have edited the lxc-debian script found in the lxc package in squeeze
to install squeeze guests. I have done a few modifications aswell, as
the script had a few minor problems (imho)
I'll document the additions i did here (apart from the update from lenny
to squeeze):
- mknod first four tty devices of the guest
- generate random mac address for the guest so it gets always the same
lease from a dhcp server
- add the network configuration to the guest configuration (otherwise
the host's network interface is used, which is quite confusing)
- require a hostname - i don't see what use is a machine that has the
same hostname as the host os.

Hope this helps someone
(sorry for the repost, i forgot the attachment..)
--
Increased sunspot activity.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lxc-debian-squeeze
Type: application/octet-stream
Size: 7287 bytes
Desc: not available
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20110224/e1fff72e/attachment.obj>
Daniel Lezcano
2011-02-24 21:43:01 UTC
Permalink
Post by John Soros
Hello list,
I have edited the lxc-debian script found in the lxc package in squeeze
to install squeeze guests. I have done a few modifications aswell, as
the script had a few minor problems (imho)
I'll document the additions i did here (apart from the update from lenny
- mknod first four tty devices of the guest
- generate random mac address for the guest so it gets always the same
lease from a dhcp server
- add the network configuration to the guest configuration (otherwise
the host's network interface is used, which is quite confusing)
- require a hostname - i don't see what use is a machine that has the
same hostname as the host os.
Hope this helps someone
(sorry for the repost, i forgot the attachment..)
Hi John,

thank you very much for the modifications. I can't take it as it is, you
should send a patch instead of the modified file.
The CONTRIBUTING file will give you some hints, no need to read the full
content ;)

Thanks again
-- Daniel
<javascript:void(0);>
John Soros
2011-02-24 23:13:51 UTC
Permalink
Right, sorry..
oh merry, the debian package doesn't contain that file.../me looks on sf
here is the patch,
Signed-off-by: John Soros <johnny at r0x0r.me>

(oops, really my day today, i just goofed again ;)

--
The keyboard isn't plugged in


On Thu, 24 Feb 2011 22:43:01 +0100
Post by Daniel Lezcano
Post by John Soros
Hello list,
I have edited the lxc-debian script found in the lxc package in
squeeze to install squeeze guests. I have done a few modifications
aswell, as the script had a few minor problems (imho)
I'll document the additions i did here (apart from the update from
- mknod first four tty devices of the guest
- generate random mac address for the guest so it gets always the
same lease from a dhcp server
- add the network configuration to the guest configuration
(otherwise the host's network interface is used, which is quite
confusing)
- require a hostname - i don't see what use is a machine that has
the same hostname as the host os.
Hope this helps someone
(sorry for the repost, i forgot the attachment..)
Hi John,
thank you very much for the modifications. I can't take it as it is,
you should send a patch instead of the modified file.
The CONTRIBUTING file will give you some hints, no need to read the
full content ;)
Thanks again
-- Daniel
<javascript:void(0);>
Jäkel, Guido
2011-02-25 08:03:55 UTC
Permalink
Dear John,
Post by John Soros
- 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
John Soros
2011-03-01 17:18:17 UTC
Permalink
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 <johnny at r0x0r.me>


--
the router thinks its a printer.


On Fri, 25 Feb 2011 09:03:55 +0100
Post by Jäkel, Guido
Dear John,
Post by John Soros
- 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
["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 at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lxc-debian.diff
Type: text/x-patch
Size: 2983 bytes
Desc: not available
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20110301/dca68b9c/attachment.bin>
Jäkel, Guido
2011-03-02 08:39:53 UTC
Permalink
Post by John Soros
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,
Post by John Soros
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
Brian K. White
2011-03-02 22:18:52 UTC
Permalink
Post by Jäkel, Guido
Post by John Soros
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,
Post by John Soros
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.
I would suggest exactly the opposite.

In my own container creation/management recipes, I specifically do _not_
use the xen prefix exactly _because_ that's what xen uses.
For the same reason I don't use any other known prefix used by hardware
or other vm systems.

I happen to use 02:00 but I don't suggest that specifically as
especially "righter" than any other in the reserved local/private range.
For one thing we probably can't realistically claim an address space
that large just for lxc.

But I do suggest don't use the same thing xen or vmware or openvz or
hyper-v etc uses, wherever there is any known consistent usage.
--
bkw
Jäkel, Guido
2011-03-03 07:45:44 UTC
Permalink
Post by Brian K. White
But I do suggest don't use the same thing xen or vmware or openvz or
hyper-v etc uses, wherever there is any known consistent usage.
Dear Brian,

i complete agree your argument. But this simply leads to the conclusion that someone(tm) have to start efforts to register a MAC-range for LXC as it is already done for the other products.

To use as a default, at least. If it's not "large enough" for someone's usecase, that this person will probably know how to deal with it.


Greetings

Guido
Geordy Korte
2011-03-03 12:48:42 UTC
Permalink
Hi,

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.

Mvg

Geordy Korte
(Sent via iphone so shorter then normal)
Post by Jäkel, Guido
Post by Brian K. White
But I do suggest don't use the same thing xen or vmware or openvz or
hyper-v etc uses, wherever there is any known consistent usage.
Dear Brian,
i complete agree your argument. But this simply leads to the conclusion that someone(tm) have to start efforts to register a MAC-range for LXC as it is already done for the other products.
To use as a default, at least. If it's not "large enough" for someone's usecase, that this person will probably know how to deal with it.
Greetings
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 at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users
Geordy Korte
2011-03-10 14:11:40 UTC
Permalink
Post by Geordy Korte
Hi,
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.

Geordy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20110310/a4c74f29/attachment.html>
Walter Stanish
2011-03-10 18:43:55 UTC
Permalink
Post by Geordy Korte
Post by Geordy Korte
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
Brian K. White
2011-03-10 19:03:16 UTC
Permalink
Post by Walter Stanish
Post by Geordy Korte
Post by Geordy Korte
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
I too am willing to pay the whole thing, so, halvsies? Or see how many
others want to split even?

But that's the easy part. I'm starting to read through the docs on line
to try to determine what would even be the most correct type of thing to
request in the first place.
--
bkw
Walter Stanish
2011-03-10 19:09:58 UTC
Permalink
Post by Brian K. White
Post by Walter Stanish
... ?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
Michael H. Warfield
2011-03-11 15:14:17 UTC
Permalink
Post by Walter Stanish
Post by Brian K. White
Post by Walter Stanish
... 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.
Post by Walter Stanish
- 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
--
Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20110311/1bbfa12a/attachment.pgp>
John Soros
2011-03-11 15:47:16 UTC
Permalink
Post by Michael H. Warfield
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.
Post by Walter Stanish
- Walter
isn't that what the script does? :
==snip==
rndbit=""
while [[ $rndbit != "2" && $rndbit != "6" && $rndbit != "A" && $rndbit != "E" ]]; do
rndbit="$(hexdump -n 1 -v -e '/1 "%02X"' /dev/urandom |sed 's,^.,,g' |tr -d '\n')"
done
macaddr=$(echo -n "0${rndbit}"; hexdump -n 5 -v -e '/1 ":%02X"' /dev/urandom)
==/snip==
I agree it's not as pretty as or'ing a random mac with 0200 but the result should be the same. Of course if someone finds a way to bitwise or on the commandline i'll be happy to update the patch.
Thanks,
(whoops, ok so how to be sure the adress is not multicast)
--
Sticky bits on disk.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20110311/e8c21b30/attachment.pgp>
Michael H. Warfield
2011-03-11 16:52:51 UTC
Permalink
Post by John Soros
Post by Michael H. Warfield
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.
Post by Walter Stanish
- Walter
==snip==
rndbit=""
while [[ $rndbit != "2" && $rndbit != "6" && $rndbit != "A" && $rndbit != "E" ]]; do
rndbit="$(hexdump -n 1 -v -e '/1 "%02X"' /dev/urandom |sed 's,^.,,g' |tr -d '\n')"
done
macaddr=$(echo -n "0${rndbit}"; hexdump -n 5 -v -e '/1 ":%02X"' /dev/urandom)
==/snip==
I agree it's not as pretty as or'ing a random mac with 0200 but the
result should be the same. Of course if someone finds a way to bitwise
or on the commandline i'll be happy to update the patch.
Thanks,
(whoops, ok so how to be sure the adress is not multicast)
Ok... Does this not work for you? Works for me...

[mhw at canyon ~]$ declare -i BYTE=$(( 0xC1 & ~ 3 | 2 ))
[mhw at canyon ~]$ echo ${BYTE}
194
(0xc2)

Since you're using the "[[" expression, I think you're pretty locked
into bash are you not?
Post by John Soros
--
Sticky bits on disk.
Regards,
Mike
--
Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20110311/20c8dc9c/attachment.pgp>
Michael H. Warfield
2011-03-11 15:57:19 UTC
Permalink
Post by Michael H. Warfield
Post by Walter Stanish
Post by Brian K. White
Post by Walter Stanish
... 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.
Another reason we may want do to this is a little more obscure. The MAC
address of a Linux bridge is the numerically lowest MAC address of the
attached interfaces. If you are using bridged networking and the
containers have a MAC addresses lower than that of the host, the bridge
will change MAC addresses as the containers are started and stopped.
Since the host interface is a member of that bridge, the host's
effective MAC address to the rest of the network also effectively
changes as containers open and close. This is a bad thing. It can
cause temporary transient network delays and glitching in the ARP cache
on IPv4 and generally raise havok on IPv6. Choosing something arbitrary
with a couple of high order bits set (say C2:xx:xx:xx:xx:xx) helps
insure that the containers have higher addresses than the host interface
and will not cause dynamic changes in the MAC addresses of the bridges.
Post by Michael H. Warfield
Post by Walter Stanish
- 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
------------------------------------------------------------------------------
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
--
Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20110311/0555e0e6/attachment.pgp>
Brian K. White
2011-03-11 22:08:30 UTC
Permalink
Post by Michael H. Warfield
Post by Walter Stanish
Post by Brian K. White
Post by Walter Stanish
... 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
Geordy Korte
2011-04-23 07:25:32 UTC
Permalink
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
Post by Michael H. Warfield
Post by Walter Stanish
Post by Brian K. White
Post by Walter Stanish
... 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
Post by Michael H. Warfield
Post by Walter Stanish
Post by Brian K. White
Post by Walter Stanish
cost $600 for one block. The dev guys might want to setup a pledge
program...
Post by Michael H. Warfield
Post by Walter Stanish
Post by Brian K. White
Post by Walter Stanish
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
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>
Brian K. White
2011-04-24 06:29:29 UTC
Permalink
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
Post by 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
Post by Michael H. Warfield
Post by Walter Stanish
Post by Brian K. White
Post by Walter Stanish
... 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
Post by Michael H. Warfield
Post by Walter Stanish
Post by Brian K. White
Post by Walter Stanish
cost $600 for one block. The dev guys might want to setup a
pledge program...
Post by Michael H. Warfield
Post by Walter Stanish
Post by Brian K. White
Post by Walter Stanish
I will pay for it.
I too am willing to pay the whole thing, so, halvsies? Or see
how many
Post by Michael H. Warfield
Post by Walter Stanish
Post by Brian K. White
others want to split even?
Sounds good. I guess we can nominate you as the finance go-to
on this
Post by Michael H. Warfield
Post by Walter Stanish
one then :)
Let us know details when they emerge.
Can someone explain to me why we can't simply use a block of
addresses
Post by Michael H. Warfield
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
Post by Michael H. Warfield
that bit is set and the 0100 bit (multicast) is clear. By the
standard,
Post by Michael H. Warfield
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
Post by Michael H. Warfield
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
Post by Michael H. Warfield
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
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 <mailto:Lxc-users at lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/lxc-users
--
==============
Geordy Korte
MSN geordy at geordy.nl <mailto:geordy at 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 at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users
John Soros
2011-03-02 17:15:04 UTC
Permalink
Hi again,
I tried creating a bug for this issue so I don't spam the list with all
my changes, but the "Add new" page on sourceforge displays a blank page
for me.
An other minor update, this fixes the fact that the scripts didn't add
the locale to locale.gen, so the locale wasn't generated and thus was
unusable (aptitude among others complains a lot).
Signed-off-by: John Soros <johnny at r0x0r.me>

--
The POP server is out of Coke


On Tue, 1 Mar 2011 18:18:17 +0100
Post by John Soros
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 <johnny at r0x0r.me>
--
the router thinks its a printer.
On Fri, 25 Feb 2011 09:03:55 +0100
Post by Jäkel, Guido
Dear John,
Post by John Soros
- 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
["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 at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lxc-debian.diff
Type: text/x-patch
Size: 3086 bytes
Desc: not available
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20110302/a67211dd/attachment.bin>
Mohit Chawla
2011-04-24 07:37:43 UTC
Permalink
Post by John Soros
I have edited the lxc-debian script found in the lxc package in squeeze
Very tangential to the current thread discussion, but I was wondering if we
could remove the libui-dialog-perl package from the template ( I have
removed it, and haven't noticed any issues so far ), for the simple reason
that we can use a dvd to provision these lxc systems, using the file:/path
convention. The libui-dialog-perl package isn't present on dvd1 under
pool/main.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20110424/b48957db/attachment.html>
John Soros
2011-04-25 12:49:43 UTC
Permalink
Hi,
I'm not sure whether using a DVD is really necessary as all the scripts
cache not only packages but also the rootfs (so you don't need to
extract and configure every package for each new host).
Cheers,
John

--
Second-system effect.


On Sun, 24 Apr 2011 13:07:43 +0530
Post by Mohit Chawla
Post by John Soros
I have edited the lxc-debian script found in the lxc package in squeeze
Very tangential to the current thread discussion, but I was wondering
if we could remove the libui-dialog-perl package from the template
( I have removed it, and haven't noticed any issues so far ), for the
simple reason that we can use a dvd to provision these lxc systems,
using the file:/path convention. The libui-dialog-perl package isn't
present on dvd1 under pool/main.
Continue reading on narkive:
Loading...