HI Rafael, Andrei, that sounds wonderful !
@Andrei , we had exactly the same situation, but we have done internal code changes in ACS 4.5 /4.8 (never committed back to community unfortunately... ), so after migration is done, and we want to change offering, the list of Offerings is NOT matching the TAG of the volume only (so no error like you still get) - the list of offerings is shown depending on the CURRENT POOL of the volume - we match the tags of any existing offerings vs tags on the CURRENT POOL where volume exist - so only matching offerings (targeting new pool...) are shown. (we had CEPH/NFS as soruce with "deprecated" tag and all ceph/nfs offerings deleted/inactive, and destination pool was SoldiFire with new storage tag and a set of Compute/Disk offerings with tag "solidfire") In our case this means - volume was on CEPH and had CEPH offering - after we migrate offering to solidfire, only offering showing tag that matches the tags of the current pool (Solidfire), are shown... hope I was clearn with this long explanation :) For volumes specifically, storage tags are (to my knowledge) only evaluated when you deploy VM (root volume) or create data volume - you can see this in logs when ACS search for pool having this and that tag... Once resource (volume) is DEPLOYED (exists), it works as it is (as Rafael explained), and Offerings are ignored for that matter - BUT interestingly enough - some properties (i.e. min/max iops aka storage QoS or KVM io throtling aka. hypervisor QoS) are inherited and copied over from offering to actual volumes table/row in DB (for that specific volume...) when volume is being created, etc - .while some properties like "cache_mode" (write-back or not) still read/applied on the fly from the actual Offering... so it's mix and match :) I might be able to provide code that did this new way of matching tags, in case it would be interesting (but no human power to commit anything/PR, I can just share with Rafael or someone who is willing to push it upstream) Rafael ? Cheers On Thu, 11 Oct 2018 at 14:16, Rafael Weingärtner < rafaelweingart...@gmail.com> wrote: > What you described seems to be the new feature introduced with > https://issues.apache.org/jira/browse/CLOUDSTACK-10323 and > https://issues.apache.org/jira/browse/CLOUDSTACK-10240. However, this > feature should have been introduced only in master (4.12). I was not able > to find those commits in 4.11.1.0 though. Maybe ACS was already allowing > the movement between shared storages with different tags?. Anyways, the > block of code used to do this process has been totally re-written (now > everything is unit-tested). It is only in 4.12 though… It will also allow > placement overridden (ignoring storage tags and storage types), and also it > will allow replacing the disk offering while migrating the disk to a > new/different storage system. > > To answer your questions. > > > My question is how did the vm start? Did cloudstack ignore the storage > > tags or is there another reason? > > > Once the volume is already placed somewhere, CloudStack any extra checking > (if it can use the volume as is). Therefore, it only moves on with the > normal VM start. > > > On Thu, Oct 11, 2018 at 8:46 AM Andrei Mikhailovsky > <and...@arhont.com.invalid> wrote: > > > Hello, > > > > I have recently tried to migrate a volume from one rbd storage pool to > > another. Have noticed a possible issue with the migration logic, which I > > was hoping to discuss with you. > > > > My setup: ACS 4.11.1.0 > > Ceph + rbd for two primary storage pools (hdd and ssd pools) > > Storage tags are used together with the Disk Offerings (rbd tag is used > > for hdd backend volumes and rbd-ssd tag is used for the ssd backend > > volumes) > > > > What I tried to do: Move a single volume from hdd pool over to the ssd > > pool. Migration went well according to the cloudstack job result. I ended > > up with a volume on the ssd storage pool. > > > > After the migration was done, I had a look at the disk service offering > of > > the migrated volume and the service offering was still the hdd service > > offering despite the volume now being stored on the ssd pool. I have > tried > > to change the disk offering to the ssd pool and had an error saying that > > the storage tags must be the same. Obviously, in my case, the storage > tags > > of the hdd and ssd pool offerings are different. I have checked the > > database and indeed, the db still has the hdd disk offering id. > > > > I have tried to start the vm and to my surprise the vm has started. From > > my previous experience and my understanding how the tags work with > storage, > > the vm should not have started. The disk offering tag of the migrated > > volume points to the hdd storage where this volume doesn't exist. So, > > starting the vm should have errors out with an error like Insufficient > > resources or something like that. > > > > So, I have a bit of an inconsistency going on with that volume. According > > to the cloudstack gui, the volume is stored on the ssd pool but has a > disk > > offering from the hdd pool and there is no way to change that from the > gui > > itself. > > > > > > My question is how did the vm start? Did cloudstack ignore the storage > > tags or is there another reason? > > > > Thanks > > > > > -- > Rafael Weingärtner > -- Andrija Panić
