daphnissov
Immortal
Immortal

vRA 7.2 cannot edit disk size of a new disk defined in a blueprint

Jump to solution

We're noticing something that appears to be a bug with vRA 7.2. In a Windows machine blueprint where an additional disk has been defined (but does not exist on the template) in the blueprint, a user cannot change the size of that disk at request time HOWEVER they can change both the drive letter and the drive label. For example, create a Windows blueprint with a disk (id 1) with size of 10, drive letter of E, and drive label of "DATA". When a user requests this blueprint, they can navigate to the Storage tab of the machine, select the new disk (with size 10, etc.), and click the pencil icon to edit any of the previously-defined values. When the resultant machine is built, the size remains the same as it was in the blueprint, but drive letter and drive label both reflect the changes at time of request. I see no other possibility than this being a bug. Is anyone observing this behavior is different where size does accept the user's request?

Tags (3)
1 Solution

Accepted Solutions
duddukurir
Contributor
Contributor

We fixed this in 7.3 and the disks added during authoring time can be edited during request time.

The machine gets provisioned with the new disk size as long as the total disks size is less than the max storage specified.

The default clone disk which comes with the template cannot be edited.

View solution in original post

13 Replies
daphnissov
Immortal
Immortal

I stated "a Windows machine blueprint" previously, however the blueprint type and guest OS appears irrelevant; it happens the same way with a Linux blueprint. GrantOrchardVMware‌, can you or anyone else independently validate this is happening?

0 Kudos
GrantOrchardVMw
Commander
Commander

A little more detail may be required.

The blueprint will need a min/max value. The sum total of all storage is bounded by that. Disk 0 (which you don't mention, but I'll address for clarity) can't be resized.

I'll take a look at this in my environment for you.

Grant http://grantorchard.com
0 Kudos
daphnissov
Immortal
Immortal

All you say is, of course, correct and I am aware of these natural constraints. The sum total is being taken into consideration here, and the increases imposed at request time fall well beneath that amount. Disk0 cannot, as you point out, be resized nor is it being attempted. Disk1 (or DiskN) is the only one attempted to be increased (not decreased), yet is not taking. I'm testing this behavior in a vRA 7.0.1 environment, and it appears the behavior of the form's interactive abilities are different, so this could be a regression. I'll have more information shortly.

0 Kudos
daphnissov
Immortal
Immortal

vRA 7.0.1 has a known issue whereby disks cannot be edited at request time. This has been documented in the release notes for vRA 7.1:

Resolved Issues

  • In vRealize Automation 7.0, custom property names are case-sensitive
  • IP address for an Amazon Web Services virtual machine is unavailable in the catalog API after you provision a machine
  • When you upgrade a replica server from vRealize Automation 7.0 to 7.0.1, the replica server must be in sync with the master server. If the replica server is not in sync, the PostgreSQL service on the replica cannot start, and the upgrade fails.
  • Edge fails to allocate virtual machine when network custom property is specified at the blueprint level
  • Unable to change disk size while requesting a machine from the catalog


It appears that vRA 7.0.1 also has the unfortunate side effect of disks getting swapped on Windows machine requests therefore rendering the deployed machine unbootable. I'm trying to locate a vRA 7.1 installation to further test this scenario, but it seems there is an established track record of difficulties in handling disk manipulation in vRA.

0 Kudos
daphnissov
Immortal
Immortal

I also tested this behavior on vRA 7.1, and while it will allow a user to edit the disk size in the request form, the deployed machine still only reflects what was configured in the blueprint.

0 Kudos
daphnissov
Immortal
Immortal

Any luck reproducing this?

0 Kudos
daphnissov
Immortal
Immortal

GrantOrchardVMware‌, any luck confirming this behavior?

0 Kudos
GrantOrchardVMw
Commander
Commander

Apologies, I forgot to add this to my to do list!

I've just taken a look now, and I see the same behaviour. My template has a single disk, the blueprint has a second. So, let's say Disk 0 = 1GB, Disk 1 = 1GB. I modify Disk 1 to be 2GB at request time and the machine provisions with a pair of 1GB disks.

Could you log an SR for this, and ask them to copy me onto it?

Grant http://grantorchard.com
0 Kudos
daphnissov
Immortal
Immortal

Thank you for taking the time to check, Grant. SR 17381181602 has been created and I've requested you be copied on responses.

0 Kudos
daphnissov
Immortal
Immortal

I heard back from the support engineer on the case and hopefully you've already seen the response, Grant, but for others watching or coming across this thread, the answer was this is a known issue and isn't scheduled to be fixed until after 7.3. So essentially this functionality has been broken in the entire 7.x release cycle, which is just sad.

0 Kudos
duddukurir
Contributor
Contributor

We fixed this in 7.3 and the disks added during authoring time can be edited during request time.

The machine gets provisioned with the new disk size as long as the total disks size is less than the max storage specified.

The default clone disk which comes with the template cannot be edited.

View solution in original post

robertshaw
Contributor
Contributor

I created a workflow package to use vRA event subscription to extend template disks.

I uploaded it to the VMware code site:

https://code.vmware.com/samples?id=3228

My blog post for some more details:

http://www.gimmesugar.com/?p=238

Crack open the workflows and change the disk ID from 0 to whatever disk you need if desired.

Hope this helps, it helped me. Note it resizes all the way into the VM - Windows OS.

Thanks, Rob

daphnissov
Immortal
Immortal

Obviously late here but that's cool, Rob, and thanks for sharing.

0 Kudos