XAPI Startup

Note: this is out-of-date. To understand the Xapi startup, the code is the authoritative source: https://github.com/xapi-project/xen-api/blob/a232a3db5e51bf21eed2680386e4de79dcf4c70e/ocaml/xapi/xapi.ml#L690

The source code controlling the xapi startup procedure is contained within api.hg/ocaml/xapi/xapi.ml. The majority of the startup code is contained within the server_init function.

In the following sequence of steps, (both) denotes that the step is executed on both a pool master and a pool slave; (master) denotes that the step is only executed on a pool master; and (slave) denotes only on a slave.

Where function names are specified, no module name implies that the function is in the Xapi module.

(both) Parse command-line arguments

See init_args.

(both) Read config file

See Helpers.read_config.

(both) Initing stunnel path

See Stunnel.init_stunnel_path.

(both) Read log configuration file

See Helpers.read_log_config.

(both) Print "server starting" message

See print_server_starting_message.

(both) Parse inventory file

See Xapi_inventory.read_inventory.

(both) Initialise local database

See init_local_database.

(both) Read pool secret

See Helpers.get_pool_secret.

(both) Initialise licensing

See License.initialise.

(both) Output xapi version info to the log

See show_config.

(both) Check control domain

See check_control_domain. We check whether the UUID of dom0 is the same as that in the inventory.

(both) Set signal handlers

See signals_handling.

(both) Set up xenstore keys

See xenstore_setup.

(both) Initialise random number generator

See random_setup.

(both) Run startup check

See startup_check. Check that xenstored, xenconsoled and blktapctrl processes are running.

(both) Register http handlers

See register_http_handlers.

(both) Register RPC callbacks

See register_rpc_callbacks.

(both) Start listening on the Unix domain socket used for RPC.

See listen_unix_socket.

(both) Start listening on the localhost Internet socket used for RPC.

See listen_localhost.

(both) Start HA if configured

See start_ha.

(both) Setup DB configuration

See setup_db_conf. Read from /etc/xensource/db.conf. Create a lock for each database connection. Set the database mode to indicate whether this is a master or a slave.

(master) Start up database engine

See start_database_engine. Create a new file if one does not already exist for each database connection (see Db_connections.maybe_create_new_db). Populate the in-memory cache from the connection containing the most recent generation of database (see Db_cache.DBCache.initialise_db_cache). Perform a garbage collection on the database in which records which are unreferenced are removed (see Db_gc.single_pass). Set all hosts to disabled, then signal the HA monitor thread that it can look at the database (see Xapi_ha.on_database_engine_ready).

(both) Bring up the management interface

See bring_up_management_if.

(both) Register SR plugins

See Sm.register.

(both) Start periodic scheduler

See Xapi_periodic_scheduler.loop. Starts a new thread which watches a queue of functions to execute at some time in the future. (See "Register periodic functions" below.)

(slave) Log into the master (say hello to pool)

Keep trying attempt_pool_hello until successful.

(slave) Update in-memory cache

See Db_cache.DBCache.initialise_db_cache. Populate the in-memory cache, potentially from a newer version of the database from the master.

(both) Perform house-keeping on the internal database

See Dbsync.setup. This invokes Dbsync_slave.update_env on all hosts and Dbsync_master.update_env on the master. This largely involves updating the database to reflect current state and synchronising the configurations between hosts across a pool.

Executed on all hosts, Dbsync_slave.update_env does the following:

• Create a localhost record if doesn't already exist
• Record the hostname information in Xapi_globs.localhost_ref
• Load the host RRD
• Refresh host info fields (software version, etc)
• Record host free memory in database
• Copy license to database
• Create host CPU record
• Create domain 0 records
• Resynchronise host crashdumps
• Update VMs' states
• Remove any leaked dom0 block-attached VBDs
• Resynchronise bonded and VLAN PIF records with pool master
• Resynchronise PIF.currently_attached
• Check patch status (see Xapi_pool_patch.update_db)

In addition, Dbsync_master.update_env does the following

• Create root user
• Create pool record
• Set the master's IP in the database
• Refresh the console URLs in the database
• Reset all Halted VMs to a known good state
• Cancel running tasks
• Update the SM plugin table
• Recreate any missing VLAN records
• Create missing Host_metrics objects for all hosts in the pool
• Create a PBD and SR for the Tools ISO.

(master) Start database garbage collection thread

