On 14/09/15 07:19 AM, Dejan Muhamedagic wrote: > Hi Digimer, > > On Fri, Sep 04, 2015 at 03:36:09AM -0400, Digimer wrote: >> Hi all, >> >> I hit an issue a little while ago where live-migrating a VM (on the >> same management network normally used for corosync and a few other >> monitoring tasks) ate up all the bandwidth, causing corosync to declare >> a failure and triggering a fence. >> >> I've dealt with this, in part, by adding redundant ring support on a >> different network. However, I'd like to also limit the migration >> bandwidth so that I don't need to fail over the ring in the first place. > > As you certainly know, heavy traffic networks are not well suited > for the latency sensitive cluster communication. Best to have the > two separated.
Oh for sure, but I've already hit 6 NICs per node (back-channel, normally just corosync, storage dedicated to DRBD and internet-facing dedicated to the user app). Adding two more NICs just for live migration, which happens very rarely, is hard to justify, despite this issue. If I can't reliably solve it with this (and/or tc and/or rrp...) then I will revisit this option. >> Is it reasonable/feasible to add 'virsh migrate-setspeed' support to >> the vm.sh RA? Something like; 'setspeed="75MiB"'? > > Yes, sounds like a good idea. Care to open an issue in github? > > Thanks, > > Dejan Done. https://github.com/ClusterLabs/resource-agents/issues/679 -- Digimer Papers and Projects: https://alteeve.ca/w/ What if the cure for cancer is trapped in the mind of a person without access to education? _______________________________________________ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org