codehaus


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to Reorganise Storage Tags


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.panic@xxxxxxxxx> 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.desaive@xxxxxxxxxxxxxxxxxxx>
>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.desaive@xxxxxxxxxxxxxxxxxxx
>> > 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.panic@xxxxxxxxx>
>> >> 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.desaive@xxxxxxxxxxxxxxxxxxx>
>> >>> 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ć