I have resolved this issue by running the following command and adding it to /boot/config/go above the emhttp line:

 

# Set Xen Bridge Delay to 2 seconds

/usr/sbin/brctl setfd br0 2

 

You can also run this command at any time but your VMs must be shut off first.

 

Now your VMs which utilize DHCP will get an immediate IP address.

oh wow!, this is so topical for me as i have just been fighting issues with sabnzbd in a vm due to this exact issue, the delay was causing issues with nfs shares accessed in sabnzbd using autofs, i wonder if tom is aware of this simple fix/workaround?.

 

thanks for sharing needo!.

I have resolved this issue by running the following command and adding it to /boot/config/go above the emhttp line:

 

# Set Xen Bridge Delay to 2 seconds

/usr/sbin/brctl setfd br0 2

 

You can also run this command at any time but your VMs must be shut off first.

 

Now your VMs which utilize DHCP will get an immediate IP address.

 

You are the man!  I will best testing this out later today myself.  Been having the same issue.

 

I've heard others indicate that they even had delays with dom0 getting an IP.  Does this fix that as well, or did you not have that issue?

You are the man!  I will best testing this out later today myself.  Been having the same issue.

 

I've heard others indicate that they even had delays with dom0 getting an IP.  Does this fix that as well, or did you not have that issue?

 

I am glad people are finding this so helpful!

 

I did see the issue and it fixed it as well.

You guys please try this instead.  In your 'config/network.cfg' file, add this line:

 

BRSTP="no"

 

This will turn off spanning tree protocol.  Note however if you have multiple physical NIC's in your server, and you have bridging enabled, but not also bonding enabled, please only connect one physical Ethernet cable to your server.

I will give it a try tom and let you know, in assuming the fix supplied by needo has the same multi nic limitation?

I will give it a try tom and let you know, in assuming the fix supplied by needo has the same multi nic limitation?

No that 'fix' is changing a timer delay associated with "Spanning Tree Protocol".  Here is some "light reading"  from Cisco on the subject:

http://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/19120-122.html

 

If STP is not enabled, then I don't think there should be any delay and is probably the "proper" fix.  In some Xen networking guides you see they disabled STP on the bridge, eg:

http://grml.org/xen/

In researching the subject you will find most Xen configs explicitly turn off STP on the bridge.

 

