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 > > >
