git.net

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

Re: How to Reorganise Storage Tags


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ć