Hey andrija, your suggestions go into the same direction i was guessing. Will test it thoroughly after christmas holidays.
And i like "manually change to some new one - and later via UI"! Had the same plan! All the best wishes for christmas! Greetings, Melanie Gesendet mit BlueMail Am 20. Dez. 2018, 17:27, um 17:27, Andrija Panic <andrija.pa...@gmail.com> schrieb: >Hi Melani, > >for root volumes - I'm pretty sure it's like following - sorry long >copy/paste - here we examine sample VM (which we really did migrate >from >NFS/CEPH to SolidFire) >(comments after code below...) > >mysql> select name,service_offering_id from vm_instance where >uuid="5525edf1-94d7-4678-b484-a3292749c08f"; >+--------------+---------------------+ >| name | service_offering_id | >+--------------+---------------------+ >| VM-XXXXXXXXX | 837 | >+--------------+---------------------+ >1 row in set (0.01 sec) > >mysql> select name,disk_offering_id from volumes where instance_id in >(select id from vm_instance where >uuid="5525edf1-94d7-4678-b484-a3292749c08f") and name like "ROOT%"; >+----------+------------------+ >| name | disk_offering_id | >+----------+------------------+ >| ROOT-226 | 837 | >+----------+------------------+ >1 row in set (0.00 sec) > > >mysql> select name,type,tags from disk_offering where id=837; >+----------------------+---------+------------+ >| name | type | tags | >+----------------------+---------+------------+ >| 4vCPU-8GB-SSD-STD-SF | Service | SolidFire1 | >+----------------------+---------+------------+ >1 row in set (0.00 sec) > >mysql> select cpu,speed,ram_size from service_offering where id=837; >+------+-------+----------+ >| cpu | speed | ram_size | >+------+-------+----------+ >| 4 | 2000 | 8192 | >+------+-------+----------+ > >So here you see both service offering (compute offering for user VMs, >or >really service offering for system VMs) AND the disk offering (ROOT) >have >same id of 837 (single offering that we examine here). > >So it's should be enough to just >- change the disk_offering_id in the volumes table (for specific, >migrated >root - to point to some offering that targets new storage (by storage >tags) >- and later again change properly via UI//API to correct one >- change service_offering_id in vm_instance table (for specific VM >whose >ROOT volume was migrated) >-these 2 above needs to match obviously.. > >Later when you change via UI/API the to correct/exact Compute Offering >the >way you like it - make sure that both tables are updated accordingly >with >new ID - in ACS 4.8 only service_offering_id (vm_instances table) was >updated to point to new service offering, while disk_offering_id in >"volume" table was NOT updated - we had an in-house patch for this to >update this one as well... > >Above I always say "manually change to some new one - and later via UI" > - >in order to generate proper usage records for final offering chosen - >otherwise you can target final offering directly with DB edit...) > >Hope I did not confuse you even more :) > >Cheers >andrija > > > >On Thu, 20 Dec 2018 at 14:29, Melanie Desaive ><m.desa...@heinlein-support.de> >wrote: > >> Hi Andrija, >> >> I tested your suggestion and they worked perfectly for data-volumes. >> >> Now I am trying to figure out how to change storage tags for >> root-volumes of VMs and SystemVMs. >> >> For the root-volumes of user VMs the storage tag seems to come from >the >> service offering, I did not find any relationships to the table >> disk_offering up to now. Still I am not 100% shure through which >fields >> the relationship is defined, and continue researching. >> >> For the root-volumes of the system-VMs the easiest way to change >storage >> tags seems to define new offering and then destroy/redeploy... >> >> If you like I will summarize my knowledge about this issue when I am >> through with the task.. >> >> Greetings, >> >> Melanie >> >> >> >> Am 13.12.18 um 19:58 schrieb Andrija Panic: >> > Hi Melanie, >> > >> > I did change it, yes (tags on existing offerings) and no need to >restart >> > mgmt, just I once had to wait for a minute or two, but Im sure it >was me >> > messed up something at that specific moment. >> > >> > Tags are evaluated during creation of the volume only (and >obviously when >> > changing offering as you can see) and not relevant later for the >volume - >> > vs. i.e. cache mode (writeback etc.) which is read during starting >VM >> > (attaching volume to VM in boot process). >> > >> > Let me know if I can help more. >> > >> > Cheers >> > >> > On Thu, Dec 13, 2018, 18:41 Melanie Desaive < >> m.desa...@heinlein-support.de >> > wrote: >> > >> >> Hi andrija, >> >> >> >> thanks a lot for your answer. >> >> >> >> Indeed is absolutely sufficient for me to know that I may change >> >> disk_offering_id for a volume. I would assume it is not necessary >to >> shut >> >> down/restart the VM or restart management service, but will try >> tomorrow. >> >> >> >> I will figure out a suitable path to migrate the volumes to their >> >> destination pools and also change the offering to those with the >desired >> >> tags that way. Absolutely ok for me to do it in two or more steps. >> >> >> >> Anyone ever changed disk_offering.tags manually? >> >> >> >> Anyway, happy to see a solution for my task and looking forward to >try >> it >> >> out tomorrow. >> >> >> >> Greetings, >> >> >> >> Melanie >> >> >> >> Gesendet mit BlueMail >> >> >> >> Am 13. Dez. 2018, 17:32, um 17:32, Andrija Panic < >> andrija.pa...@gmail.com> >> >> schrieb: >> >>> Hi Melanie, >> >>> >> >>> when moving volume to new storage, when you want to change disk >> >>> offering >> >>> (or compute offering for ROOT disk...), ACS doesn't allow that - >it >> >>> lists >> >>> only offerings that have same tag as current offering (not >good...) >> >>> >> >>> We have inhouse patch, so that you CAN do that, by making sure to >list >> >>> all >> >>> offergins that have TAG that matches the TAG of the new >destination >> >>> pool of >> >>> the volume (hope Im clear here). >> >>> >> >>> All volumes read tag from their offering - so just either change >> >>> disk_offering_id filed for each moved/migrated volume to point >to same >> >>> sized offering on new storage - and then normally change it once >more >> >>> via >> >>> UI to a new once etc - or manualy change to smaller disk offering >(DB >> >>> edit) >> >>> and later via UI/API to correct (same size) disk offering (or >bigger if >> >>> you >> >>> want to really resize) >> >>> >> >>> I can try to share a patch in a non-developer, copy/paste way - >in case >> >>> you >> >>> want to patch your ACS to support this (as explained at the >begining of >> >>> the >> >>> email...) >> >>> >> >>> Hope that helps >> >>> >> >>> Cheers >> >>> >> >>> On Thu, 13 Dec 2018 at 13:50, Melanie Desaive >> >>> <m.desa...@heinlein-support.de> >> >>> wrote: >> >>> >> >>>> Hi all, >> >>>> >> >>>> we are currently reorganizing our SAN Setup and I would like to >> >>>> introduce new storage tags on my existing volumes. >> >>>> >> >>>> I was naively assuming to simply change the tags or offering by >GUI >> >>> or >> >>>> API calls. >> >>>> >> >>>> Does not seem to work. Only way to change the tags, seems to be >by >> >>> using >> >>>> a new disk offering, which is denied, when the tags between old >and >> >>> new >> >>>> offering differ. :( Or am I missing something? >> >>>> >> >>>> I had a look into the cloud database, and the storage tags, seem >to >> >>> be >> >>>> only stored in >> >>>> >> >>>> disk_offering.tags >> >>>> and >> >>>> storage_pool_tags.tag >> >>>> >> >>>> Would it be a valid option for me to update disk_offering.tags >by SQL >> >>> to >> >>>> the desired value or could that break some deeper logic? >> >>>> >> >>>> Or is there even a better way to change the storage tags for >existing >> >>>> volumes. (With or without downtime for the VMs) >> >>>> >> >>>> Looking forward to any advice! >> >>>> >> >>>> Greetings, >> >>>> >> >>>> Melanie >> >>>> -- >> >>>> -- >> >>>> >> >>>> Heinlein Support GmbH >> >>>> Linux: Akademie - Support - Hosting >> >>>> >> >>>> http://www.heinlein-support.de >> >>>> Tel: 030 / 40 50 51 - 0 >> >>>> Fax: 030 / 40 50 51 - 19 >> >>>> >> >>>> Zwangsangaben lt. §35a GmbHG: >> >>>> HRB 93818 B / Amtsgericht Berlin-Charlottenburg, >> >>>> Geschäftsführer: Peer Heinlein -- Sitz: Berlin >> >>>> >> >>>> >> >>> >> >>> -- >> >>> >> >>> Andrija Panić >> >> >> > >> >> -- >> -- >> >> Heinlein Support GmbH >> Linux: Akademie - Support - Hosting >> >> http://www.heinlein-support.de >> Tel: 030 / 40 50 51 - 0 >> Fax: 030 / 40 50 51 - 19 >> >> Zwangsangaben lt. §35a GmbHG: >> HRB 93818 B / Amtsgericht Berlin-Charlottenburg, >> Geschäftsführer: Peer Heinlein -- Sitz: Berlin >> >> > >-- > >Andrija Panić
