Thank you so much! Worked perfectly for us. Used the procedure to reorganize our storages and move quite a number of VRs to defined storage pools.
Am Mittwoch, den 06.11.2019, 12:10 +0000 schrieb Richard Lawley: > 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 > <m.desa...@heinlein-support.de> wrote: > > Hi Richard, > > > > looks good. Just did an > > > > update network_offerings set service_offering_id = <new service > > offering id> where id = <id of network_offering to change> > > > > 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 +0000 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 > > > <m.desa...@heinlein-support.de> 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 +0000 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 > > > > > <m.desa...@heinlein-support.de> 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 > > > > > > > > pool > > > > > > > > Looking for pools in dc: 1 pod:1 cluster:3. Disabled > > > > > > > > pools > > > > > > > > will > > > > > > > > be > > > > > > > > ignored. > > > > > > > > Found pools matching tags: [Pool[7|PreSetup], > > > > > > > > Pool[9|PreSetup], > > > > > > > > Pool[10|PreSetup], Pool[18|PreSetup]] > > > > > > > > ClusterScopeStoragePoolAllocator returning 3 suitable > > > > > > > > storage > > > > > > > > pools > > > > > > > > ClusterScopeStoragePoolAllocator looking for storage > > > > > > > > pool > > > > > > > > Looking for pools in dc: 1 pod:1 cluster:3. Disabled > > > > > > > > pools > > > > > > > > will > > > > > > > > be > > > > > > > > ignored. > > > > > > > > Found pools matching tags: [Pool[7|PreSetup], > > > > > > > > Pool[9|PreSetup], > > > > > > > > Pool[10|PreSetup], Pool[18|PreSetup]] > > > > > > > > ClusterScopeStoragePoolAllocator returning 3 suitable > > > > > > > > storage > > > > > > > > pools > > > > > > > > -- > > > > > > > > > > > > > > > > Kind regards, > > > > > > > > > > > > > > > > Melanie > > > > > > > >
