tsinik-dw commented on issue #5915:
URL: https://github.com/apache/cloudstack/issues/5915#issuecomment-1062926347
Hi @nvazquez,
it worked!...
I made multiple tests and got several error messages which I am going to
list at the end of this report.
Please excuse my gigantic post :-) but the information may be helpful.
First, the steps that led to a successful volume migration.
1. Create Compute Offering (CO 1) without tags
2. Create VM using CO 1
3. Alter CO 1 DB entry in `disk_offering table` (set min_iops, max_iops,
hv_ss_reserve)
4. Alter the VM's volume DB entry in the `volumes` table (set min_iops,
max_iops, hv_ss_reserve)
At this point UI doesn't give the Solidfire storage as an available option
for volume migration, so
5. in CMK I execute the following:
` migrate volume storageid=2514b65e-b231-4b2e-932c-c897f2df7c79
volumeid=83bc0063-b73c-4581-8bd0-c7e59d34263e livemigrate=true`
and the volume gets migrated giving the following output;
~~~
{
"volume": {
"account": "admin",
"created": "2022-03-09T10:14:51+0200",
"destroyed": false,
"deviceid": 0,
"diskioread": 0,
"diskiowrite": 0,
"diskkbsread": 0,
"diskkbswrite": 0,
"displayvolume": true,
"domain": "ROOT",
"domainid": "747b2d33-8031-11ec-9ad0-ba21ccf13580",
"hypervisor": "XenServer",
"id": "83bc0063-b73c-4581-8bd0-c7e59d34263e",
"isextractable": false,
"maxiops": 4000,
"miniops": 1000,
"name": "ROOT-133",
"path": "c71023ba-d338-4290-8b1c-8a314a662bc2",
"provisioningtype": "thin",
"quiescevm": false,
"serviceofferingdisplaytext": "CO 1 Desc",
"serviceofferingid": "a1c6f819-c653-406e-8a86-4b39ed4b744a",
"serviceofferingname": "CO 1",
"size": 5368709120,
"state": "Ready",
"storage": "SOLIDFIRE",
"storageid": "2514b65e-b231-4b2e-932c-c897f2df7c79",
"storagetype": "shared",
"tags": [],
"templatedisplaytext": "Centos 7",
"templateid": "7bdc9edc-3afd-42e3-a23c-150ec4b58afa",
"templatename": "Centos 7",
"type": "ROOT",
"virtualmachineid": "3e28031a-5019-4459-a19b-6fa0b73c4373",
"vmdisplayname": "VM-XCP-2",
"vmname": "VM-XCP-2",
"vmstate": "Running",
"zoneid": "97299276-7257-4b79-a1df-51cf89c402e2",
"zonename": "ZONE1"
}
}
~~~
For sake of completeness, I attach the corresponding management log entries
[nv_vol_migr_to_managed_cmk_success.txt](https://github.com/apache/cloudstack/files/8214811/nv_vol_migr_to_managed_cmk_success.txt)
Now, some remarks and errors:
1. If I use the `newdiskofferingid` option the migration does not work, even
if the old and new disk offerings are exactly the same and with no tags.
Error message:
~~~
(noc-dev) 🐱 > migrate volume storageid=2514b65e-b231-4b2e-932c-c897f2df7c79
volumeid=58a087e5-eab5-4588-acd2-b48d27895e8b livemigrate=true
newdiskofferingid=b89a1d02-c775-470c-bd13-2a655d74cd49
{
"accountid": "d0987ed7-8031-11ec-9ad0-ba21ccf13580",
"cmd":
"org.apache.cloudstack.api.command.admin.volume.MigrateVolumeCmdByAdmin",
"completed": "2022-03-09T11:37:41+0200",
"created": "2022-03-09T11:37:41+0200",
"jobid": "3dc0fe30-8e9a-4911-8bcc-a428adda4fcf",
"jobprocstatus": 0,
"jobresult": {
"errorcode": 431,
"errortext": "The disk offering informed is not valid
[id=b89a1d02-c775-470c-bd13-2a655d74cd49]."
},
"jobresultcode": 530,
"jobresulttype": "object",
"jobstatus": 2,
"userid": "d09ca276-8031-11ec-9ad0-ba21ccf13580"
}
🙈 Error: async API failed for job 3dc0fe30-8e9a-4911-8bcc-a428adda4fcf
~~~
2. No matter the values and tag combinations in disk offerings, if the
`newdiskofferingid` option is used the error message is the same as above
3. If the initial compute offering uses a disk offering with a tag, then I
have to manually add this tag to the managed storage in `stoprage_pool_tags`.
Otherwise, I got the following:
~~~
(noc-dev) 🐱 > migrate volume storageid=2514b65e-b231-4b2e-932c-c897f2df7c79
volumeid=c925d774-1d1a-40b9-af62-ba21ad001f08 livemigrate=true
{
"accountid": "d0987ed7-8031-11ec-9ad0-ba21ccf13580",
"cmd":
"org.apache.cloudstack.api.command.admin.volume.MigrateVolumeCmdByAdmin",
"completed": "2022-03-09T11:56:59+0200",
"created": "2022-03-09T11:56:59+0200",
"jobid": "b8535cbb-e996-452d-bd37-97e1057653b1",
"jobprocstatus": 0,
"jobresult": {
"errorcode": 530,
"errortext": "Migration target pool [null, tags:sf,solidfire] has no
matching tags for volume [ROOT-135, uuid:c925d774-1d1a-40b9-af62-ba21ad001f08,
tags:nfsPrimaryXCP]"
},
"jobresultcode": 530,
"jobresulttype": "object",
"jobstatus": 2,
"userid": "d09ca276-8031-11ec-9ad0-ba21ccf13580"
}
🙈 Error: async API failed for job b8535cbb-e996-452d-bd37-97e1057653b1
~~~
I guess, in a production environment, a `proxy `compute offering must be
used with an e.g. `migration` tag so as to not change the normal initial
compute offering and add this same tag to the destination storage
4. Finally, after migration, I changed the Compute Offering to the correct
one (with the appropriate tag) and everything went smooth.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