That said, if any of the VM's setup internal bridges I think there's trouble (though can't see why any would do that).

 

Also if you have multiple NIC's and you really are bridging them, then you probably do want STP enabled, but in that case you probably also care about the forwarding delay.

 

Since I think the most common use of multiple NIC's is to bond them together, then put the bridge on top of that, you don't need STP enabled on the bridge.

 

Slightly OT, but I presume that it is possible to enable two physical network interfaces, and not bond them or bridge them, but assign one to Dom0 and the other to one, or more, of the VMs?

 

Or would that force all traffic between the various domains to go out on to the physical network?

ahhh right tom, i didnt know exactly what needo's command did, didnt realise it was just messing with STP, i am VERY aware of STP as i have seen it cause havoc on many corporate networks due to badly configured  layer 3 switches and/or incompatibility between manufacturers of equipment.

 

To me your assumption that most people will be using multi homed systems as a bonded virtual nic makes sense, so maybe it's worth having STP disabled by default in the next beta?, maybe with the option to enable it in the webui for people who do want to bridge multiple nic's.

 

in any case i will get back to you asap and let you know the result of passing that flag on my system.

 

edit confirmed working tom when using flag in network.cfg, im getting zero delay in the vm, it picks up dhcp lease straight away, good stuff!.

 

edit confirmed working tom when using flag in network.cfg, im getting zero delay in the vm, it picks up dhcp lease straight away, good stuff!.

Working for me also

Slightly OT, but I presume that it is possible to enable two physical network interfaces, and not bond them or bridge them, but assign one to Dom0 and the other to one, or more, of the VMs?

 

Or would that force all traffic between the various domains to go out on to the physical network?

 

Maybe this would work via PCI passthru of one of the NIC's?  I haven't tried this yet.

ahhh right tom, i didnt know exactly what needo's command did, didnt realise it was just messing with STP, i am VERY aware of STP as i have seen it cause havoc on many corporate networks due to badly configured  layer 3 switches and/or incompatibility between manufacturers of equipment.

"havoc" is an understatement 

 

To me your assumption that most people will be using multi homed systems as a bonded virtual nic makes sense, so maybe it's worth having STP disabled by default in the next beta?, maybe with the option to enable it in the webui for people who do want to bridge multiple nic's.

The reason it's enabled by default is because during testing I had both ports of a server connected to the same switch (a bonding setup) and then I disabled 'bonding' and enabled 'bridging' - well this caused "havoc" with our network - that is to say the entire network was brought down immediately because of an arp broadcast storm.  Our junky switch doesn't support STP, having it enabled wouldn't have helped this particular case, but  it occurred to me that it might help a customer or two who inadvertently gets into the same situation.

 

For -beta5 we've added ability to configure STP "yes" or "no" on Network Settings page and written some help text that explains the risk of turning it off in certain configurations.  When one goes to this page to set up a "normal" Xen networking config, they would rename the bridge from "br0" to "xenbr0" and change Enable STP to "no".

 

I set this switch yesterday

 

BRSTP="no"

 

then rebooted.  I've had a whole day of almost completely unresponsive network access, losing access to shared drives, programs hanging for LONG periods of time, and lots of general unpleasantness since.  I'm not sure if it's related to adding this to the cfg file, but I've just removed it from the cfg and am currently trying to reboot.  The system is currently hung with this along the bottom of the GUI page...

 

Stop AVAHI...Stop NFS...Stop SMB...Spinning up all drives...Sync filesystems...

 

it's been that way for quite some time now.

 

shutdown -r now from putty doesn't shut it down either.  I'm afraid I'm going to have to pull the plug to reboot

 

FYI, I am using both NIC's on my motherboard, and have another Intel card installed on the board, but not connected to ethernet.  I have a XEN VM running also, if that matters.

JustinChase, i think reading tom's comments that if you have multiple nic's connected and you do NOT have them bonded together then you must NOT disable STP, otherwise you get an ARP  broadcast storm, quote from tom:-

 

I had both ports of a server connected to the same switch (a bonding setup) and then I disabled 'bonding' and enabled 'bridging' - well this caused "havoc" with our network - that is to say the entire network was brought down immediately because of an arp broadcast storm.

 

so in your case if you want to remove the delay you either disable one of the nic's OR set the nic's to bonded and set the bridge on the bonded adapter.

Thanks.  I'll bond the NIC's, but which bonding setting would you suggest?  I'm looking for fastest response from unRAID on wifi connected machines.

 

Also, how do I "set the bridge on the bonded adapter"?  I sort of assume this is the default, and I don't need to do anything special here, but want to be sure.

 

Also, as an FYI, I did end up hard-booting the machine after removing the line mentioned.  Obviously unRAID started a parity check upon reboot, which made accessing any of the shares nearly impossibly slow.  I stopped the parity check, and things improved.  Should a parity check make user share access so terrible?

hi justinchase, replies as follows:-

 

I'll bond the NIC's, but which bonding setting would you suggest?

Also, how do I "set the bridge on the bonded adapter"?

 

im afraid im not actually using bonding as i use only a single nic, you might be able to find something on the unraid wiki regards this though.

 

I'm looking for fastest response from unRAID on wifi connected machines.

 

to be honest having bonded nic's is not going to improve responsiveness for machines connecting via wifi at all, wifi is incredibly slow in comparison to a wired connection, your wireless speeds are going to be around the 50Mb/s speeds at very best, whereas a wired gigabit connection is around 800-850 Mb/s, so your never going to max out a single nic, never mind 2 nic's bonded.

 

one thing you can do to improve wifi speeds is to channel bond, this is very different to bonding wired nic's together and is typically done on the router/access point, i hope this helps?.

 

edit - take a look here for more info regards channel bonding http://compnetworking.about.com/od/wireless/f/80211n-300-mbps.htm

 

Should a parity check make user share access so terrible?

 

a parity check will indeed slow things down, but it should still be "reasonable", i can still stream 1080p movies across a wired connection with no issues whilst a parity check is in progress, it does of course matter on what spec of hardware you have, if you have slow drives and a slow processor then you may well get some lengthy delays navigating shares until the parity check is complete. i would highly recommend performing a parity check WITH automatic correction as soon as possible, cancelling this process is not recommended.

Thanks for the help, again.

 

I'm basically using bonding because I can.  I'm not sure which choice is best, but xor sounds the most useful, even if not actually useful in my case.  it, at least, provides redundancy, which probably won't hurt.

 

I actually have channel bonding setup on my router, so I should be good there.

 

I think much of my problems were related to having many/most of my drives completely full, so even renaming files would either take forever, or fail, due to not having any space on the drive, even though I had over 4TB available on the array, due to new discs being added.  I (wrongly) assumed unRAID would automatically use the available space if necessary, but instead, it was trying to keep files on the same disc they currently reside on, which was causing much/all of my problems.

 

I've spent the last day or so moving files from full discs to the new discs, and haven't had any weird issues since I made space available on all drives.

 

I suspect my drives are not great, since even using Midnight Commander to move from one disc to another, I'm still only getting about 35MB/s max average speeds.  I really thought SATA3 drives would do much better, but I guess not.

 

Oh well, such is life.

 

Now, I have to fix all my SAB & SB permissions issues, which has been a very unpleasant experience so far.

Thanks for the help, again.

 

I'm basically using bonding because I can.  I'm not sure which choice is best, but xor sounds the most useful, even if not actually useful in my case.  it, at least, provides redundancy, which probably won't hurt.

 

I actually have channel bonding setup on my router, so I should be good there.

 

I think much of my problems were related to having many/most of my drives completely full, so even renaming files would either take forever, or fail, due to not having any space on the drive, even though I had over 4TB available on the array, due to new discs being added.  I (wrongly) assumed unRAID would automatically use the available space if necessary, but instead, it was trying to keep files on the same disc they currently reside on, which was causing much/all of my problems.

 

I've spent the last day or so moving files from full discs to the new discs, and haven't had any weird issues since I made space available on all drives.

 

I suspect my drives are not great, since even using Midnight Commander to move from one disc to another, I'm still only getting about 35MB/s max average speeds.  I really thought SATA3 drives would do much better, but I guess not.

 

Oh well, such is life.

 

Now, I have to fix all my SAB & SB permissions issues, which has been a very unpleasant experience so far.

 

Justin, is your sig up to date?

 

Also, depending on how you have your drives setup, as well as the split levels might cause you issues when you add another drive.

 

Also (its too late now, but for next time), if you are adding BIGGER drives, you could always pull a smaller drive, add the bigger drive, let the array build back onto the bigger drive, then preclear the smaller drive and add it back in when its all done. This is letting your replace a drive (almost as if it were bad) with a larger one, and as soon as its done rebuilding you have plenty more space (assuming you did something like go from a 2TB to a 4TB).

 

Are those sata3 hdds hooked up to a sata3 controller? if not, they will fall back to sata2/1 speeds as needed. Dunno what MB you are running right now, not sure if your sig is up to date.

sorry for the delay in responding.  No, my signature was not up to date, but now it is.

 

I finally got at least 100GB moved off of all my full drives, and have not had any more of these weird issues, so I consider my situation resolved now.

 

Good idea on pulling a drive to replace with a bigger one then pre-clearing the old drive to add back.  I may try that next time.

 

I finally got (most) of my SAB and SB issues resolved, and am just finishing up on the installation (updating actually) of a Windows 7 VM.

 

Next is to figure out PCI passthru

 

Thanks.

Just a fair warning to anyone reading this thread.

 

Bonding is not something that should really be done if it isn't needed.  If you aren't fully saturating your gig network then don't waste your time and money on a bonding setup.

 

If you are interested in setting up bonding anyways then you should really buy a switch that supports it and configure it both in unraid and on the switch.

 

There are many professional? server administrators who can't properly setup bonding or really understand all of the terminology around it.

 

I might just plug a second cable into my server since I know STP is enabled by default now.  A little bit of redundancy is always appreciated.