Ability to add custom disk offer to data disk (created from multi-disk template)

[Doni7722]

ISSUE TYPE

• Improvement Request

COMPONENT NAME

API, UI

CLOUDSTACK VERSION

4.11.2

CONFIGURATION

N/A

OS / ENVIRONMENT

N/A

SUMMARY

With CS 4.11.2. we are able to create templates based on Multi-disks OVA file (see #2146). If you launch a VM based on this template you need to specify a disk offer per disk you would like to create. The disk offer for the data disks (only data disks are affected) are not allowed to be custom.

STEPS TO REPRODUCE

Over API:

deploy virtualmachine templateid=(ID of the MultiOVA template) name=(VM NAME) displayname=(DISPLAYNAME) zoneid=(ZONEIID) serviceofferingid=(SERVICE OFFERING ID ie small, medium,etc) datadiskofferinglist[0].datadisktemplateid=(this is the template UUID for the first data disk) datadiskofferinglist[0].diskofferingid=(ID of a disk offering) 

Make sure that the disk offer ID is from a disk offer which allows to be a custom value.

EXPECTED RESULTS

VM should be created and CS should allow us to specify a custom size for the data disk

ACTUAL RESULTS

You will retrieve the following error message if used a custom disk offer:

Error: (HTTP 431, error code 4350) Invalid disk offering id X specified for datadisk template X. Custom Disk offerings are not supported for Datadisk templates

[rohityadavcloud]

Custom disk offering for multi-disk ova is not supported because the ova template already may have a data disk/template with fixed size. A custom disk offering would mean, if the provided value is smaller then the data disk is shrunk otherwise expanded. @nvazquez can you share your view?

[Doni7722]

Hi @rhtyd I see your point but this way we would need to create all kind of disk offerings. What I mean is, a data disk can come with a size of 85GB and the next one comes with 135GB and so on. So in this case we would first need to create a disk offering which matches the exact size of the disk and after that we would be able to import the template. What I was thinking is that you can choose custom size but define there the exact size of the data disk, so it's not needed to create all the time a new offering for it if none does match. What would be required is to add a hint or something inside the UI and write "please define the disk size of the data disk in the OVA" or something like that.

[nvazquez]

@Doni7722 @rhtyd I think this is a nice improvement we can work on including for the next major release

[andrijapanicsb]

I don't think we'll have time for this one, moving it to 4.15 milestone

[shwstppr]

@nvazquez this should fixed/changed with 4.15.0.0 vsphere advanced capabilities changes?

[DaanHoogland]

@Doni7722 can you check with 4.14 if @shwstppr is correct?

[Doni7722]

@DaanHoogland the vsphere advanced capabilities change comes with 4.15. I can check it when there is a RC available.

[DaanHoogland]

sorry, i meant 4.15 indeed. the final RC is GA now.

[rohityadavcloud]

@Doni7722 can you test latest 4.15.1? We've moved to a new deploy-as-is feature which is more streamlined with vSphere.

[DaanHoogland]

ping @Doni7722 ?

[Doni7722]

Hi @rhtyd & @DaanHoogland sorry for the (very) late response... I had a look at the deploy-as-is feature and I can tell you that it works!

However I would still like to discuss the current "solution" of this new features as it does not cover all issues:

1. with the deploy-as-is feature CloudStack does not respect the kind of the disks but creates all disks inside the OVA as root disks (root-123-0, root-123-1, root-123-2, etc.) which is wrong as those are data disks and not root disks. I was still not able to finish all tests but this may could lead to other problems as well.
2. root disks are always mapped to the service offering in the matter of disk offering. So if you define your root disk to run on a good storage tier but would like to have you data disks on fast/better storage tier you will not be able as root-disks can not change storage tiers (at least not by users).
3. I was unable to create a disk backup (snapshot) from a single disk. So looks like this is broken if there are multiple root-disks. A normal VM snapshot was successful.
4. deploy-as-is did not map the OS correctly (however that's not a big thing as it can be manually corrected)

As I already said the deploy-as-is method does work and all data disks were assigned correctly and were read- & writable. It does come with some cons however were I think that the biggest would be that we are unable to assign a different disk offering or storage tiers to those data-disks as this would be the need for so many use cases (DB data disks, Archive data-disks, etc.). This was not the case under #2146 as here we could assign the correct storage tier but were just not flexible for the disk size.

[DaanHoogland]

@Doni7722 , thanks for the evaluation of the feature.
I think your points 2 and 3 merrit separate requests.
Point 1 should not be a problem so please keep an eye out if it does.
As for 4, what did you observe? The OVA's mapping should be better than what cloudstack can make of it. Do you mean it wasn't honoured?
regards,

[Doni7722]

@DaanHoogland concerning point 1 - not sure if that's no problem as for example I'm also not able to re-install a VM. The message says that re-installing a VM from the template will only change the root disk but will not touch data disks. However in this case we have mulitple root disks. After trying to re-install the VM it just run into an error and the VM cannot be started.
Point 4: It was a CentOS 7 VM which was mapped to other linux 64-bit - however I guess that's the smaller issue here as this can be corrected without issues.

[DaanHoogland]

Ok @Doni7722 I'm not sure if the problem of .1 is that the disks are all cosidered root, or for instance a VM with multiple root disks should be able to be re-installed, but not being able to is worth an issue ticket.
Was the CentOS7 template declared as CentOS 7 in the OVA? if so it is a bug in cloudstack, if not, it should.