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

Compare with Current View Page History

« Previous Version 17 Next »


Introduction

Systemvm.iso contains all our systemvm (ssvm, cpvm, routervm)  agent code(java + some scripts) that gets patched onto the systemvms once they are deployed. The procedure for patching them is different for different hypervisors.

Mechanism of propagating systemvm.iso

Systemvm.iso gets propagated differently for different hypervisors. It is part of the Cloudstack rpm or is built on dev environments when the systemvms are built (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 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 else nothing happens. 

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

Hyperv - TODO 

Updating an existing systemvm.iso

Lets say you made a fix in the agent code meaning systemvm.iso is changed.  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.
    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. For each host 
        1. Login and type command - xe host-param-clear param-name=tags uuid=<uuid of the XS host>
      2. Restart MS and the iso should get propagated for all. Check timestamp. 
      3. 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.
    2. Forcefully propagate iso OR No change in build version (eg. dev setups) OR only change in the minor version -
      1. Stop all management server
      2. Go to Secondary Storage folder
      3. Remove old systemvm.iso file from systemvm folder (here systemvm<version>.iso, where version is the management server version)
      4. Start management server.
      5. 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. 

  • No labels