cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amogh Vasekar <>
Subject Re: [PROPOSAL] Ability to add new guest OS
Date Wed, 05 Mar 2014 06:34:02 GMT
Responses inline.


On 3/4/14 12:00 AM, "Daan Hoogland" <> wrote:

>+1 for the feature,
>Did you consider systemvms? Or the default vm-template? Or are those
>marked as undeletable or even hardcoded in case the table gets editted
>outside of ACS?
[Amogh] Sorry, I don't think I get the question here. The table would only
map the OS name of systemvm, which is standardized in CloudStack, to the
hypervisor specific OS name.
For the undeletable part, please refer to the next one.
>The delete feature is vital. You marked it as open for discussion but
>I don't agree. The admin should delete when he makes a mistake! Or
>when an os has a structural vulnerability!
[Amogh] Sure! I should have been clearer in the doc. I meant to say that
some mappings may be marked as non-editable / non-deletable. These may be
the ones that come bundled in with CloudStack, or a subset of those. This
second point was the one I had in mind with respect to being open for
All admin specified mappings should be editable / deletable.
>How and when is memory mapping done? Someone is busy instantiating a
>template based on an os which in the meanwhile is being deleted. What
[Amogh] This is a good point. The current implementation I have in mind
would use these mappings as the VM details are being created to be sent to
the agent. As such, it should honor the user view of details. Let me get
back with more details on this though.
>On Mon, Mar 3, 2014 at 9:44 PM, Amogh Vasekar <>
>> Hi,
>> CloudStack currently does not allow an easy way to add new guest OS
>> for example, a standard way to add say, CentOS 6.5 even though a
>> hypervisor may support it.
>> Part of the reason is since the OS to hypervisor-specific platform
>> mappings are currently hard-coded into the code-base [1][2]
>> 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,
>> admin will be responsible for providing the mapping to
>> platform names based on his knowledge, which may be enhanced in future.
>> For example, based on [1], an admin should be able to add a mapping
>>like :
>> CentOS 6.5 (64 bit) -> CentsOS 6.5 .
>> The functional spec can be found at :
>> o+add+new+guest+OS+mappings
>> Comments / suggestions welcome.
>> Thanks,
>> Amogh
>> [1]
>> c/com/cloud/hypervisor/kvm/resource/
>> [2]
>> c/com/cloud/hypervisor/xen/resource/

View raw message