SystemVm.iso

Introduction

Mechanism of propagating systemvm.iso

Systemvm.iso gets propagated differently for different hypervisors. It comes packaged as part of the Cloudstack rpm or is built on dev environments with the command "mvn clean install -P developer,systemvm" (More info on building cloudstack) . 

Once the iso is at the appropriate location depending on the hypervisor it is inserted as a cd drive and the contents are put on the systemvms. Below is an explanation of how they are propagated for each hypervisor.

Xenserver - 

When the host is added, MS pushes the systemvm.iso from MS to XS at the location "/opt/xensource/packages/iso/systemvm.iso" and creates a tag on XS of the form 'vmops-version-com.cloud.hypervisor.xenserver.resource.XenServer602Resource-4.5.0-SNAPSHOT' .

Basically it has three parts. 

1. Constant String - "vmops-version-"
2. Class name containing the code implementation of the tag "com.cloud.hypervisor.xenserver.resource.XenServer602Resource" + "-"
   Java code - this.getClass().getName() 
3. Cloudstack version - "4.5.0-SNAPSHOT"
   Java code - CitrixResourceBase.class.getPackage().getImplementationVersion()

Every time MS restarts / host reconnects happens the tag is checked.  If it has changed then it copies the iso to the host and recreates the tag. 

Vmware -

When CS is configured and tries to deploy the first systemvm, VmwareManagerImpl as part of starting the vm does a check to find out whether sec storage contains a systemvm.iso file with the current CS version (Java code - version = this.getClass().getPackage().getImplementationVersion()). If it doesnt find it then it copies the systemvm.iso to the secondary storage from MS under the systemvm folder (looks something like systemvm-4.4.0-SNAPSHOT.iso).

KVM - 

The iso comes in as part of the agent install on the kvm host. It gets updated every time you upgrade the agent.

Hyperv - TODO 

Updating an existing systemvm.iso

Systemvm.iso changes whenever a fix is made in the systemvm code. This means the new iso needs to be propagated to the systemvms Lets see how it can be picked up by the systemvms. Here is the guide for that.   

1. Xen

   1. Major change in build version -  The changes to systemVM.ISO will get propagated automatically if there is a major change in the build version ( eg. it would be propagated if there were a change from 4.3.0 to 4.3.1), no separate procedure or steps are required. This is because the tag has changed. But say its a minor build version change (say from 4.2.1.0 -> 4.2.1.1) then you need to follow step b below to propagate the iso. Basically versioning depends on how you build rpm. Even minor change can automatically propagate the iso if the versioning was injected in the rpm.
   2. Forcefully propagate iso OR No change in build version (eg. dev setups) OR only change in the minor version - You will have to do the following 
      1. Ensure to backup the existing systemvm.iso (copy systemvm.iso under /usr/share/cloudstack-­‐common/vms to a temporary location. NOTE - this location is for rpm installs of CS)
         
      2. For each host 
         1. Login and type command - xe host-param-clear param-name=tags uuid=<uuid of the XS host>
      3. Restart MS and the iso should get propagated for all. Check timestamp. 
      4. Restart systemvms and they should get the iso inserted.

2. VMWare 

   1. Change in build version -  The changes to systemVM.ISO will get propagated automatically if there is a major change in the build version ( eg. it would be propagated if there were a change from 4.3.0 to 4.3.1), no separate procedure or steps are required. But say its a minor build version change (say from 4.2.1.0 -> 4.2.1.1) then you need to follow step b below to propagate the iso. The propagation of iso onto the sec. storage happens as part of starting system vm. Basically versioning depends on how you build rpm. Even minor change can automatically propagate the iso if the versioning was injected in the rpm.
   2. Forcefully propagate iso OR No change in build version (eg. dev setups) OR only change in the minor version -
   1. 1. Ensure to backup the existing systemvm.iso (copy systemvm.iso under /usr/share/cloudstack-­‐common/vms to a temporary location. NOTE - this location is for rpm installs of CS)
      2. Put your new systemvm.iso on the MS.
      3. Stop all management server
      4. Go to Secondary Storage folder
      5. Remove old systemvm.iso file from systemvm folder (here systemvm<version>.iso, where version is the management server version)
      6. Start management server.
      7. Stop and Start the SystemVMs (Once the SSVM is started new systemvm.iso will be applied) (check if new systemvm.iso is pushed in your secondary storage’s systemvm folder as part of start of the systemvm. You should see something related to it in the logs)

3. KVM

   1. Go to kvm host
   2. Stop cloudstack agent
   3. Upgrade cloudstack agent
   4. Restart cloudstack agent
   5. Stop and Start SystemVMs.

4. HyperV (Supported only from 4.3.x release onwards)

1. Stop Management Server
2. Remove systemvm-4.3.0.0.iso from secondary storage (it’ll be located under \\secondary_storage_path\systemvm\)
3. Remove systemvm-4.3.0.0.iso from each Hyper-V host (Path: C:\Users\Public\Documents\Hyper-V\Virtual Hard Disks)
4. Start Management Server
5. Destroy SystemVMs
6. New SystemVMs will be spawned and the new iso (systemvm-4.3.0.1.iso) will get copied to the secondary storage and Hypervisor host also.

Injecting keys into systemvm.iso

On every start of MS public key is inserted into the systemvm.iso so that admin/MS can passwordless ssh into systemvms. These are also the global configs (encrypted) - ssh.privatekey and ssh.publickey.