Guest Agent for XenServer hypervisor
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
- Completed by
- Vish Ishaya
Related branches
Related bugs
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:/
The Openstack guest agent code is here: https:/
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.
