Vim method missing


#1

Hi,

After upgraded from Boninik to Darga-1 appliance, I tested on my old adddisk_to_vm code which I took reference from the CloudFormPOC that worked well previously.

In this case, when I worked on negative testing, upon executing the following codes, I got a “VimFault”“method_missing” that was triggered by "vm_storage"error:
prov = $evm.root[‘mig_provision’]
vm = prov.vm
vim_vm = vm.object_send( ‘instance_eval’, ‘with_provider_object( | vimVM | return vimVM }’ )
vim_vm.addDisk( “[#{vm.storage_name}]”, size*1024)

I appreciate if someone could point me to how vm.addDisk works? Is the request tap on VMware API? Do we need VDDK for this to work? Thanks.

Cheers,
Casius.


#2

@blomquisg can you review this question from @casius and forward to a SME if necessary.


#3

@casius

I would suggest using the add_disk method that is exposed from automate instead of the method you are using.

You may also want to test against Darga-2


#4

Hi @gmccullough. May I know how can this method be called from MIQ lifecycle in “Automate”? Thanks!


#5

Assuming you have a handle to the VM object like you show above:

prov = $evm.root['mig_provision']
vm = prov.vm

The call would be:

vm.add_disk( "[#{vm.storage_name}]", size*1024)

Just wanted to point out that this is just supported on VMware provider VMs at the moment.


#6

@gmccullough, thanks for your response. At the moment, when I initiated vm.addDisk(“storage_name”, size), the ruby method add_disk() in apps/models/vm_or_template/operations/configuration.rb will be called. As I am new to ruby on rails, I am wondering how the methods in lifecycle state could correctly locate the right add_disk method. I do also noticed that the example given used vm.add_disk() instead of vm_addDisk(). Is this the one that make the difference when we call a method in /lib over one in /app/…/… ? Thanks.


#7

The initial logic you reference is directly accessing the VimVM object which is calling the addDisk method here:

The add_disk call from the automate service model will call this add_disk method:

Which then calls raw_add_disk and routes the call to vm_add_disk on the provider. Ultimately they both end up calling the same MiqVimVM.rb method.

The big difference is that the sync_or_async_ems_operation method from automate will ensure the work is routed to the proper worker and zone where the appliance is configured to talk to the provider.

Also the object_send( 'instance_eval' logic is hacking around the automate service model and is not a recommended approach.


#8

Hi @gmccullough,

I tested on the suggested method add_disk(). I observed that when disks was not successfully added in VMware, errors were not shown on MIQ. In fact, no exceptions were thrown in MIQ, which may not be ideal as errors would then only be discovered much later. Thanks for your response.

Cheers,
Casius.


#9

The add_disk method takes an optional third parameter where you can specify a synchronous flag for the operation.

You might want to try running with that flag set to true:

vm.add_disk( "[#{vm.storage_name}]", size*1024, :sync => true)


#10

Hi @gmccullough,

Currently add_disk method adds a new independent disk. I am wondering to create a disk where diskMode is “non-independent”? I tried the following method but it does not work:
vm.add_disk( “[#{vm.storage_name}]”, size*1024, {:sync=> true, :dependent => true} )?

Your help is much appreciated. Thanks!

Cheers,
Casius.


#11

The automate add_disk method is only passing along disk_name and disk_size as you can see here:

However, the backend method supports passing a few additional properties: :thinProvisioned, :dependent and :persistent

See here:

Please open a git issue and we can work on passing the additional hash values to support setting the other fields.


#12

Is there a way to call that back-end method from the Automate Engine?

I’m new to MIQ and don’t quite grasp when or how the method that calls raw_add_disk() would be accessed if not from the AE.

I am trying to thinly provision a disk from an Automate Method and it looks like Issue #12488 hasn’t see any movement.


#13

@switchboard.op Thanks for the update, the issue was actually resolved but the PR did not get linked to the issue but to a bugzilla ticket so there was no update.

I have associated the issue to merged PR #14350 and closed the issue.

Thanks again.


#14

Thank you for the info @gmccullough!

Unfortunately it looks like the version of CloudForms we’re running is based on Darga and doesn’t have these changes rolled in.

Thankfully it’s only three lines. :grin:


#15

Instead of pulling in upstream code and doing a rake compile, I just called sync_or_async_ems_operation() directly:

# Get vm object
vm = $evm.root['vm']

# Get the size for the new disk from the root object
size = $evm.root['dialog_size'].to_i
size_in_mb = size * 1024

# Add disk to a VM
unless size.zero?
  $evm.log(:info, "Creating a new #{size}GB disk on Storage: #{vm.storage_name}")

  # In CFME 5.8 this should work
  # vm.add_disk("[#{vm.storage_name}]", size_in_mb, thin_provisioned: true)

  # This is a hack to make thin provisioning from AE work in CFME 5.7
  vm.sync_or_async_ems_operation(true, "add_disk", ["[#{vm.storage_name}]", size_in_mb, thin_provisioned: true])
end

exit MIQ_OK