Revision 4ab6784a
b/doc/design-openvswitch.rst | ||
---|---|---|
21 | 21 |
|
22 | 22 |
Proposed changes |
23 | 23 |
---------------- |
24 |
1. Implement functions into gnt-network to manage Open vSwitch through Ganeti gnt-network
|
|
25 |
should be able to create, modify and delete vSwitches. The resulting configuration shall
|
|
26 |
automatically be done on all members of the node group. Connecting Ethernet devices to
|
|
27 |
vSwitches should be managed through this interface as well. |
|
24 |
1. Implement functions into gnt-cluster and gnt-node to manage Open vSwitch through Ganeti.
|
|
25 |
It should be possible to create, modify and delete vSwitches. The resulting configuration
|
|
26 |
shall automatically be done on all members of the node group, if possible. Connecting Ethernet
|
|
27 |
devices to vSwitches should be managed through this interface as well.
|
|
28 | 28 |
|
29 | 29 |
2. Implement VLAN-capabilities: Instances shall have additional information for every NIC: VLAN-ID |
30 | 30 |
and port type. These are used to determine their type of connection to Open vSwitch. This will |
... | ... | |
39 | 39 |
bandwidth and maximum burst. This helps to balance the bandwidth needs between the VMs and to |
40 | 40 |
ensure fair sharing of the bandwidth. |
41 | 41 |
|
42 |
Automatic configuration of OpenvSwitches |
|
43 |
++++++++++++++++++++++++++++++++++++++++ |
|
44 |
Ideally, the OpenvSwitch configuration should be done automatically. |
|
45 |
|
|
46 |
This needs to be done on node level, since each node can be individual and a setting on cluster / node group |
|
47 |
level would be too global is thus not wanted. |
|
48 |
|
|
49 |
The task that each node needs to do is: |
|
50 |
``ovs-vsctl addbr <switchname>`` with <switchname> defaulting to constants.DEFAULT_OVS |
|
51 |
``ovs-vsctl add-port <switchname> <ethernet device>`` optional: connection to the outside |
|
52 |
|
|
53 |
This will give us 2 parameters, that are needed for the OpenvSwitch Setup: |
|
54 |
switchname: Which will default to constants.DEFAULT_OVS when not given |
|
55 |
ethernet device: Which will default to None when not given, might be more than one (NIC bonding) |
|
56 |
|
|
57 |
These parameters should be set at node level for individuality, _but_ can have defined defaults on cluster |
|
58 |
and node group level, which can be inherited and thus allow a cluster or node group wide configuration. |
|
59 |
If a node is setup without parameters, it should use the settings from the parent node group or cluster. If none |
|
60 |
are given there, defaults should be used. |
|
61 |
|
|
62 |
As a first step, this will be implemented for using 1 ethernet device only. Functions for nic bonding will be added |
|
63 |
later on. |
|
64 |
|
|
42 | 65 |
Configuration changes for VLANs |
43 | 66 |
+++++++++++++++++++++++++++++++ |
44 | 67 |
nicparams shall be extended by a value "vlan" that will store the VLAN information for each NIC. |
... | ... | |
71 | 94 |
gnt-instance modify shall be able to add or remove single VLANs from the vlan string without users needing |
72 | 95 |
to specify the complete new string. |
73 | 96 |
|
97 |
NIC bonding |
|
98 |
+++++++++++ |
|
99 |
To be done |
|
100 |
|
|
74 | 101 |
Configuration changes for QoS |
75 | 102 |
+++++++++++++++++++++++++++++ |
76 | 103 |
Instances shall be extended with configuration options for |
Also available in: Unified diff