This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.

Child pages
  • Adding support for non-US Keyboard for Console Proxy
Skip to end of metadata
Go to start of metadata

Main Files (Present in directory mentioned next to them)

[1] ajaxkeys.js : /usr/share/cloudstack-common/systemvm/js/

[2] ajaxviewer.js : /usr/share/cloudstack-common/systemvm/js/

[3] consoleKeyboardOptions.jsp : /usr/share/cloudstack-management/webapps/client/

References

[1] Support for non-US keyboards in Console Proxy


Note : Bold Italic designates added/modified values

 

After the framework changes as mentioned in [1], It is easier to add support for non-US keyboard for console proxy. To do so one has to just add the mappings for their locale keyboard in one designated file.

How to propagate changes to CPVM

To get these changes take effect in CPVM, one has to stop the console proxy, so that modified files gets copied to CPVM when they are started again by CloudStack.

Glossary:

RAW keyboard

    Primarily translates KeyDown/KeyUp event, either as is (if there is no mapping entry) or through mapped result.
For KeyPress event, it translates it only if there exist a mapping entry in jsX11KeysymMap map and the entry meets the condition 

Example of this kind of keyboard are JP


COOKED keyboard 

       Primarily translates KeyPress event, either as is or through mapped result.
       It translates KeyDown/KeyUp only there exists a mapping entry,
       or if there is no mapping entry, translate when certain modifier key is pressed (i.e., CTRL or ALT key)

Example for this type of keyboard are US, UK, FR


Mapping entry types
direct : will be directly mapped into the entry value with the same event type
boolean : only valid for jsX11KeysymMap, existence of this type, no matter true or false
in value, corresponding KeyDown/KeyUp event will be masked
array : contains a set of conditional mapping entry

Conditional mapping entry

{
type: <event type>, code: <mapped key code>, modifiers: <modifiers>,
shift : <shift state match condition>, -- match on shift state
guestos : <guest os match condition>, -- match on guestos type
browser: <browser type match condition>, -- match on browser
browserVersion: <brower version match condition> -- match on browser version
guestosDisplayName: <guest os display name condition> -- matches on specific version of guest os
provide the guest os display name substring to uniquely identify version
for example if guestosDisplayName CentOS 5.2 (32-bit), then to match this condition
give unique substring to identify like 5.2 or CentOS 5.2 etc.
hypervisor: <hypervisor match condition> --match on hypervisor
hypervisorVersion: <hypervisor version match condition> --match on hypervisor version
}

 

Changes needs to be done in consoleKeyboardOptions.jsp

To add new keyboard for console proxy add the corresponding parameters in  file [3] consoleKeyboardOptions.jsp. Option added here will be displayed while deploying VM.

for example say  file [3] consoleKeyboardOptions.jsp is looking like below

 <option value="us"><fmt:message key="label.standard.us.keyboard" /></option>
 <option value="uk"><fmt:message key="label.uk.keyboard" /></option>
 <option value="jp"><fmt:message key="label.japanese.keyboard" /></option>
 <option value="fr">French AZERTY keyboard</option>

Then to add keyboard for simplified chinese add the line as follows

 <option value="us"><fmt:message key="label.standard.us.keyboard" /></option>
 <option value="uk"><fmt:message key="label.uk.keyboard" /></option>
 <option value="jp"><fmt:message key="label.japanese.keyboard" /></option>
 <option value="fr">French AZERTY keyboard</option>
<option value="sc"><fmt:message key="label.simplified.chinese.keyboard" /></option>

 

Changes needs to be done in ajaxkeys.js

Add the keyboard in  file [1] ajaxkeys.js also. Where to add the keyboard option in file [1] ajaxkeys.js will depend upon your keyboard layout.

We divide the keyboard layout into two categories cooked keyboard and raw keyboard as mentioned in glossary

To add the cooked keyboard type, add in below section in ajakeys.js

var cookedKeyboardTypes = {"us":"Standard (US) keyboard",

                                                                 "uk":"UK keyboard",

                                              "fr":"French AZERTY keyboard"}

and to add the raw keyboard type add in section 

 var rawKeyboardTypes = {"jp":"Japanese keyboard"}

Make sure key is same as value in consoleKeyboardOptions.jsp

Say if you consider simplified Chinese of type raw keyboard then add it as follow

