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.
Category:XAPI Devel
Category:Design Document