Bug 1473526

Summary: Unable to add dependent disk in vsphere 5.5
Product: Red Hat CloudForms Management Engine Reporter: Neha Chugh <nchugh>
Component: ProvidersAssignee: James Wong <jwong>
Status: CLOSED NOTABUG QA Contact: Milan Falešník <mfalesni>
Severity: medium Docs Contact:
Priority: medium    
Version: 5.7.0CC: bsorota, gblomqui, jfrey, jhardy, mfalesni, mkanoor, nchugh, obarenbo, tfitzger
Target Milestone: GAKeywords: Regression
Target Release: cfme-future   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-11-08 07:55:02 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: VMware Target Upstream Version:
Embargoed:

Description Neha Chugh 2017-07-21 05:36:03 UTC
Description of problem:
Unable to add dependent disk in vsphere 5.5

Version-Release number of selected component (if applicable):
Cloudforms 4.2

How reproducible:
Always

Steps to Reproduce:
1. Add the dependent disk to vmware explicitly via automate method using $vmobj.add_disk(#{$vmobj.storage_name}]", disksize.to_i*1024, {:thin => true, :dependent => true})
2. add_disk method works in vsphere client 6.5 but not in vsphere 5.5.
3. In vsphere 5.5, neither we observe any exception nor it add the dependent disk.
4. But if we navigate to VM and choose the "Reconfigure VM" option then it is able to add the dependent disk to the vsphere 5.5 

Actual results:
add_method doesnt work in vsphere 5.5.

Expected results:
add_method should work in vsphere 5.5

Additional info:

Comment 2 Greg McCullough 2017-07-21 13:49:00 UTC
Reconfigure uses a different code path as it is building a configSpec with more than just disk modifications, but it is unclear why the VMware addDisk would not work on 5.5.

Sending to the provider team for assistance.

Reconfigure method is here: https://github.com/ManageIQ/manageiq-providers-vmware/blob/b8a3de0f32405811a83e75af4544aa130bc62603/app/models/manageiq/providers/vmware/infra_manager/vm/reconfigure.rb#L110

The automate call ultimately ends up calling the VMware methods here:
https://github.com/ManageIQ/vmware_web_service/blob/master/lib/VMwareWebService/MiqVimVm.rb#L744

Any reason why this older VMware addDisk method would no longer work with VMWare 5.5?

Comment 3 James Wong 2017-07-31 20:24:34 UTC
I found this error in evm.log which indicates that the VM has no associated EMS. Can you confirm this log snippet is from the automate operation?


[----] E, [2017-04-25T11:32:06.659465 #30126:a2713c] ERROR -- : MIQ(MiqQueue#deliver) Message id: [2000004108402], Error: [VM has no EMS, unable to add disk]
[----] E, [2017-04-25T11:32:06.659674 #30126:a2713c] ERROR -- : [RuntimeError]: VM has no EMS, unable to add disk  Method:[rescue in deliver]
[----] E, [2017-04-25T11:32:06.659883 #30126:a2713c] ERROR -- : /var/www/miq/vmdb/app/models/vm_or_template/operations/configuration.rb:75:in `raw_add_disk'
/var/www/miq/vmdb/app/models/vm_or_template/operations/configuration.rb:81:in `add_disk'
/var/www/miq/vmdb/app/models/miq_queue.rb:347:in `block in deliver'
/opt/rh/rh-ruby23/root/usr/share/ruby/timeout.rb:91:in `block in timeout'
/opt/rh/rh-ruby23/root/usr/share/ruby/timeout.rb:33:in `block in catch'
/opt/rh/rh-ruby23/root/usr/share/ruby/timeout.rb:33:in `catch'
/opt/rh/rh-ruby23/root/usr/share/ruby/timeout.rb:33:in `catch'
/opt/rh/rh-ruby23/root/usr/share/ruby/timeout.rb:106:in `timeout'
/var/www/miq/vmdb/app/models/miq_queue.rb:343:in `deliver'
/var/www/miq/vmdb/app/models/miq_queue_worker_base/runner.rb:106:in `deliver_queue_message'
/var/www/miq/vmdb/app/models/miq_queue_worker_base/runner.rb:134:in `deliver_message'
/var/www/miq/vmdb/app/models/miq_queue_worker_base/runner.rb:152:in `block in do_work'
/var/www/miq/vmdb/app/models/miq_queue_worker_base/runner.rb:146:in `loop'
/var/www/miq/vmdb/app/models/miq_queue_worker_base/runner.rb:146:in `do_work'
/var/www/miq/vmdb/app/models/miq_worker/runner.rb:334:in `block in do_work_loop'
/var/www/miq/vmdb/app/models/miq_worker/runner.rb:331:in `loop'
/var/www/miq/vmdb/app/models/miq_worker/runner.rb:331:in `do_work_loop'
/var/www/miq/vmdb/app/models/miq_worker/runner.rb:153:in `run'
/var/www/miq/vmdb/app/models/miq_worker/runner.rb:128:in `start'
/var/www/miq/vmdb/app/models/miq_worker/runner.rb:21:in `start_worker'
/var/www/miq/vmdb/app/models/miq_worker.rb:343:in `block in start'
/opt/rh/cfme-gemset/gems/nakayoshi_fork-0.0.3/lib/nakayoshi_fork.rb:24:in `fork'
/opt/rh/cfme-gemset/gems/nakayoshi_fork-0.0.3/lib/nakayoshi_fork.rb:24:in `fork'
/var/www/miq/vmdb/app/models/miq_worker.rb:341:in `start'
/var/www/miq/vmdb/app/models/miq_worker.rb:270:in `start_worker'
/var/www/miq/vmdb/app/models/miq_worker.rb:150:in `block in sync_workers'
/var/www/miq/vmdb/app/models/miq_worker.rb:150:in `times'
/var/www/miq/vmdb/app/models/miq_worker.rb:150:in `sync_workers'
/var/www/miq/vmdb/app/models/miq_server/worker_management/monitor.rb:52:in `block in sync_workers'
/var/www/miq/vmdb/app/models/miq_server/worker_management/monitor.rb:50:in `each'
/var/www/miq/vmdb/app/models/miq_server/worker_management/monitor.rb:50:in `sync_workers'
/var/www/miq/vmdb/app/models/miq_server/worker_management/monitor.rb:22:in `monitor_workers'
/var/www/miq/vmdb/app/models/miq_server.rb:346:in `block in monitor'
/var/www/miq/vmdb/gems/pending/util/extensions/miq-benchmark.rb:11:in `realtime_store'
/var/www/miq/vmdb/gems/pending/util/extensions/miq-benchmark.rb:30:in `realtime_block'
/var/www/miq/vmdb/app/models/miq_server.rb:346:in `monitor'
/var/www/miq/vmdb/app/models/miq_server.rb:368:in `block (2 levels) in monitor_loop'
/var/www/miq/vmdb/gems/pending/util/extensions/miq-benchmark.rb:11:in `realtime_store'
/var/www/miq/vmdb/gems/pending/util/extensions/miq-benchmark.rb:30:in `realtime_block'
/var/www/miq/vmdb/app/models/miq_server.rb:368:in `block in monitor_loop'
/var/www/miq/vmdb/app/models/miq_server.rb:367:in `loop'
/var/www/miq/vmdb/app/models/miq_server.rb:367:in `monitor_loop'
/var/www/miq/vmdb/app/models/miq_server.rb:250:in `start'
/var/www/miq/vmdb/lib/workers/evm_server.rb:65:in `start'
/var/www/miq/vmdb/lib/workers/evm_server.rb:92:in `start'

Comment 7 James Wong 2017-10-19 13:40:12 UTC
Neha,

The log I've extracted points out that this is an invalid operation to begin with.  If there's no other info to prove the otherwise, please close this bug as invalid.  We can always reopen it when need to.

thanks,
James

Comment 8 Neha Chugh 2017-11-08 07:55:02 UTC
James,

Yes we can close this bug as we didn't heard from customer back.

Regards,
Neha Chugh