Aside from the laughable idea of “militantly” supporting anything with a blog post, Miguel simply noted that these people exist, have written a book, and will be doing the speaking-tour-thing near him. Does he agree with the contents? (shakes eight-ball) Signs point to Yes.
Is he free to do so? Also yes.
Are you free to ignore him? Still yes.
Does His Chomskiness actually take the challenge and provide a better rebuttal to the underlying book than politely demanding Miguel STFU? Yep.
Oh, and here’s a patch that will let you do something cool with XEN 3.0.3:
--- network-bridge 2007-02-08 09:21:12.000000000 -0600
+++ network-vlans 2007-09-14 09:55:20.000000000 -0500
@@ -26,6 +26,7 @@
# bridge The bridge to use (default xenbr${vifnum}).
# netdev The interface to add to the bridge (default eth${vifnum}).
# antispoof Whether to use iptables to prevent spoofing (default no).
+# vlans VLANs to add on top of the bridge
#
# Internal Vars:
# pdev="p${netdev}"
@@ -64,18 +65,27 @@
bridge=${bridge:-xenbr${vifnum}}
netdev=${netdev:-eth${vifnum}}
antispoof=${antispoof:-no}
+vlans=$(echo $vlans | sed -e 's/,/ /g')
pdev="p${netdev}"
vdev="veth${vifnum}"
vif0="vif0.${vifnum}"
get_ip_info() {
- addr_pfx=`ip addr show dev $1 | egrep '^ *inet' | sed -e 's/ *inet //' -e 's/ .*//'`
+ addr_pfx=`ip addr show dev $1 | sed -n 's/^ *inet (.*) [^ ]*$/1/p'`
gateway=`ip route show dev $1 | fgrep default | sed 's/default via //'`
}
+
+is_bonding() {
+ [ -f "/sys/class/net/$1/bonding/slaves" ]
+}
+
+is_ifup() {
+ ip link show dev $1 | awk '{ exit $3 !~ /[]/ }'
+}
do_ifup() {
- if ! ifup $1 ; then
+ if ! ifup $1 || ! is_ifup $1 ; then
if [ ${addr_pfx} ] ; then
# use the info from get_ip_info()
ip addr flush $1
@@ -206,8 +216,8 @@
mac=`ip link show ${netdev} | grep 'link/ether' | sed -e 's/.*ether (..:..:..:..:..:..).*/1/'`
preiftransfer ${netdev}
transfer_addrs ${netdev} ${vdev}
- if ! ifdown ${netdev}; then
- # If ifdown fails, remember the IP details.
+ if is_bonding ${netdev} || ! ifdown ${netdev}; then
+ # Remember the IP details if necessary.
get_ip_info ${netdev}
ip link set ${netdev} down
ip addr flush ${netdev}
@@ -223,6 +233,18 @@
add_to_bridge ${bridge} ${vif0}
add_to_bridge2 ${bridge} ${pdev}
do_ifup ${netdev}
+
+ if [ -n "$vlans" ]; then
+ vconfig set_name_type VLAN_PLUS_VID_NO_PAD
+
+ for vlan in $vlans; do
+ create_bridge xenbr${vlan}
+
+ vconfig add ${bridge} ${vlan}
+ setup_bridge_port vlan${vlan}
+ add_to_bridge xenbr${vlan} vlan${vlan}
+ done
+ fi
else
# old style without ${vdev}
transfer_addrs ${netdev} ${bridge}
@@ -262,6 +284,20 @@
ip link set ${netdev} name ${vdev}
ip link set ${pdev} name ${netdev}
do_ifup ${netdev}
+
+ if [ -n "$vlans" ]; then
+ for vlan in $vlans; do
+ if [ -n `ip link show vlan${vlan} | grep '${bridge}:'` ]; then
+ ip link delif ${bridge} xenbr${vlan}
+ ip link set ${bridge} down
+
+ ip link set vlan${vlan} down
+ vconfig rem ${bridge} ${vlan}
+ fi
+ done
+
+ vconfig set_name_type DEV_PLUS_VID_NO_PAD
+ fi
else
transfer_routes ${bridge} ${netdev}
ip link set ${bridge} down
It may be buggy, since I haven’t tested it in production. What it does is this: allows you to run an 802.1Q trunk into your XEN server, then put your virtual machines on any VLAN you want with a couple configuration stanzas.
So, your xend-config.sxp will have:
(network-script 'network-vlans netdev=eth0 vlans=8,9,10,11,13,121,14,15')
Which translates to “create bridges for VLAN 8, 9, 11, 13, 121, 14, and 15 with a xenbr prefix”. Then you set your DomU vif stanza to be “bridge=xenbr13” and bam! your DomU exists on the VLAN13. The primary limitation of this is that it keeps your Dom0 on the untagged/native VLAN, which isn’t best practice.
The stack of modules a packet traverses to get to a DomU will look like this (with relevant modules):
[network] --> dom0: peth0 (dev) --> dom0: xenbr0 (bridge) --> dom0: vlan13 (dot1q attached to xenbr0) --> dom0: xenbr13 (bridge) --> dom0: vifX.0 (netloop) --> domU: xen0 (xennet)
James Cape 
Chomsky is talking about the article, and he basically agrees with the premise, but disagrees that only the Lobby is to blame for, that there is plenty of other blame to go around.
I have not read the book in its entirety, but it significantly larger than the article that you can read in a couple of hours.
It’s not great for GNOME, really though, is it?
That you let this fetid, anti-semitic, cretino-leftists, Microsoft-arse-licking lickspittle get away with spewing his passive-aggressive unpleasantness across your free software project blogregator.
It really is about time that Icaza is told that he’s not welcome any more and should STFU.
Miguel:
I’ve not read the book either. I didn’t know there was one, honestly.
Martin:
1. You begin by referring to GNOME in the second person—“you”—but drop the pronouns altogether when demanding Miguel be told (by “us”, I presume) that he’s not welcome anymore. Are you saying you want someone ostricized from a group you’re not a part of?
2. So far as I am aware, Planet GNOME is whatever those who have been involved in GNOME—past and present—want to make it. It’s not a “project” anything, nor has it ever been. If Miguel’s missives on the state of Israel’s behavior in the territories make it on http://www.gnome.org, then you’ve got a complaint…
3. Typically, demands that X be purged from the party take longer than 100 words. Otherwise people’s minds rebel at the abrupt shift. You would do well to remember that in the future, Comrade Coxall.
“The expression “Partisan politics” usually refers to fervent, sometimes militant support of a party, cause, faction, person, or idea.”
Surely that is exactly what we want. People who are passionate about the things they believe. The falecy that everything has to appeal to everyone and not offend or upset anyone is what has made the world a bland place.
And I love the anti-israel == anti-semetic bullshit from Mr Coxall. Still, same thing happens with America. I disagree with people getting tasered for asking the wrong questions, so obviously I just hate america. Makes perfect sense. How can one hate a country anyway?
We already do the same thing without any patching.
Just create all the vlan devices in dom0 (eth0.2, eth0.342, etc.), put them each in a bridge (xenbr2, xenbr342, etc.) and then you can do the exact same. Decide in which VLAN the DomU lives.
Basicly you just comment the (network-script ) thingy out completely and configure all the bridges and stuff in the dom0 system.
That’s true, except that the RHEL 5 network-scripts fall apart when your “eth0” is actually an active/passive 802.3ad “bond0,” and is built on top of several ethernet devices.
In that case, your options are to either fix the RHEL 5 scripts, or write a custom script to bring up all your interfaces in the proper order. Using the “network-vlans” patch above, you simply configure your bond0 (which does work with the RHEL 5 scripts), and then just let XEN do it’s thing on top of that.
Update: Let me rephrase the first paragraph: RHEL 5’s network scripts fall apart when you try to do a bridge on top of a dot1q on top of a bonding device on top of the real NICs, and make it come up on boot. In which case you’re going to be scripting the startup anyways, so why not just do a regular bonded device and then let XEN’s network scripts do all the interface renaming and bridging craziness.
In more recent RedHat updates, this patch spits out errors, apparently it seems because some of the changes were already incorporated.
*** network-bridge 2007-10-12 14:44:44.000000000 -0400
--- network-vlans 2007-10-22 13:06:20.000000000 -0400
***************
*** 27,32 ****
--- 27,33 ----
# bridge The bridge to use (default xenbr${vifnum}).
# netdev The interface to add to the bridge (default eth${vifnum}).
# antispoof Whether to use iptables to prevent spoofing (default no).
+ # vlans VLANs to add on top of the bridge
#
# Internal Vars:
# pdev="p${netdev}"
***************
*** 65,70 ****
--- 66,72 ----
bridge=${bridge:-xenbr${vifnum}}
netdev=${netdev:-eth${vifnum}}
antispoof=${antispoof:-no}
+ vlans=$(echo $vlans | sed -e 's/,/ /g')
pdev="p${netdev}"
vdev="veth${vifnum}"
***************
*** 232,237 ****
--- 234,251 ----
add_to_bridge ${bridge} ${vif0}
add_to_bridge2 ${bridge} ${pdev}
do_ifup ${netdev}
+
+ if [ -n "$vlans"] ]; then
+ vconfig set_name_type VLAN_PLUS_VID_NO_PAD
+
+ for vlan in $vlans; do
+ create_bridge xenbr${vlan}
+
+ vconfig add ${bridge} ${vlan}
+ setup_bridge_port vlan${vlan}
+ add_to_bridge xenbr${vlan} vlan${vlan}
+ done
+ fi
else
# old style without ${vdev}
transfer_addrs ${netdev} ${bridge}
***************
*** 271,276 ****
--- 285,304 ----
ip link set ${netdev} name ${vdev}
ip link set ${pdev} name ${netdev}
do_ifup ${netdev}
+
+ if [ -n "$vlans"] ]; then
+ for vlan in $vlans; do
+ if [ -n `ip link show vlan${vlan} | grep '${bridge}:'` ]; then
+ ip link delif ${bridge} xenbr${vlan}
+ ip link set ${bridge} down
+
+ ip link set vlan${vlan} down
+ vconfig rem ${bridge} ${vlan}
+ fi
+ done
+
+ vconfig set_name_type DEV_PLUS_VID_NO_PAD
+ fi
else
transfer_routes ${bridge} ${netdev}
ip link set ${bridge} down
Also, you don’t HAVE to leave dom0 on the native vlan. I’ve found that running the new xen script with something like:
network-vlans vlans=7,10 vifnum=0 netdev=bond0 start
worked just fine, my local bond0.7 or bond0.10 interfaces that were created with RedHat startups still functioned. However, it killed the local routing table, necessitating re-doing that.
Pardon the formatting.. apparently I dropped a character somewhere….