Guest Agent for XenServer hypervisor

Registered by Jesse Andrews on 2010-09-03

The feature will allow communication with a guest agent from compute node controller. This allows cloud controller APIs to be added for user controlled password reset, settings ips, ... - allowing windows support.

Blueprint information

Status:
Complete
Approver:
Rick Clark
Priority:
Undefined
Drafter:
Anso Labs
Direction:
Needs approval
Assignee:
Chris Behrens
Definition:
Approved
Series goal:
None
Implementation:
Implemented
Milestone target:
None
Started by
Rick Clark on 2010-11-16
Completed by
Vish Ishaya on 2011-05-06

Related branches

Sprints

Whiteboard

Marking this complete, as it works properly for xen. Will file separate blueprints for more robust guest agent support for all hypervisors. --vish

I'm not sure when we can consider this "complete" so I'm not putting a milestone target on this one. We may need to divide this into smaller blueprints that we can target effectively --vish

The long term goal will be to have an hypervisor agnostic guest agent to use to (re)configure guest settings (such as root password, networking config, etc). But we first need to worry about this working under XenServer via XenStore communication. We also need to make sure the agent is easily extendable and maintainable going forward.

The original Rackspace agent is here: https://launchpad.net/agent-smith

The Openstack guest agent code is here: https://launchpad.net/openstack-guest-agents
The latter contains both the Unix code base (Linux + FreeBSD) as well as the Windows code base.

Most of the real work is currently done via bash scripts, as it is thought to be a mistake to assume Python is available in the guest. But due to being limited to bash, sed, awk, etc, the scripts are very messy and somewhat difficult to maintain.

To move towards a hypervisor agnostic agent and to make the current agent more maintainable, my thoughts are to convert the current C portion into something small that links the python interpreter and just implements a basic infrastructure for loading various host<->guest communication modules with a callout to a worker script/function. We should be able to have a self contained process (no forking) to do most of the work if we can embed Python into this binary. Being able to write the real work in Python should result in a lot more readable code compared to bash/sed/awk.

The first communication module will be for XenStore communication.

Tasks:

1) Build support into the C agent to link the C python library and be able to load python modules.
2) Build a module API for pluggable communication modules and worker modules.
3) Convert the xen.c code into a XenStore communication plugin module
4) Create a simple worker python module that advertises all of the current commands and callbacks for them, but underneath just calls the current bash scripts
5) Work one by one to convert bash scripts into python modules.

(?)

Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.