Introduction

The current Cloud Stack management server runs only on Linux servers. The purpose of this feature is to run CloudStack management server on windows as well without using Cygwin. This document will illustrate what changes we may need to do at code level and script level. This will also introduce some installation procedures to have in place before running the management server on windows.

Scope

Should able to start/stop/restart management server as a service on windows. Do remember that we are not trying to  manage development setup as well on windows.

We will target for 2k8r2/2k12r2 windows.

Installer will be written to support 64 bit environment for now.

Procedure

We need to convert all shell scripts to Pyhton scripts to make sure those are runnable on windows as well.

Make sure the copied files on windows file system will not change the line ending character other wise it will create a mess after copied to hyper-visor host.

The following modules need to run from windows as well to make sure they run without using cygwin

1. Deploy DB
2. Seed system template onto secondary storage location
3. start/stop/restart management server
4. Samba integration

Setup Databases

The setup databases component has been integrated with MSI installer itself. The wizard will take the needed information from the admin along with the option to create a database for the first time and then does the databases setup before completing the installation.

Seed SystemTemplate

This will execute the following scripts

• scripts/storage/secondary/cloud-install-sys-tmplt
• cripts/storage/secondary/createtmplt.sh
• decrypt.sh

Management Server

When we start the management server currently it is calling the following scripts

• scripts/vm/systemvm/injectkeys.sh
  
  

There are some places in Java code where bash scripts are written inside the jave code.The following list of class files are having such scripts

• com.cloud.utils.net.NetUtils.getDefaultEthDevice()
• com.cloud.server.ConfigurationServerImpl.updateKeyPairs()
  • Need to find alternate tool of "ssh-keygen" for windows 

The following things need to be done as part of installer before start of the management server

1. Create a folder structure mentioned in Installation Structure and Dependencies
2. Copy necessary files to respective fodlers

Samba integration

     <TODO>

Installer

Used WiX tool to write the windows installer which creates a .msi at the end. The tool uses XMLs to generate installer.The extension of Wix Tool input files is ".wxs"

 The following things are happening inside installer. 

1. Selection of installation path
2. Creating the folder structure at installation path selected above
3. Copying the required files to the respective plcaes
4. Adding the following entries to Environment variables
   CATALINA_BASE
    CLOUDSTACK_HOME
    CATALINA_OPTS
5. Opened the following ports in Windows firewall (Picked from Ports used by CloudStack)
   8080
   8096 
   8787 
   9090 
   3922 
   8250 
6. Adding bin paths of Java, Python and 7z to "Path" environment variable.
7. Adding entry to services (Though the start service is not working in the backend service is getting started when we start the service in services)

All these steps are captured at : scripts\installer\windows\acs.wxs

Build MSI 

Integrated it with maven build but for now it runs only on windows. The prerequisite to run the below command is to install "Wix Tool Set V3.8".

Added the following profile to build the msi installer using maven.

"buildw".

Full maven command is: mvn clean install -Dnoredist -P systemvm,buildw

Or alternatively

We use the following tools from Wix tool set to build our msi installer.

1. <Path To WiX Tool>\bin\candle.exe - To compile the files having extension ".wxs" to generate files of extension ".wixpdb"

2. <Path To WiX Tool>\bin\heat.exe - To generate a ".wxs" file by harvesting a directory (to create Directory ref for all existing files in the given directory recursively)

3. <Path To WiX Tool>\bin\light.exe - To generate the final .msi file using the output files generated using the tool in step (1).

Sequence of steps to build final msi file

1. Do a maven build at root of the source code
2. Create a folder at some path called installer
3. copy the directory "client\target\cloud-client-ui-4.4.0-SNAPSHOT" as client to the above folder
4. Copy files from C:\Work\apache_cloudstack\cloudstack\scripts\installer\windows to the above folder
5. go to the above installer folder in command line
6. Run: "<Path To WiX Tool>\bin\heat" dir client -gg -cg Test -ke -sfrag -template fragment -out client.wxs -var wix.SourceClient -dr WEBAPPS
7. Run: "<Path To WiX Tool>\bin\candle.exe" acs.wxs
8. Run: "<Path To WiX Tool>\bin\candle.exe" client.wxs
9. Run: "<Path To WiX Tool>\bin\light.exe" acs.wixobj client.wixobj -out acs.msi  -ext "C:\Program Files (x86)\WiX Toolset v3.8\bin\WixUIExtension.dll" -dSourceClient=SourceDir\client

It will generate acs.msi at the same location where we run aboce commands.

run acs.msi to install Apache Cloud Stack as "Run As Administrator" (By default this is disabled. You need to enable this to run the installer).

