You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Introduction

CloudStack currently does not allow an easy way to add new guest OS types, for example, a standard way to add say, CentOS 6.5.

Part of the reason is since the OS to hypervisor-specific platform mappings are currently hard-coded into the code-base

To support such new OS addition, the current way is to manipulate the DB using upgrade scripts and make the necessary code changes.

This proposal aims to partially mitigate this issue by allowing the CloudStack admin the ability to add new OS in the list, and update the mapping to hypervisor-specific platform names, via APIs / UI. For now, the admin will be responsible for providing the mapping to hypervisor-specific platform names based on his knowledge, which may be enhanced in future.

Scope

  1. Should be able to add guest os -> hypervisor emulator platform mapping
  2. Should be able to delete guest os -> hypervisor emulator platform mapping
  3. Should be able to modify guest os -> hypervisor emulator platform mapping

Implementation

At the core, the mappings will be stored in a table in DB.The table guest_os_hypervisor may be reused for this purpose (it is not being used elsewhere)

To accommodate Xen specifics (mappings are version specific in some cases), the hypervisor version will be stored in the table too.

Additionally, a table will be needed to store the available platform emulators for a hypervisor.

The APIs needed are :

  1. List all platform emulators for a hypervisor
    1. hypervisor as parameter
  2. Add new mapping
    1. hypervisor, guest OS name and platform emulator as parameters
  3. Delete existing mapping (some mappings may be marked as non-deletable / editable. This is an open question)
    1. hypervisor, guest OS name as parameter
  4. Modify existing mapping
    1. hypervisor, guest OS name and platform emulator as parameters

The APIs will not allow for duplicate guest OS -> platform emulator mappings for a specific hypervisor.

The APIs above are sufficient to implement a UI on top of this.

The ResourceBase / OsMapper files will load the mappings from DB, via the respective Gurus.

<Additional details and sequence diagram here>

Comments / Suggestions

  • No labels