cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marty Sweet <msweet....@gmail.com>
Subject Re: 4.2.0 Upgrade and System Templates (KVM - Ubuntu 12.04)
Date Sun, 27 Oct 2013 10:40:45 GMT
Thanks Kelcey, that worked a treat!

Do you know of any plans to update the official documentation?

Marty


On Sun, Oct 27, 2013 at 1:16 AM, kelcey@backbonetechnology.com <
kelcey@backbonetechnology.com> wrote:

> 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" <shadowsor@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.dev@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 <shadowsor@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.dev@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
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message