Still need to change the logo, text etc according to the community requirements.

Phase-1

The following are included in phase-1

1. Installing Management Server as a service on windows through GUI
   1. Should able to start/stop/restart the service through service manager
   2. Should able to select installation path
2. Setting up databases while installation process itself
   1. Take input needed to setup databases like user/password/root password in UI etc..
   2. Options to create fresh database
   3. Data encryption in database
3. Injecting SSH Keys into systemvm iso
4. SSL key generation on installation automatically
5. Integrating System Template Seeding
6. It supports only xenserver With NFS in phase-1
7. un-installation is supported
8. Cluster setup is supported
9. Integrating MSI file generation with maven build.

Compatibility Metrics

Hypervisors Supported

Storage Types

Issues Found During Phase-1

1. Could not integrate with S3 storage server due to
   1. During Copying from S3 to NFS management server does nfs mount on to the local. On windows we can mount NFS path to a Driver letter only not to the existing path
      1. Solution(s)
         1. Either remove the intermediate step that is copying from S3 to NFS (i.e remove dependency on NFS when we use S3 storage server)
         2. Or Change the code to mount it to a driver letter only for windows and continue for Linux environments as is.

Phase-2

The following will be included in Phase-2

1. localization of the installer
2. Usage Server Installation
3. Integrating awsapi
4. upgrade support
5. Samba Integration to support hyper-visors like vmware, Hyper-v etc..
6. M-Sql Support
7. Extending for other Hypervisors/Storage types

Appendix

Feedback

1. SSH (John Kinsella) :
   Putty doesn’t really want to be used for command-line key generation[1].
   Take a look at libssh[2] - from a glance, that looks like it might be the best approach.
   

   http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/puttygen-batch.html
   http://www.libssh.org/
    

   [Damodar] : Sure we will look into libssh as an alternate for ssh key generation. 

2. .(Alex Hitchins) I certainly wouldn't rely on cygwin in production
        [Damodar] : The idea is to remove dependency on cygwin completely.
   I'd be interested to look into performance comparisons between Java on windows and Linux. Technically, there should be no difference I'd have thought 
        [Damodar] : Will check if time permits.

3. (Alex Huang)
   Management server should never have mounted the NFS secondary storage. We need to fix that. Please have a talk with Kelven about this. I don't see us adding Samba to any machine that runs the management server. If this is just about seeding the system template, it can be done as part of installation rather than management server.
    [Damodar] : As I verified in vmware case we mount SSVM onto local storage. This integration as of now we think is only in case of VMWare.
   If I truly think about Windowsification, I think windows installer, windows service, opening ports in windows firewall. I don't see any of that here. Or else it's useless for windows people.
   [Damodar] : Yes we considered this as a separate note
   For java, most people write a windows service that launches the jvm and keeps track of the jvm.
   There's a number of things that CloudStack management server does today at startup that should not be there and those are what complicates the windowfication. These things should be moved out of the management server and into installation. What should be inside the management server startup procedure should be checks, rather than generations. It should check for ssh key exists and the database version matches etc
        [Damodar] : As of now we identified some of them and covered in the above section (For Ex: Deploy DB, Seeding system Template and installing ssh keys)
    it should not do the following. 
          Upgrade of the database
              [Damodar] : This will be covered as part of deploy db
          ssh key generation
               [Damodar] : Already covered in the details section. For now Assumption is already these keys would have been installed.
          iso generation.
               [Damodar] : You mean systemvm.iso here.. If that is the case then I think this will be part of maven build only.
   

   It's not a serious refactoring. Most of these things are actually isolated in plugins that are separated from the management server already. For example, Rohit was able to use the same plugin that does database upgrade to implement deploydb with relative ease. We just never finished the job to remove it from the management server bootstrap. I don't see the code change as big changes. And these changes benefits CloudStack regardless of it it's windows or not.
        [Damodar] :We will keep in mind of refactoring and we will try to do that where ever is needed.
   I think packaging is where most of the changes are. The good thing is that this packaging is obviously going to be entirely in windows package (won't be rpm for example) so hopefully we keep that in mind and don't disrupt the rpm packaging.
         [Damodar] : Sure we will keep this as well in mind.
   I do see a lot of people who can benefit from this. I think people who are implementing true cloud usages will use our current installation. But I do meet a lot of windows admins who needs help. And they might move over to Linux for actual deployment but even just to get started to try out cloudstack is difficult for them. However, if we're targeting this group, then the current spec is insufficient
         [Damodar] : What areas need to be improved here so that we will incorporate the same into the FS. Still we did not add the Database part(replacing MySql with Microsofr Sql) in this as we are thinking to move that to 2nd phase.