var rawKeyboardTypes = {"jp":"Japanese keyboard",

                                          "sc":"Simplified Chinese keyboard"}

Make a note "sc" key is same as value in file [3] consoleKeyboardOptions.jsp

It will be good practice to add the constant for your keyboard. To do so add constant in below section. For example to add constant for simplified Chinese add it as shown below

 

Add the constant for your keyboard type in section.

KEYBOARD_TYPE_COOKED = "us";

KEYBOARD_TYPE_JP = "jp";

KEYBOARD_TYPE_UK = "uk";

KEYBOARD_TYPE_FR = "fr";

KEYBOARD_TYPE_SC = "sc";


After the adding keyboard in one of above categories its time to define the key mappings. Focus should be on those keys which are not working by default.

To do so create index for your keyboard as shown below

Say your ajaxkeys.js looks like as shown below,

 

var keyboardTables = [
{tindex: 0, keyboardType: KEYBOARD_TYPE_COOKED, mappingTable:
{X11: [ .............
],
keyPress: [ ...........
]
}
},
{tindex: 1, keyboardType: KEYBOARD_TYPE_UK, mappingTable:
{X11: [ .............
],
keyPress: [ ...........
]
}
},
{tindex: 2, keyboardType: KEYBOARD_TYPE_JP, mappingTable:
{X11: [ .............
],
keyPress: [ ...........
]
}
}

Then after modification it will look like

 

var keyboardTables = [
{tindex: 0, keyboardType: KEYBOARD_TYPE_COOKED, mappingTable:
{X11: [ .............
],
keyPress: [ ...........
]
}
},
{tindex: 1, keyboardType: KEYBOARD_TYPE_UK, mappingTable:
{X11: [ .............
],
keyPress: [ ...........
]
}
},
{tindex: 2, keyboardType: KEYBOARD_TYPE_JP, mappingTable:
{X11: [ .............
],
keyPress: [ ...........
]
}
},

{tindex: 3, keyboardType: KEYBOARD_TYPE_SC, mappingTable:

               {X11: [ .............

                     ],

                keyPress: [ ...........

                        ]

               }

           }

]

Here KEYBOARD_TYPE_SC is constant "sc" as defined above.

After creating index its time to add the conditional map entries into X11 and keyPress array. It will depend on your keyboard in which you want to put your conditional entries.

Conditional map entries can be of two types

Type 1 (entry is numeric code)

{keycode: 34,      entry: 0x40,   guestos: "windows"},
{keycode: 160,  entry : 0x5e,  guestos: "windows",    browser: "Firefox"},

Here entry is numeric code. If entry doesn't match the conditions then default handling will be done. 

 

Type 2 (entry is of array type)

{keycode: 43, entry: [
{type: KEY_DOWN, code: X11_KEY_SHIFT, modifiers: 0, shift: false },
{type: KEY_DOWN, code: X11_KEY_ADD, modifiers: 0, shift: false },
{type: KEY_UP, code: X11_KEY_ADD, modifiers: 0, shift: false },
{type: KEY_UP, code: X11_KEY_SHIFT, modifiers: 0, shift: false },
{type: KEY_DOWN, code: X11_KEY_ADD, modifiers: 0, shift: true },
{type: KEY_UP, code: X11_KEY_ADD, modifiers: 0, shift: true },
]
}

Here entry is array of entries. Each entry states the conditions on which it will match and the code to which it will match. If one specifying entry in this format then he/she has to specify entry for all the possible combinations. By possible combiations it means that entries should be able to find mapping. If they are not able to identify mapping then no event will be sent. So If you are specifying browser in one condition then you have to specify entries for all browsers. 

 

Here keycode is input keycode and entry is output which will determine the key shown on VM console. This entry will only applied if it matches condition which are mentioned next to it.

Here in first entry condition is guestos: "windows" i.e. match only if guestos is windows while in second conditional map entry one more condition is added that match only if guestos is windows and browser is firefox. 

Conditional mapping entries can be defined on the conditions which are mentioned in glossary conditional mapping entry.


We should normally be using only Type 1 entries but in some exceptional cases Type 2 entries can also be used. Type 2 entries can be used if one want different code KEY_DOWN and KEY_UP for keycode.

 

How to identify input keycode and output keycode (Taken from FS)

If you don't want to go into details then go directly to section Key type events though it will be a good idea to get some understanding.

The journey of a key

When a key is pressed on the user keyboard, before it reaches its destination and displays a key output on the user VM, it passes through the browser the client uses, the client OS, the console proxy, the server side hypervisor, host OS, and displays a key on the VM. Even when console proxy does the key translation correctly according to the standard and keyboard layout, any component in this path can change the key translation, hence it can make the key output at the end user VM incorrect. 

Each component, for example, the OS, usually has its own key translation mechanism. With all the components’ own key translation involved, it adds complication to the console proxy key translation. In the end, the correct key translation for the console proxy is to make the correct key gets displayed at the end user VM.

For each different language keyboard, the main engine to be changed is the keyboard key translation rules and tables. There are ten parameters affecting which keyboard translation table to deploy. Five parameters are on server side, which include server OS, hypervisor, and keyboard. Server can obtain this information from the ManagementServer (MS) in Cloudstack. 

Parameters on server side: 

  1. s_os: OS type for VM, such as Windows, Linux (Rhel, Centos, …)
  2. s_osVersion: os version;
  3. s_hypervisor: hypervisor type, such as Vmware, Xen, LVM, Hyper
  4. s_hypVersion: version;
  5. s_keyb: VM keyboard, such as English keyboard(EN), Japanese, …

There are five parameters on client side:

  1. c_os: client OS type, such as Windows, Linux ...
  2. c_osVersion: OS version;
  3. c_browser: IE(IE can have different versions too, IE8, IE9, etc); Firefox, Chrome, Safari
  4. c_browserVersion: browser version;
  5. c_keyb: client keyboard, English keyboard(EN), Japanese(jp), ….
    Based on the different combination of the parameters on the server side and the client side, each combination corresponds to one keyboard mapping table.

Console proxy language keyboard translation

At present, if anyone needs to add a new keyboard support for a language, he needs to spend time understanding the console proxy code and the various key translation logic and rules. Then he can modify a javasript file to add the new language key translation table. However, since this javascript file contains complex logic and rules used for other languages, any change to this file needs to be thought out carefully, otherwise it can cause regression and made some existing keys fail. 

To make this process easier, we refactor the console proxy code for keyboard support. Our goal is to save users and developers time to understand the code path, and limit the scope of change as much as possible. Hence it can reduce the possibility of regression and testing time. After the refactor, the majority of keyboard translation rules and logic stay in a file which the users will not need to understand fully and make modifications. Users only need to modify a small table, which has direct input and output mapping, This small file to be modified handles some special keys for the special language keyboard. 

For special keyboard such as Japanese keyboard, it is required that the hypervisor, host OS and browser also need to deploy Japanese version. 
Even though the console proxy does the translation we expect, the final result at the end may not display the correct key, because of the other components and their own key translations along the way. Hence, all we need to find at the console proxy level is to get the input key translated to a value that eventually display the proper key at the user VM terminal.

What is input and output key codes
Ajaxviewer.js is a javascript file handles all the keys translations. We refer to this translation ‘T’. 

There are two codes users need to be aware of and work with:
Input_keycode: this is the keycode when user presses a key, before any translation. It is related to the key’s physical location on the keyboard;

Output_keycode: this is the keycode sent out by console proxy, to display the correct key on the VM, after all the translations;

T(input_keycode) = output_keycode; 

For example, a general ASCII letter a, we may have T(97) = 97; – when the key for ‘a’ is pressed, the input code is 97; when output keycode is 97, letter ‘a’ is displayed on user VM;

 Key type events 
There are two types of key events: key down/key up, and key press. 

There are two main translation schemes: X11 key system and non-X11 key systems. For X11 key system, the translation follows the X11 keys. It handles the key down/key up events, and skip the key press event. For example, a translation for CapsLock key may be like this (we use X11_ prefix to denote the X11 key):

T(KEY_CAPSLOCK) = X11_KEY_CAPSLOCK 

For non-X11 key system, it does not use the standard X11 key code. It mainly handles the key press event. We build a translation table to handle the majority of the keys for non-X11. 

For the majority of the keys, the logic and rules are set up in ajaxviewer.js. Users do not normally need to modify this file, unless there is a need to change or add any rule there. Users for a special keyboard support need to add entries into the table in ajaxkeys.js. This is a table to handle the special keys which are not covered by the rules and tables in ajaxviewer.js. The rules in ajaxviewer.js handles the default key translation and covers the common keys on the keyboard. It has rules for the special keys. It treats the special keys in a conditional mapping table. For each special keyboard, users just add the entries in the conditional event mapping table in ajaxkeys.js. 

Algorithm for the X11 type of keys:
Step 1: if entry exists in the jsX11KeysymMap table in ajaxviewer.js, translate that key to a corresponding X11_key in that table using key down/key up event;
Step 2: if the condition matches, translate the keys in the conditional map table with jsX11KeysymMap;

For non-X11 type of keys: it handles only the keyPress events; 
Step 1: for every keyPress event, do the key translation;
Step 2: shall only handles key down/up event if all the conditions are true for a special key in the conditional mapping table. 

The conditional mapping table is in a separate file ajaxkeys.js, it has the format for each conditional entry:

 

Conditional mapping entry   { 
    type: <event type>, code: <mapped key code>, modifiers: <modifiers>,
    shift : <shift state match condition>,        -- match on shift state
    guestos : <guest os match condition>,     -- match on guestos type
    browser: <browser type match condition>,  -- match on browser
    browserVersion: <brower version match condition>  -- match on browser version
    guestosDisplayName: <guest os display name condition>  -- matches on specific version of guest os
provide the guest os display name substring to uniquely identify version
for example if guestosDisplayName CentOS 5.2 (32-bit), then to match this condition
give unique substring to identify like 5.2 or CentOS 5.2 etc.
hypervisor: <hypervisor match condition> --match on hypervisor
hypervisorVersion: <hypervisor version match condition> --match on hypervisor version
}

 

For example a match for a particular browser can be like this:

 

{keycode: 59, entry: X11_KEY_COLON, browser: "Firefox"}, when the browser is Firefox, the rule will apply. Otherwise the rule will not apply. 

 

Browser, type and guestos all have string type.

 

Where should key entry go

If key is printable (can be seen after typing in document like ascii characters) then it should go in keyPress map. For prinatble keys we are guaranteed of keyPress event. One can verify whether keyPress event is generated using sites available online. One such site is http://unixpapa.com/js/testkey.html. All other keys except printable should go in X11 keys.

 

Find the input_keycode and output_keycode for a particular key

The new translation table in ajaxkeys.js handles the conditional mappings for some special keys. It implements the “T” function: T(input_keycode) = output_keycode. 

When a key is pressed, we need to know its input_keycode, so that we can find out if it already has an entry in the table. If it has an entry in the table, but the output is not correct, we need to modify or add a conditional entry to match the current browser and os conditions. If there is no existing entry for this key, we need to add a new entry in the table. So by all means, we need to know its input_keycode. 

To find out the Input_keycode, we can turn on the keyboard logger window which will show the keycode for every key pressed. “CTRL-ATL-SHIFT+SPACE” turns on the lodger or click on green circle icon on top-right corner. To have a fresh window to show the code for a new key, clear the window first, and then press a key.

However, for the value of output_keycode, it is tricky. It is more of a trial and error process. We can search the keyboard standard key document, and try various values. We can try pressing different keys and see what input_keycode  generates what output on console. Using these trials we can get the output_code of the key. 

For example:

User pressed Key "$", for this say input_keycode is 36 but on screen we are getting "&". Now user tries different key

say User pressed Key "^", and say its input_keycode is 40 but on screen we are getting "$"

so we can safely deduce from that output_keycode (If it already exists in key mapping) of "^" should be output_code of "$".

If key mapping doesn't exist then we can try putting input_keycode of "^" as output_keycode of "$".

Changes to be done in ajaxviewer.js

Ideally we should not be touching this file but sometime situation arises that something is missing then we need to modify this file.

ajaxviewer.js manipulates conditional mapping entries defined in ajaxkeys.js and creates mapping table for translation. 

 Situation like you need one more condition to make life easy for you.

Possible values for conditional mapping entry conditions

These values are taken from guest_os_category table in cloud DB of CloudStack.

guestos : CentOS, Debian, Oracle, RedHat, SUSE, Windows, Other, Novel, Unix, Ubuntu, None

 

Possible Value for guestOsDisplayName

These values are taken from display_name column in guest_os table. To see current list of guest os available refer the CloudStack documents. Or this can be seen from OS Type in template details or while registering template

CentOS 4.5 (32-bit) 
CentOS 4.6 (32-bit)
CentOS 4.7 (32-bit)
CentOS 4.8 (32-bit)
CentOS 5.0 (32-bit)
CentOS 5.0 (64-bit)
CentOS 5.1 (32-bit)
CentOS 5.1 (64-bit)
CentOS 5.2 (32-bit)
CentOS 5.2 (64-bit)
CentOS 5.3 (32-bit)
CentOS 5.3 (64-bit)
CentOS 5.4 (32-bit)
CentOS 5.4 (64-bit)
Debian GNU/Linux 5.0 (64-bit)
Oracle Enterprise Linux 5.0 (32-bit)
Oracle Enterprise Linux 5.0 (64-bit)
Oracle Enterprise Linux 5.1 (32-bit)
Oracle Enterprise Linux 5.1 (64-bit)
Oracle Enterprise Linux 5.2 (32-bit)
Oracle Enterprise Linux 5.2 (64-bit)
Oracle Enterprise Linux 5.3 (32-bit)
Oracle Enterprise Linux 5.3 (64-bit)
Oracle Enterprise Linux 5.4 (32-bit)
Oracle Enterprise Linux 5.4 (64-bit)
Red Hat Enterprise Linux 4.5 (32-bit)
Red Hat Enterprise Linux 4.6 (32-bit)
Red Hat Enterprise Linux 4.7 (32-bit)
Red Hat Enterprise Linux 4.8 (32-bit)
Red Hat Enterprise Linux 5.0 (32-bit)
Red Hat Enterprise Linux 5.0 (64-bit)
Red Hat Enterprise Linux 5.1 (32-bit)
Red Hat Enterprise Linux 5.1 (64-bit)
Red Hat Enterprise Linux 5.2 (32-bit)
Red Hat Enterprise Linux 5.2 (64-bit)
Red Hat Enterprise Linux 5.3 (32-bit)
Red Hat Enterprise Linux 5.3 (64-bit)
Red Hat Enterprise Linux 5.4 (32-bit)
Red Hat Enterprise Linux 5.4 (64-bit)
SUSE Linux Enterprise Server 9 SP4 (32-bit)
SUSE Linux Enterprise Server 10 SP1 (32-bit)
SUSE Linux Enterprise Server 10 SP1 (64-bit)
SUSE Linux Enterprise Server 10 SP2 (32-bit)
SUSE Linux Enterprise Server 10 SP2 (64-bit)
SUSE Linux Enterprise Server 10 SP3 (64-bit)
SUSE Linux Enterprise Server 11 (32-bit)
SUSE Linux Enterprise Server 11 (64-bit)
Windows 7 (32-bit)
Windows 7 (64-bit)
Windows Server 2003 Enterprise Edition(32-bit)
Windows Server 2003 Enterprise Edition(64-bit)
Windows Server 2008 (32-bit)
Windows Server 2008 (64-bit)
Windows Server 2008 R2 (64-bit)
Windows 2000 Server SP4 (32-bit)
Windows Vista (32-bit)
Windows XP SP2 (32-bit)
Windows XP SP3 (32-bit)
Other Ubuntu (32-bit)
Other (32-bit)
Windows 2000 Server
Windows 98
Windows 95
Windows NT 4
Windows 3.1
Red Hat Enterprise Linux 3(32-bit)
Red Hat Enterprise Linux 3(64-bit)
Open Enterprise Server
Asianux 3(32-bit)
Asianux 3(64-bit)
Debian GNU/Linux 5(64-bit)
Debian GNU/Linux 4(32-bit)
Debian GNU/Linux 4(64-bit)
Other 2.6x Linux (32-bit)
Other 2.6x Linux (64-bit)
Novell Netware 6.x
Novell Netware 5.1
Sun Solaris 10(32-bit)
Sun Solaris 10(64-bit)
Sun Solaris 9(Experimental)
Sun Solaris 8(Experimental)
FreeBSD (32-bit)
FreeBSD (64-bit)
SCO OpenServer 5
SCO UnixWare 7
Windows Server 2003 DataCenter Edition(32-bit)
Windows Server 2003 DataCenter Edition(64-bit)
Windows Server 2003 Standard Edition(32-bit)
Windows Server 2003 Standard Edition(64-bit)
Windows Server 2003 Web Edition
Microsoft Small Bussiness Server 2003
Windows XP (32-bit)
Windows XP (64-bit)
Windows 2000 Advanced Server
SUSE Linux Enterprise 8(32-bit)
SUSE Linux Enterprise 8(64-bit)
Other Linux (32-bit)
Other Linux (64-bit)
Other Ubuntu (64-bit)
Windows Vista (64-bit)
DOS
Other (64-bit)
OS/2
Windows 2000 Professional
Red Hat Enterprise Linux 4(64-bi
SUSE Linux Enterprise 9(32-bit)
SUSE Linux Enterprise 9(64-bit)
SUSE Linux Enterprise 10(32-bit)
SUSE Linux Enterprise 10(64-bit)
CentOS 5.5 (32-bit)
CentOS 5.5 (64-bit)
Red Hat Enterprise Linux 5.5 (32-bit)
Red Hat Enterprise Linux 5.5 (64-bit)
Fedora 13
Fedora 12
Fedora 11
Fedora 10
Fedora 9
Fedora 8
Ubuntu 10.04 (32-bit)
Ubuntu 9.10 (32-bit)
Ubuntu 9.04 (32-bit)
Ubuntu 8.10 (32-bit)
Ubuntu 8.04 (32-bit)
Ubuntu 10.04 (64-bit)
Ubuntu 9.10 (64-bit)
Ubuntu 9.04 (64-bit)
Ubuntu 8.10 (64-bit)
Ubuntu 8.04 (64-bit)
Red Hat Enterprise Linux 2
Debian GNU/Linux 6(32-bit)
Debian GNU/Linux 6(64-bit)
Oracle Enterprise Linux 5.5 (32-bit)
Oracle Enterprise Linux 5.5 (64-bit)
Red Hat Enterprise Linux 6.0 (32-bit)
Red Hat Enterprise Linux 6.0 (64-bit)
None
Other PV (32-bit)
Other PV (64-bit)
CentOS 5.6 (32-bit)
CentOS 5.6 (64-bit)
CentOS 6.0 (32-bit)
CentOS 6.0 (64-bit)
Oracle Enterprise Linux 5.6 (32-bit)
Oracle Enterprise Linux 5.6 (64-bit)
Oracle Enterprise Linux 6.0 (32-bit)
Oracle Enterprise Linux 6.0 (64-bit)
Red Hat Enterprise Linux 5.6 (32-bit)
Red Hat Enterprise Linux 5.6 (64-bit)
SUSE Linux Enterprise Server 10 SP3 (32-bit)
SUSE Linux Enterprise Server 10 SP4 (64-bit)
SUSE Linux Enterprise Server 10 SP4 (32-bit)
SUSE Linux Enterprise Server 11 SP1 (64-bit)
SUSE Linux Enterprise Server 11 SP1 (32-bit)
Ubuntu 10.10 (32-bit)
Ubuntu 10.10 (64-bit)
Sun Solaris 11 (64-bit)
Sun Solaris 11 (32-bit)
Windows PV
CentOS 5.7 (32-bit)
CentOS 5.7 (64-bit)
Ubuntu 12.04 (32-bit)
Ubuntu 12.04 (64-bit)
Windows 8 (32-bit)
Windows 8 (64-bit)
Windows Server 2012 (64-bit)
Windows Server 2012 R2 (64-bit)
Ubuntu 11.04 (32-bit)
Ubuntu 11.04 (64-bit)
CentOS 6.3 (32-bit)
CentOS 6.3 (64-bit)
CentOS 5.8 (32-bit)
CentOS 5.8 (64-bit)
CentOS 5.9 (32-bit)
CentOS 5.9 (64-bit)
CentOS 6.1 (32-bit)
CentOS 6.1 (64-bit)
CentOS 6.2 (32-bit)
CentOS 6.2 (64-bit)
CentOS 6.4 (32-bit)
CentOS 6.4 (64-bit)
Debian GNU/Linux 7(32-bit)
Debian GNU/Linux 7(64-bit)
SUSE Linux Enterprise Server 11 SP2 (64-bit)
SUSE Linux Enterprise Server 11 SP2 (32-bit)
SUSE Linux Enterprise Server 11 SP3 (64-bit)
SUSE Linux Enterprise Server 11 SP3 (32-bit)
Red Hat Enterprise Linux 5.7 (32-bit)
Red Hat Enterprise Linux 5.7 (64-bit)
Red Hat Enterprise Linux 5.8 (32-bit)
Red Hat Enterprise Linux 5.8 (64-bit)
Red Hat Enterprise Linux 5.9 (32-bit)
Red Hat Enterprise Linux 5.9 (64-bit)
Red Hat Enterprise Linux 6.1 (32-bit)
Red Hat Enterprise Linux 6.1 (64-bit)
Red Hat Enterprise Linux 6.2 (32-bit)
Red Hat Enterprise Linux 6.2 (64-bit)
Red Hat Enterprise Linux 6.3 (32-bit)
Other CentOS (32-bit)
Other CentOS (64-bit)
Other SUSE Linux(32-bit)
Other SUSE Linux(64-bit)
Red Hat Enterprise Linux
Red Hat Enterprise Linux
Red Hat Enterprise Linux
Oracle Enterprise Linux 5.7 (32-bit)
Oracle Enterprise Linux 5.7 (64-bit)
Oracle Enterprise Linux 5.8 (32-bit)
Oracle Enterprise Linux 5.8 (64-bit)
Oracle Enterprise Linux 5.9 (32-bit)
Oracle Enterprise Linux 5.9 (64-bit)
Oracle Enterprise Linux 6.1 (32-bit)
Oracle Enterprise Linux 6.1 (64-bit)
Oracle Enterprise Linux 6.2 (32-bit)
Oracle Enterprise Linux 6.2 (64-bit)
Oracle Enterprise Linux 6.3 (32-bit)
Oracle Enterprise Linux 6.3 (64-bit)
Oracle Enterprise Linux 6.4 (32-bit)
Oracle Enterprise Linux 6.4 (64-bit)
Apple Mac OS X 10.6 (32-bit)
Apple Mac OS X 10.6 (64-bit)
Apple Mac OS X 10.7 (32-bit)
Apple Mac OS X 10.7 (64-bit)
FreeBSD 10 (32-bit)
FreeBSD 10 (64-bit)
CentOS 6.5 (32-bit)
CentOS 6.5 (64-bit)
Windows 8.1 (64-bit)
Windows 8.1 (32-bit)
CentOS 5 (32-bit)
CentOS 5 (64-bit)
Oracle Enterprise Linux 5 (32-bit)
Oracle Enterprise Linux 5 (64-bit)
Oracle Enterprise Linux 6 (32-bit)
Oracle Enterprise Linux 6 (64-bit)
Red Hat Enterprise Linux 5 (32-bit)
Red Hat Enterprise Linux 5 (64-bit)
Red Hat Enterprise Linux 6 (32-bit)
Red Hat Enterprise Linux 6 (64-bit)
Ubuntu 14.04 (32-bit)
SUSE Linux Enterprise Server 12 (64-bit)
Red Hat Enterprise Linux 7
CentOS 7
Oracle Linux 7
CentOS 6 (32-bit)
CentOS 6 (64-bit)
Oracle Enterprise Linux 6.5 (32-bit)
Oracle Enterprise Linux 6.5 (64-bit)
Red Hat Enterprise Linux 6.5 (32-bit)
Red Hat Enterprise Linux 6.5 (64-bit)
Ubuntu 14.04 (64-bit)
CoreOS

Possible Values of hypervisor and hypervisorVersion

These values are taken from hypervisor_type and hypervisor_version column of  hypervisor_capabilities table in cloud DB. Refer this table for latest possible values.

hypervisorhypervisorVersion
 XenServer
default
 XenServer
XCP 1.0
 XenServer
5.6
XenServer
5.6 FP1
XenServer
5.6 SP2
XenServer
6.0
XenServer
6.0.2
XenServer
6.1.0
XenServer
6.2.0
XenServer
6.5.0

VMware

default 

VMware

4.0

VMware

4.1
VMware
5.0
VMware
5.1
VMware
5.5

KVM

default 

Ova

default
Ova
2.3
LXC
default

Hyperv

6.2

Ovm3

3.2

Ovm3

3.3

 

  • No labels