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.
...
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.
Xen
- 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.
- 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
- For each host
- Login and type command - xe host-param-clear param-name=tags uuid=<uuid of the XS host>
- Restart MS and the iso should get propagated for all. Check timestamp.
- Restart systemvms and they should get the iso inserted.
VMWare
- 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.
- Forcefully propagate iso OR No change in build version (eg. dev setups) OR only change in the minor version -
- Put your new systemvm.iso on the MS.
- Stop all management server
- Go to Secondary Storage folder
- Remove old systemvm.iso file from systemvm folder (here systemvm<version>.iso, where version is the management server version)
- Start management server.
- 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)
KVM
- Go to kvm host
- Stop cloudstack agent
- Upgrade cloudstack agent
- Restart cloudstack agent
- Stop and Start SystemVMs.
HyperV (Supported only from 4.3.x release onwards)
- Stop Management Server
- Remove systemvm-4.3.0.0.iso from secondary storage (it’ll be located under \\secondary_storage_path\systemvm\)
- Remove systemvm-4.3.0.0.iso from each Hyper-V host (Path: C:\Users\Public\Documents\Hyper-V\Virtual Hard Disks)
- Start Management Server
- Destroy SystemVMs
- 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.
...