Nils,
On Oct 18, 2009, at 4:13 AM, Nils Goroll wrote:
Hi Kais and all,
Set the bandwith limit on the vnic of one of the guests to zero.
assuming the guest's automatically created vnic is called xvm1_0:
# dladm set-linkprop -p maxbw=0 xvm1_0
Great idea! I will try this tomorrow. Thank you!
Today is not the 16th of September, so my reply is a month late, but
still this doesn't seem to work for me as I'd expect:
- Little detail: Only setting maxbw to 0 temporarily seems to work:
r...@d0:~# dladm set-linkprop -t -p maxbw=0 xvm4_2
r...@d0:~# dladm show-linkprop xvm4_2
LINK PROPERTY PERM VALUE DEFAULT
POSSIBLE
xvm4_2 autopush -- -- -- --
xvm4_2 zone rw -- -- --
xvm4_2 state r- up up
up,down
xvm4_2 mtu r- 1500 1500 1500
xvm4_2 maxbw rw 0 -- --
xvm4_2 cpus rw -- -- --
xvm4_2 priority rw high high
low,medium,high
xvm4_2 tagmode rw vlanonly vlanonly
normal,vlanonly
r...@d0:~# dladm set-linkprop -p maxbw=0 xvm4_2
dladm: warning: cannot persistently set link property 'maxbw':
object not found
If xvm4_2 is a temporary VNIC created by Xen then it's expected. If
you don't specify -t, dladm will assume you want to set that property
persistently, and you cannot store persistent properties for non-
persistent data-links.
There was an effort to allow the maximum bandwidth to be configured
from the Xen tools themselves, and then apply the corresponding maxbw
property on the VNICs transparently as they are created by Xen. The
bandwidth limit would have been in this case stored persistently in
the Xen configuration itself, and then applied to the temporary VNICs
created by Xen. See http://arc.opensolaris.org/caselog/PSARC/2009/137.
Unfortunately the responsible engineer was redeployed before he had a
chance to finish the work and this has not been picked up by anyone
else.
- Doesn't work as expected
I see that you have sent an another email with an update:
I did get the expected behavior with a series of set-linkprop and
reset-linkprop commands.
So obviously corner-cases exist when the maxbw property isn't
applied strictly.
It would be interesting to know how you can get to that state. If you
can reproduce this let us know.
Nicolas.
In my xvm-based development environment, I am running several
virtualized clusters. When I set maxbw=0 for the cluster
interconnect interfaces to the same etherstub on all nodes, ohac
still reports them as working (iow, probes are successfully
transmitted):
# on dom0
r...@d0:~# dladm show-link| egrep 'up.*cli'
xvm6_3 vnic 1500 up cli1
xvm6_2 vnic 1500 up cli0
xvm7_3 vnic 1500 up cli1
xvm7_2 vnic 1500 up cli0
r...@d0:~# dladm set-linkprop -t -p maxbw=0 xvm6_2
r...@d0:~# dladm set-linkprop -t -p maxbw=0 xvm7_2
r...@d0:~# dladm show-linkprop | egrep '^xvm[67].*maxbw'
xvm6_0 maxbw rw -- -- --
xvm6_3 maxbw rw -- -- --
xvm6_1 maxbw rw -- -- --
xvm7_0 maxbw rw -- -- --
xvm6_2 maxbw rw 0 -- --
xvm7_1 maxbw rw -- -- --
xvm7_3 maxbw rw -- -- --
xvm7_2 maxbw rw 0 -- --
# has no effect on interconnect status of the clusters
pub0-node1:/# clinterconnect status
Cluster Transport Paths ===
Endpoint1 Endpoint2 Status
--------- --------- ------
pub0-node0:xnf3 pub0-node1:xnf3 Path online
pub0-node0:xnf2 pub0-node1:xnf2 Path online
Thank you, Nils
_______________________________________________
networking-discuss mailing list
[email protected]
--
Nicolas Droux - Solaris Kernel Networking - Sun Microsystems, Inc.
[email protected] - http://blogs.sun.com/droux
_______________________________________________
networking-discuss mailing list
[email protected]
