[
https://issues.apache.org/jira/browse/CLOUDSTACK-9046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14996606#comment-14996606
]
ASF GitHub Bot commented on CLOUDSTACK-9046:
--------------------------------------------
Github user wilderrodrigues commented on the pull request:
https://github.com/apache/cloudstack/pull/1050#issuecomment-155080182
Ping @remibergsma @borisroman @DaanHoogland @wido
Tests were executed as described below:
* Deploy 4.4.4
- KVM Host
- Management Server
- 2 VMs running on Isolated Networks + 2Pub IPs + FW/PF
- 2 VPCs with 1 tier each + 1 VM per tier + ACL + PF
- SSH into the 4 VMs to testify it was all fine with 4.4.4
* Upgrade steps
- Register SysteVM 4.5 and 4.6
- Needed because we were upgrading from 4.4.4
- Stop/Update the KVM agent
- Stop/Update the Management Server
- Check the Routers say "Requires Upgrade = YES"
- SSH into SSVM/CPVM and check /etc/cloudstack-release file. It should
say 4.4.1
- Destroy SSVM/CPVM
- Check again the /etc/cloudstack-release file. It should say 4.6.0
- Reboot the Virtual Routers
- Check the /etc/cloudstack-release. It should say 4.6.0
- SSH into the VMs via the public IPs. It should be possible
> Fix upgrade path from 4.4 and 4.5 to 4.6
> ----------------------------------------
>
> Key: CLOUDSTACK-9046
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9046
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Upgrade
> Affects Versions: 4.6.0
> Reporter: Wilder Rodrigues
> Assignee: Wilder Rodrigues
> Priority: Blocker
> Fix For: 4.6.0
>
>
> When upgrading to 4.6 from 4.5 or earlier, the systemvm template that is
> registered upfront is not marked as SYSTEM and set as the template for the
> existing systemvms. Therefore, new systemvms work fine but existing ones
> don't.
> RCA is missing code in the upgrade path, as is present when upgrading from
> 4.4 to 4.5 for example.
> The code in the Upgrade442to450.java is not generic, as the name suggests,
> and simply configures the whole SystemVM and all the existing Domain VMs to
> use the SystemVM-4.5.0 that was registered. It means that after the upgrade
> all the routers were marked okay, but they were using the old stuff, from
> 4.5.0. The attempt to deploy a new VM was also failing with the following
> error (on the host):
> 2015-11-07 18:17:31,135 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-4:null) Exit value is 1
> 2015-11-07 18:17:31,135 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-4:null) Traceback (most recent call last): File
> "/opt/cloud/bin/update_con
> fig.py", line 20, in <module> from merge import QueueFile File
> "/opt/cloud/bin/merge.py", line 23, in <module> import cs_ip File
> "/opt/cloud/bin/cs_ip.py", lin
> e 19, in <module> from netaddr import *ImportError: No module named netaddr
> Why that? Because the KVM host has the new systemvm.iso, which contains all
> the new python stuff, but the systemvm template, which installs the Guest OS
> (Debian) is old and does not contain the modules we now need.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
