Hi, Try this, it was written for your situation!
http://cloud.kelceydamage.com/cloudfire/blog/2013/10/08/conquering-the-cloudstack-4-2-dragon-kvm/ -Kelcey Sent from my HTC ----- Reply message ----- From: "Marcus Sorensen" <shadow...@gmail.com> To: <dev@cloudstack.apache.org> Subject: 4.2.0 Upgrade and System Templates (KVM - Ubuntu 12.04) Date: Sat, Oct 26, 2013 4:22 PM I'm not sure. Somebody on the list has asked about this before, so you may be able to find answers in the history. I've never actually done it because I could never get answers about how it was supposed to work. I did do some digging and found that cloudstack always looks for the newest system type template of a certain name and uses that. But I wasn't sure how the script went about triggering a redeploy of the root disk, it just seemed to reboot the VMS. Personally, I've always just replaced the template file by hand, swapping out the old file with the the new on secondary and primary storage, then set the global variable that recreates system VMs when you restart them. I wouldn't recommend doing it that way unless you don't care if it gets messed up (Dev environment). When I ran through upgrade scenarios in testing the release, I was always using the newer template with 4.1 thus didn't need to do that step. On Oct 26, 2013 3:08 PM, "Marty Sweet" <msweet....@gmail.com> wrote: > Hi Marcus, > > That is so irritating, when registering the new template using the > interface should the routing box be checked? > I say this because on past system templates they appear as routing in the > database although it is not specifically stated in the docs (as I assume it > wasn't an option in 3.x). > > Also, how would I go about downloading this now? Seeing as my SecStorage VM > is offline? > This script seems to have little effect: > > > /usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt > -m /var/export/secondary -u > > http://d21ifhcun6b1t2.cloudfront.net/templates/4.2/systemvmtemplate-2013-06-12-master-kvm.qcow2.bz2 > -h kvm -s mykey -F -o localhost -r root -d mypassword > > cloudstack-sysvmadm -d 127.0.0.1 -u cloud -p -a > Running item 12 fails with and shows a nice list of options for the > command: > /usr/bin/cloudstack-sysvmadm: line 21: /etc/rc.d/init.d/functions: No such > file or directory > > Thanks for your help so far! > Marty > > > On Sat, Oct 26, 2013 at 9:51 PM, Marcus Sorensen <shadow...@gmail.com > >wrote: > > > Yes, you do need to upgrade your system VMS, and you should also have a > new > > systemvm.iso that was bundled in the cloudstack-common deb file that > would > > have been installed as an upgrade on your KVM hosts. I also feel that the > > documentation of system vm upgrade is lacking. The only place I know if > is > > in the release notes: > > > > > http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.2.0/html-single/Release_Notes/index.html > > , > > see 3.1 "Upgrade Instructions", item 12. It references a script > > "cloudstack-sysvmadm", but the upgrade of the system vm template should > be > > done beforehand. Now look at the section just below, 3.2. This > > documentation is obviously messed up because it first says "this applies > > only to VMware", and then it promptly gives system vm upgrade > instructions > > for XenServer, KVM, and VMWare hosts. It's unclear why this system vm > > upgrade would only apply to zones which had VMware hosts, and why these > > instructions aren't also on the 4.1.x to 4.2.x instructions. At any rate, > > the system vm instuctions there for KVM should apply. Register the > template > > (optionally, check the data base to ensure the template is set as system > > type), then restart the system vms per the item 12 script. If your KVM > > hosts relaunch the system vms per the new template and they have the new > > systemvm.iso, they should work. > > > > > > On Oct 26, 2013 2:19 PM, "Marty Sweet" <msweet....@gmail.com> wrote: > > > > > Hi Guys, > > > > > > I have just upgraded to 4.2.0 from 4.1.1 and am having some issues with > > the > > > SystemVMs. > > > I understand that we are meant to upgrade to the new system image? > Using > > > the script in the 'Prepare systemvm' documentation I did this with no > > > avail, editing the database to suit what I think would work has also > not > > > worked. > > > > > > Restoring a backup, I now have my original 4.1.1 acton systemvm > > templates. > > > What steps should I take to launch a systemVM successfully? > > > > > > The upgrade documentation is pretty lacking in this respect, and just > > says > > > restart the systemvms, with no reference to upgrading the image. > > > > > > I also note that the new systemvms don't seem to be mounting the NFS > and > > > are instead using /usr/share/cloudstack-common/vms/systemvm.iso. > > > > > > Opening a VNC session to the VM, shows the following messages: > > > Cannot assign requested address: make_sock: could not bind address > > > dnsmasq: unknown interface eth0 > > > dnsmasq apache2 ... failed! > > > > > > My MD5 sum for the CD boot file is below and is consistant across all 4 > > > nodes: > > > 092a299932bda93cc522b1c3e56af4a8 > > > /usr/share/cloudstack-common/vms/systemvm.iso > > > > > > > > > Many thanks, > > > Marty > > > > > >
