| DS | Defines a Data Source Field. |
| DS-Name | The name of this Data Source. |
| DST | Defines the Data Source Type. Can be GAUGE, COUNTER, DERIVE or ABSOLUTE. |
| HeartBeat | Defines the minimum heartbeat, the maximum number of seconds that can go by before a DS value is considered unknown. |
| Min | The minimum acceptable value. Values less than this number are considered unknown. This is optional. |
| Max | The maximum acceptable value. Values exceeding this number are considered unknown. This is optional. |
RRA:CF:xff:steps:rows
![[Note]](https://lh3.googleusercontent.com/blogger_img_proxy/AEn0k_uim1XHOm3BFEmjWQckDuYeIOd1XLpxyPgicxmPjzvt4LWAERyU1fJSd2Ef_MmOwiM3WwX4PjcxwgrOwPa7XCYrNaw0Hf_wDZoeHSJzFq1A-C8k7NDDR4bHmJ81yAC5mj8neJJiDVYRFhIRKvr8qYwspTM1q7VPQA=s0-d) | Note |
|---|---|
Please note, that you need to use an extra option
--block-migrate for the live migration command, in order to use block migration. |
| Note |
|---|---|
Please note, that block migration works only with EXT local storage SRs, and the server should not have any volumes attached.
|
| Type: | enum vdi_type | ||||||||||||
| |||||||||||||
| Name: | type | ||||||||||||
| type of the VDI |
Open vSwitch Boot Sequence on XenServer
---------------------------------------
When Open vSwitch is installed on XenServer, its startup script
/etc/init.d/openvswitch runs early in boot. It does roughly the
following:
* Loads the OVS kernel module, openvswitch.
* Starts ovsdb-server, the OVS configuration database.
* XenServer expects there to be no bridges configured at
startup, but the OVS configuration database likely still has
bridges configured from before reboot. To match XenServer
expectations, the startup script deletes all configured
bridges from the database.
* Starts ovs-vswitchd, the OVS switching daemon.
At this point in the boot process, then, there are no Open vSwitch
bridges, even though all of the Open vSwitch daemons are running.
Later on in boot, /etc/init.d/management-interface (part of XenServer,
not Open vSwitch) creates the bridge for the XAPI management interface
by invoking /opt/xensource/libexec/interface-reconfigure. Normally
this program consults XAPI's database to obtain information about how
to configure the bridge, but XAPI is not running yet[*] so it instead
consults /var/xapi/network.dbcache, which is a cached copy of the most
recent network configuration.
[*] Even if XAPI were running, if this XenServer node is a pool slave
then the query would have to consult the master, which requires
network access, which begs the question of how to configure the
management interface.
XAPI starts later on in the boot process. XAPI can then create other
bridges on demand using /opt/xensource/libexec/interface-reconfigure.
Now that XAPI is running, that program consults XAPI directly instead
of reading the cache.
As part of its own startup, XAPI invokes the Open vSwitch XAPI plugin
script /etc/xapi.d/openvswitch-cfg-update passing the "update"
command. The plugin script does roughly the following:
* Calls /opt/xensource/libexec/interface-reconfigure with the
"rewrite" command, to ensure that the network cache is
up-to-date.
* Queries the Open vSwitch manager setting (named
"vswitch_controller") from the XAPI database for the
XenServer pool.
* If XAPI and OVS are configured for different managers, or if
OVS is configured for a manager but XAPI is not, runs
"ovs-vsctl emer-reset" to bring the Open vSwitch
configuration to a known state. One effect of emer-reset is
to deconfigure any manager from the OVS database.
* If XAPI is configured for a manager, configures the OVS
manager to match with "ovs-vsctl set-manager".
Notes
-----
* The Open vSwitch boot sequence only configures an OVS configuration
database manager. There is no way to directly configure an OpenFlow
controller on XenServer and, as a consequence of the step above that
deletes all of the bridges at boot time, controller configuration only
persists until XenServer reboot. The configuration database manager
can, however, configure controllers for bridges. See the BUGS section
of ovs-controller(8) for more information on this topic.
* The Open vSwitch startup script automatically adds a firewall rule
to allow GRE traffic. This rule is needed for the XenServer feature
called "Cross-Host Internal Networks" (CHIN) that uses GRE. If a user
configures tunnels other than GRE (ex: VXLAN, LISP), they will have
to either manually add a iptables firewall rule to allow the tunnel traffic
or add it through a startup script (Please refer to the "enable-protocol"
command in the ovs-ctl(8) manpage).
http://openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=blob_plain;f=INSTALL.XenServer;hb=HEAD
cat /etc/xensource/network.conf
xe-switch-network-backend bridge
xe-switch-network-backend openvswitch
/boot/guest symlink/directory in Dom0. For detailed instructions, see next section./images is properly set up. See next section for more details.srtype="ext" within the installation tag of the answer file./boot/guest symlink/directory in Dom0./boot/guest needs to be created inside Dom0. The OpenStack VM will put the kernel and ramdisk extracted from the AKI and ARI images to this location.# LOCAL_SR=$(xe sr-list name-label="Local storage" --minimal) # LOCALPATH="/var/run/sr-mount/$LOCAL_SR/os-guest-kernels" # mkdir -p "$LOCALPATH" # ln -s "$LOCALPATH" /boot/guest
