Re: How to upgrade cloud stack
https://www.shapeblue.com/cloudstack-upgrades-best-practices/ i.e. you are interested in parallel upgrade. i.e. you prepare your Ubuntu 18.04 servers, and later import DB to new mysql host, install acs 4.13 on new mgmt server etc. Some practice is needed here. Read the link I've sent. Best, Andrija On Wed, 6 Nov 2019, 22:15 Hakan Yıldız, wrote: > Hi everyone, > > We use cloud stack 4.9.2.0 under ubuntu 14.04. > How can I upgrade from cloud stack 4.9.2.0 under ubuntu 14.04 to cloud > stack 4.13.0 under ubuntu 1804 ? > > > > > > Thank you for your help. > > System Administrator > Hakan Yıldız > > > > YASAL UYARI: Bu elektronik posta ve onunla iletilen butun dosyalar sadece > gondericisi tarafindan almasi amaclanan yetkili gercek ya da tuzel kisinin > kullanimi icindir. Eger soz konusu yetkili alici degilseniz bu elektronik > postanin icerigini aciklamaniz, kopyalamaniz, yonlendirmeniz ve kullanmaniz > kesinlikle yasaktir ve bu elektronik postayi derhal silmeniz gerekmektedir. > SAĞLAYICI bu mesajin icerdigi bilgilerin dogrulugu veya eksiksiz oldugu > konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne > sekilde olursa olsun iceriginden, iletilmesinden, alinmasindan ve > saklanmasindan sorumlu degildir. Bu mesajdaki gorusler yalnizca gonderen > kisiye aittir ve SAĞLAYICI' nın goruslerini yansitmayabilir. > > LEGAL NOTICE: This e-mail and any files transmitted with it are > confidential and intended solely for the use of the individual or entity to > whom they are addressed. If you are not the intended recipient you are > hereby notified that any dissemination, forwarding, copying or use of any > of the information is strictly prohibited, and the e-mail should > immediately be deleted. SAGLAYICI makes no warranty as to the accuracy or > completeness of any information contained in this message and hereby > excludes any liability of any kind for the information contained therein or > for the information transmission, reception, storage or use of such in any > way whatsoever. The opinions expressed in this message belong to sender > alone and may not necessarily reflect the opinions of SAGLAYICI >
How to upgrade cloud stack
Hi everyone, We use cloud stack 4.9.2.0 under ubuntu 14.04. How can I upgrade from cloud stack 4.9.2.0 under ubuntu 14.04 to cloud stack 4.13.0 under ubuntu 1804 ? Thank you for your help. System Administrator Hakan Yıldız YASAL UYARI: Bu elektronik posta ve onunla iletilen butun dosyalar sadece gondericisi tarafindan almasi amaclanan yetkili gercek ya da tuzel kisinin kullanimi icindir. Eger soz konusu yetkili alici degilseniz bu elektronik postanin icerigini aciklamaniz, kopyalamaniz, yonlendirmeniz ve kullanmaniz kesinlikle yasaktir ve bu elektronik postayi derhal silmeniz gerekmektedir. SAĞLAYICI bu mesajin icerdigi bilgilerin dogrulugu veya eksiksiz oldugu konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne sekilde olursa olsun iceriginden, iletilmesinden, alinmasindan ve saklanmasindan sorumlu degildir. Bu mesajdaki gorusler yalnizca gonderen kisiye aittir ve SAĞLAYICI' nın goruslerini yansitmayabilir. LEGAL NOTICE: This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted. SAGLAYICI makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the information transmission, reception, storage or use of such in any way whatsoever. The opinions expressed in this message belong to sender alone and may not necessarily reflect the opinions of SAGLAYICI
Re: SystemVM Storage Tags not taken into account?
I wouldn't say this is something we do routinely, mostly to correct mistakes at the start. You could end up with problems if you deployed VMs based on an old version of a service offering, then changed tags in such a way that there was no possible location a VM could start up next time. However, with a dash of common sense it should be fine to use :) On Wed, 6 Nov 2019 at 11:52, Melanie Desaive wrote: > > Hi Richard, > > looks good. Just did an > > update network_offerings set service_offering_id = offering id> where id = > > and restarted one of the networks from this offering with cleanup. > > Comes up nicely and new tags are taken into account. > > Do you use this procedure in production to change tags and parameters > like cpus, ram? > > Could gain lots of flexibility if this is safely possible. > > Greetings, > > Melanie > > Am Montag, den 04.11.2019, 15:45 + schrieb Richard Lawley: > > There's nothing in the API or the UI. We just change it in the DB. > > > > On Mon, 4 Nov 2019 at 13:48, Melanie Desaive > > wrote: > > > Hi Richard, > > > > > > thank you for this hint. > > > > > > I had a look in the database, and yes, all Network Offeringns in > > > the > > > table network_offerings still reference the old System/Disk > > > offering > > > IDs from disk_offering/system_offering. > > > > > > Is there an intended way to change > > > "network_offerings.service_offering_id" for an existing network > > > offering? Would it be ok to update the database? Is there an API > > > call? > > > I did not find anything in the documentation. > > > > > > Kind regards, > > > > > > Melanie > > > > > > > > > > > > Am Freitag, den 01.11.2019, 09:25 + schrieb Richard Lawley: > > > > Melanie, > > > > > > > > > Maybe the procedure for resetting the System Offering for > > > > > Virtual > > > > > Routers differs from that for SSVM and CP and I missed some > > > > > point? > > > > > > > > The System Offering for Virtual Routers is not taken from the > > > > same > > > > place as SSVM/CP - it's set on the Network Offering instead, so > > > > you > > > > can have different network offerings with different system > > > > offerings. > > > > > > > > Regards, > > > > > > > > Richard > > > > > > > > On Fri, 1 Nov 2019 at 08:33, Melanie Desaive > > > > wrote: > > > > > Good morning Andrija, > > > > > > > > > > yes, I did restart mgmt. Documentation states that. > > > > > > > > > > Interestingly the documentation in > > > > > http://docs.cloudstack.apache.org/en/4.11.1.0/adminguide/service_offerings.html#changing-the-default-system-offering-for-system-vms > > > > > only mentions only resetting the unique_names for Secondary > > > > > Storage > > > > > VM > > > > > and Console Proxy VM not for the Virtual Routers in the > > > > > database. > > > > > > > > > > Maybe the procedure for resetting the System Offering for > > > > > Virtual > > > > > Routers differs from that for SSVM and CP and I missed some > > > > > point? > > > > > > > > > > Greetings, > > > > > > > > > > Melanie > > > > > > > > > > Am Donnerstag, den 31.10.2019, 17:19 +0100 schrieb Andrija > > > > > Panic: > > > > > > tried restarting mgmt after tag change? Usually not required > > > > > > but > > > > > > might be > > > > > > for systemVMs. > > > > > > > > > > > > On Thu, 31 Oct 2019, 15:21 Melanie Desaive, < > > > > > > m.desa...@mailbox.org> > > > > > > wrote: > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > I just tried to set up storage tags for System VMs, but the > > > > > > > behaviour > > > > > > > is not as expected. The deployment planner does not seem to > > > > > > > take > > > > > > > the > > > > > > > storage tag into account when deciding over the storage. > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > The only storage with the tag "SYSTEMV" ist "ACS-LUN-SAS- > > > > > > > 01' > > > > > > > with > > > > > > > id=10 > > > > > > > > > > > > > > mysql> select id,name,tag from storage_pool_view where > > > > > > > cluster_name > > > > > > > = > > > > > > > 'cluster2' and status = 'Up' and tag = 'SYSTEMVM' order by > > > > > > > name,tag; > > > > > > > +++--+ > > > > > > > > id | name | tag | > > > > > > > +++--+ > > > > > > > > 10 | ACS-LUN-SAS-01 | SYSTEMVM | > > > > > > > +++--+ > > > > > > > 1 row in set (0,00 sec) > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > I definied the tag "SYSTEVM" for the System Offering for > > > > > > > the > > > > > > > Virtual > > > > > > > Routers: > > > > > > > > > > > > > > mysql> select id,name,unique_name,type,state,tags from > > > > > > > disk_offering > > > > > > > where type='Service' and state='Active' and unique_name > > > > > > > like > > > > > > > 'Cloud.Com-SoftwareRouter' order by unique_name \G > > > > > > > *** 1. row > > > > > > > *** > > > > > > > id: 281 > > > > > > >name: System Offering For
Re: SystemVM Storage Tags not taken into account?
Hi Richard, looks good. Just did an update network_offerings set service_offering_id = where id = and restarted one of the networks from this offering with cleanup. Comes up nicely and new tags are taken into account. Do you use this procedure in production to change tags and parameters like cpus, ram? Could gain lots of flexibility if this is safely possible. Greetings, Melanie Am Montag, den 04.11.2019, 15:45 + schrieb Richard Lawley: > There's nothing in the API or the UI. We just change it in the DB. > > On Mon, 4 Nov 2019 at 13:48, Melanie Desaive > wrote: > > Hi Richard, > > > > thank you for this hint. > > > > I had a look in the database, and yes, all Network Offeringns in > > the > > table network_offerings still reference the old System/Disk > > offering > > IDs from disk_offering/system_offering. > > > > Is there an intended way to change > > "network_offerings.service_offering_id" for an existing network > > offering? Would it be ok to update the database? Is there an API > > call? > > I did not find anything in the documentation. > > > > Kind regards, > > > > Melanie > > > > > > > > Am Freitag, den 01.11.2019, 09:25 + schrieb Richard Lawley: > > > Melanie, > > > > > > > Maybe the procedure for resetting the System Offering for > > > > Virtual > > > > Routers differs from that for SSVM and CP and I missed some > > > > point? > > > > > > The System Offering for Virtual Routers is not taken from the > > > same > > > place as SSVM/CP - it's set on the Network Offering instead, so > > > you > > > can have different network offerings with different system > > > offerings. > > > > > > Regards, > > > > > > Richard > > > > > > On Fri, 1 Nov 2019 at 08:33, Melanie Desaive > > > wrote: > > > > Good morning Andrija, > > > > > > > > yes, I did restart mgmt. Documentation states that. > > > > > > > > Interestingly the documentation in > > > > http://docs.cloudstack.apache.org/en/4.11.1.0/adminguide/service_offerings.html#changing-the-default-system-offering-for-system-vms > > > > only mentions only resetting the unique_names for Secondary > > > > Storage > > > > VM > > > > and Console Proxy VM not for the Virtual Routers in the > > > > database. > > > > > > > > Maybe the procedure for resetting the System Offering for > > > > Virtual > > > > Routers differs from that for SSVM and CP and I missed some > > > > point? > > > > > > > > Greetings, > > > > > > > > Melanie > > > > > > > > Am Donnerstag, den 31.10.2019, 17:19 +0100 schrieb Andrija > > > > Panic: > > > > > tried restarting mgmt after tag change? Usually not required > > > > > but > > > > > might be > > > > > for systemVMs. > > > > > > > > > > On Thu, 31 Oct 2019, 15:21 Melanie Desaive, < > > > > > m.desa...@mailbox.org> > > > > > wrote: > > > > > > > > > > > Hi all, > > > > > > > > > > > > I just tried to set up storage tags for System VMs, but the > > > > > > behaviour > > > > > > is not as expected. The deployment planner does not seem to > > > > > > take > > > > > > the > > > > > > storage tag into account when deciding over the storage. > > > > > > > > > > > > -- > > > > > > > > > > > > The only storage with the tag "SYSTEMV" ist "ACS-LUN-SAS- > > > > > > 01' > > > > > > with > > > > > > id=10 > > > > > > > > > > > > mysql> select id,name,tag from storage_pool_view where > > > > > > cluster_name > > > > > > = > > > > > > 'cluster2' and status = 'Up' and tag = 'SYSTEMVM' order by > > > > > > name,tag; > > > > > > +++--+ > > > > > > > id | name | tag | > > > > > > +++--+ > > > > > > > 10 | ACS-LUN-SAS-01 | SYSTEMVM | > > > > > > +++--+ > > > > > > 1 row in set (0,00 sec) > > > > > > > > > > > > -- > > > > > > > > > > > > I definied the tag "SYSTEVM" for the System Offering for > > > > > > the > > > > > > Virtual > > > > > > Routers: > > > > > > > > > > > > mysql> select id,name,unique_name,type,state,tags from > > > > > > disk_offering > > > > > > where type='Service' and state='Active' and unique_name > > > > > > like > > > > > > 'Cloud.Com-SoftwareRouter' order by unique_name \G > > > > > > *** 1. row > > > > > > *** > > > > > > id: 281 > > > > > >name: System Offering For Software Router - With > > > > > > Tags > > > > > > unique_name: Cloud.Com-SoftwareRouter > > > > > >type: Service > > > > > > state: Active > > > > > >tags: SYSTEMVM > > > > > > 1 row in set (0,00 sec) > > > > > > > > > > > > -- > > > > > > > > > > > > But when I redeploy a virtual Router the deployment planner > > > > > > takes > > > > > > all > > > > > > storages into account. :( > > > > > > > > > > > > The log saies explicitely "Pools matching tags..." and > > > > > > lists > > > > > > several > > > > > > other pools. > > > > > > What do I miss? > > > > > > > > > > > > -- > > > > > > ClusterScopeStoragePoolAllocator looking for storage
Re: host alert
Great, cheers. On Wed, 6 Nov 2019 at 08:36, Munjo Jung wrote: > Hello Andrija, > Thank you so much for your quick reply. And the issue has been solved. > The root cause was DB error. There were a storage_pool and its related data > duplicated on DB. > after deleting storage pool id, kvm hosts have recovered their status 'up' > from 'alert'. > I also restarted libvirt and cloudstack agent as you recommended. > Thanks, > > MJ > > On 2019/11/05 16:17:18, Andrija Panic wrote: > > Hi > > > > Before the steps below, I suggest (since your whole rack is affected...) > to > > verify via telnet "telnet 8250" -that your mgmt > > server is reachable - confirm that there is no connectivity issue on IP > > level (firewall and such). > > > > Then, try the following: > > - stop cloudstack agent > > - restart libvirt (make sure it's restarted, I've seen cases when libvirt > > would not restart due to being stuck etc - confirm that the process has > the > > new PID) > > - start cloudstack agent > > > > > > This will make sure your libvirt has NO pools in it (existing VMs are > still > > happily running), and CloudStack agents will connect to the management > > server and, hopefully, everything should be fine. > > > > Regards, > > Andrija > > > -- Andrija Panić