Start a thread to periodically garbage collect records with hanging references in the database.

(both) Check that current license is okay for pooling configuration

Raise a system alert if the license does not support pooling and yet there exist slaves in the database (or this is a slave).

(both) Set memory target for control domain

See set_domain0_memory_target. Set the dom0 memory target in engp:XenStore.

(both) Start message e-mailing thread

See Xapi_message.start_message_hook_thread. Starts a thread which executes /opt/xensource/libexec/mail-alarm for sending messages.

(both) Start heartbeat thread

See Db_gc.start_heartbeat_thread. Start heartbeat thread which periodically "tickles" the heartbeat.

(both) Synchronise HA state

See resynchronise_ha_state. If HA has been disabled on the pool while this host was offline but HA was previously enabled on it, then disable it locally. Alternatively, if HA has been enabled on the pool but this host is the master and has it disabled, then disable HA on the pool. If HA is enabled in the pool and this host is a slave and has it disabled, this is an inconsistent state, so switch to emergency mode.

(master) Start pool database backup thread

See Pool_db_backup.pool_db_backup_thread. Starts a thread to periodically flush the database to the slaves.

(master) Register database change notifier

See Xapi_event.register_hooks. Register Xapi_event.event_add as a callback for database events.

(both) Start monitoring thread

See Monitor.loop. On a new thread, periodically executes Monitor.do_monitor. This spits out database usage and CPU load information to the log (see Monitor_self.go), and updates the RRDs (see Monitor_rrds.update_rrds).

(both) Start database calls monitoring thread

See Monitor_dbcalls.monitor_dbcall_thread.

(both) Start guest liveness monitoring thread

See Xapi_guest_agent.guest_metrics_liveness_thread. Starts a thread which monitors the liveness of guests.

(both) (Placeholder for touching a "ready" file)

Currently does nothing, but can cause a file to be touched if set in Xapi_globs.ready_file.

(master) Check that there are no other masters in the pool

See check_no_other_masters. Check that there are no other masters in the pool by asking them all what they think they are. If any other thinks that they are a master, then this host reverts to being a slave, and restarts.

(both) Register periodic functions

See Xapi_periodic_scheduler.register. Adds functions to the periodic event scheduler to flush files to disk; rotate log files; garbage collect network bridges; show that the periodic event scheduler is still running; and backup RRDs.

(both) Execute startup scripts

See startup_script. Executes /opt/xensource/libexec/xapi-startup-script.

(master) Execute scripts in the "master-scripts" directory with param "start"

See Xapi_pool_transition.run_external_scripts. Invoke each script in /etc/xensource/master.d/ with the parameter start.

(slave) Execute scripts in the "master-scripts" directory with param "stop"

See Xapi_pool_transition.run_external_scripts. Invoke each script in /etc/xensource/master.d/ with the parameter stop.

(master) Create networks

See Create_networks.create_networks_localhost. Creates a guest installer network, on which guests have a private, local IP address.

(both) Bring up physical NICs

See Xapi_pif.start_of_day_best_effort_bring_up. Try to bring up physical PIFs (by calling Xapi_pif.plug for each), in a best-effort fashion.

Xapi_pif.plug calls Xapi_network.attach which instantiate the network (i.e. bridge) associated with the PIF. This is achieved via Nm.bring_pif_up which calls the interface-reconfigure script with the "up" command unless the PIF is marked with currently_attached as true.

(both) Initialise storage

See Create_storage.create_storage_localhost. Creates PBDs for shared SRs.

(both) Start events thread

See Events.listen_xal.

(master) Start SR scanning thread

See Xapi_sr.scanning_thread. Start a thread to scan SRs.

(master) Check / create templates

See Create_templates.create_all_templates.

(both) (Placeholder for touching an "initialisation complete" file)

Currently does nothing, but can cause a file to be touched if set in Xapi_globs.init_complete.

(both) Establish version of tools VDI

See Xapi_pv_driver_version.get_latest_tools_vsn. Sets Xapi_globs.tools_version to the version of the currently-inserted XS tools ISO.

(slave) Fetch database backup from master

See Pool_db_backup.fetch_database_backup. Fetch the database from the master and flush it to each database connection.

(both) Plug unplugged PBDs

See plug_unplugged_pdbs. Calls Create_storage.plug_unplugged_pbds.

(master) Consider sending a master transition alert

If this node has just become a master then raise a system alert to spread this news.