VMware Aria Automation Tools

 View Only

 Aria Automation 8.16.0 writing VM template and additional vmdk files into separate dirs in /vmfs/volumes/{datastore} if we have dots in (fully-qualified) VM name

c4r80xyl1c's profile image
c4r80xyl1c posted Jun 13, 2024 05:13 AM
Background:

We are running Aria Automation 8.16.0 with vSphere 8.0u1d
We are beta testing creation of Rocky 8 VMs using Aria Automation
Our installation is relatively new and we are not Aria Automation experts

The Rocky 8 installation is included in the VMware template on a vmdk (call it OS vmdk)
We add an additional Cloud.Vsphere.Disk disk (call it App vmdk) to each VM at build time 
That additional disk is created by cloud template and as a 2nd vmdk as expected .. but ..

Activity:

Users specify servername in service broker and we use that in assembler cloud template
 - The FQDN of the host is set to the servername value (ie., myhost.mysubdom.mydom.com)
 - The name of the VM in vSphere is set to the servername value (ie., myhost.mysubdom.mydom.com)
 
Problem:
 
The problem we have is the end location of the vmdks for a given VM is 2 different dirs
- This only happens when we fully qualify servername, not when we do not fully qualify servername
- This does not happen if we create VMs manually using vSphere UI
 
i.e.,
If we create myhost.mysubdom.mydom.com
- OS vmdk is written to /var/vmfs/{datastore}/myhost.mysubdom.mydom.com/{UUID}.vmdk
- App vmdk is written to /var/vmfs/{datastore}/myhost/{UUID}.vmdk - i.e., unqualifed "FQDN"

Question:

Is anyone able to tell me how, for a new VM named myhost.mysubdom.mydom.com in vSphere,
We can make vRA / vSphere write the OS and App vmdks as follows please? -
 OS vmdk is written to /var/vmfs/{datastore}/myhost.mysubdom.mydom.com/servername-1.vmdk (or other filename)
App vmdk is written to /var/vmfs/{datastore}/myhost.mysubdom.mydom.com/servername-2vmdk (or other filename)

Other analysis:

I can't find any documentation on Cloud.Vsphere.Disk properties I might try 
There's a note about this forum on 2 (unnamed) hidden params which probably won't help
I've logged a ticket with Broadcom support which is now with Broadcom engineering   

Example:

When I pass servername = armadillo.mysubdom.mydom.com to

formatVersion: 1
inputs:
  inpAdditionalDisk1:
    type: integer
    title: Additional Disk Size
    default: 50
    minimum: 0
    maximum: 100
  inpServerName:
    type: string
    title: Server Name
  inpFlavor:
    type: string
    title: Size
    oneOf:
      - title: Small (1 x vCPU + 4 GB RAM)
        const: Small
resources:
  additionaldisk1:
    type: Cloud.vSphere.Disk
    properties:
      capacityGb: ${input.inpAdditionalDisk1}
  Cloud_vSphere_Machine_1:
    type: Cloud.vSphere.Machine
    properties:
      # attachedDisks: ${map_to_object(resource.additionaldisk1[*].id, "source")}
      attachedDisks:
        - source: ${resource.additionaldisk1.id}
      name: ${input.inpServerName}
      image: Rocky-8
      flavor: ${input.inpFlavor}
      datacenter: kb
      environment: pre-prod
      customizeGuestOs: false

I get - 

[myuser@myhost:/vmfs/volumes/vsan:{redacted}] ls -ld armadillo*
lrwxr-xr-x    1 myuser     myuser            36 Jun 14 05:33 armadillo -> {redacted1}
lrwxr-xr-x    1 myuser     myuser            36 Jun 14 05:33 armadillo.mysubdom.mydom.com -> {redacted}
 
[myuser@myhost:/vmfs/volumes/vsan:{redacted}] cd armadillo
[myuser@myhost:/vmfs/volumes/vsan:{redacted}/armadillo] ls
additionaldisk1.vmdk <--- this should be in the same dir as ..
 
[myuser@myhost:/vmfs/volumes/vsan:{redacted}/armadillo] cd ../
[myuser@myhost:/vmfs/volumes/vsan:{redacted}] cd armadillo.mysubdom.mydom.com
[myuser@myhost:/vmfs/volumes/vsan:{redacted}/armadillo.mysubdom.mydom.com] ls
armadillo.mysubdom.mydom.com-13b9728c.vswp                                           armadillo.mysubdom.mydom.com.vmx
armadillo.mysubdom.mydom.com-13b9728c.vswp.lck                                       armadillo.mysubdom.mydom.com.vmx.lck
armadillo.mysubdom.mydom.com-5828230a.hlog                                           armadillo.mysubdom.mydom.com.vmx~
armadillo.mysubdom.mydom.com.nvram                                                   vmware.log
armadillo.mysubdom.mydom.com.vmdk <--- .. this                                       vmx-armadillo.mysubdom.m-b940cec9e21{redacted}8bad104dec08787cf88ad2923abf3ecaf4ba6-1.vswp
armadillo.mysubdom.mydom.com.vmsd                                                    vra-rocky-8-64bit.mysubdom.mydom.com.scoreboard
[myuser@myhost:/vmfs/volumes/vsan:{redacted}/{redacted}]

What I want is all the files (including both vmdk's) in the same dir 
 i.e., In /vmfs/volumes/vsan:{redacted}/armadillo.mysubdom.mydom.com 
c4r80xyl1c's profile image
c4r80xyl1c

Broadcom engineering provided an update:

We were able to reproduce the issue by giving a custom name to the VM from the BP.
The '.' in the name of the VM seems to be the root cause of the issue as guessed in the recording.
We are working on the fix and we will get back to you.

Just for confirmation, from the recording it seems that the VM and its disks are placed into a VMFS datastore.
Is that correct?
[Yes, that is correct]