Currently I’m running 5.4 Beta on a 6.5 vCenter cluster. I have gone ahead and stood up the Opennebula instance, created the cluster, added the vCenter host, added network, storage. Created new virtual machine and installed the context rpm for CentOS 6.9 for this beta release. I have been able to instantiate a VM without disk expansion just fine, but when I try to create a VM with an expanded disk, I get the below error:
Mon Jun 19 16:46:57 2017 [Z0][VM][I]: New state is PENDING
Mon Jun 19 17:04:21 2017 [Z0][VM][I]: New state is ACTIVE
Mon Jun 19 17:04:21 2017 [Z0][VM][I]: New LCM state is PROLOG
Mon Jun 19 17:04:21 2017 [Z0][VM][I]: New LCM state is BOOT
Mon Jun 19 17:04:21 2017 [Z0][VMM][I]: Generating deployment file: /var/lib/one/vms/0/deployment.1
Mon Jun 19 17:04:21 2017 [Z0][VMM][I]: Successfully execute transfer manager driver operation: tm_context.
Mon Jun 19 17:04:21 2017 [Z0][VMM][I]: Successfully execute network driver operation: pre.
Mon Jun 19 17:04:34 2017 [Z0][VMM][I]: Command execution fail: /var/lib/one/remotes/vmm/vcenter/deploy '/var/lib/one/vms/0/deployment.1' '[sjcvcenter65]_CLUSTER01' 0 [sjcvcenter65]_CLUSTER01
Mon Jun 19 17:04:34 2017 [Z0][VMM][E]: Deploy of VM 0 on vCenter cluster [sjcvcenter65]_CLUSTER01 with `/var/lib/one/vms/0/deployment`.1 failed due to "InvalidDeviceOperation: Invalid operation for device '0'."
Mon Jun 19 17:04:34 2017 [Z0][VMM][E]: ["/usr/lib/one/ruby/vendors/rbvmomi/lib/rbvmomi/vim/Task.rb:11:in `wait_for_completion'", "/usr/lib/one/ruby/vcenter_driver/virtual_machine.rb:1311:in `resize_unmanaged_disks'", "/var/lib/one/remotes/vmm/vcenter/deploy:69:in `"]
Mon Jun 19 17:04:34 2017 [Z0][VMM][I]: ExitCode: 255
Mon Jun 19 17:04:34 2017 [Z0][VMM][I]: Failed to execute virtualization driver operation: deploy.
Mon Jun 19 17:04:34 2017 [Z0][VMM][E]: Error deploying virtual machine: Deploy of VM 0 on vCenter cluster [sjcvcenter65]_CLUSTER01 with /var/lib/one/vms/0/deployment.1 failed due to "InvalidDeviceOperation: Invalid operation for device '0'."
Mon Jun 19 17:04:34 2017 [Z0][VM][I]: New LCM state is BOOT_FAILURE
Is there something I’m missing either in the setup, or the contextualization of the VM that would be this error? vCenter reports an error while trying to modify the configuration of the VM.
Hi Jesus!
thanks for your feedback and testing it’s really helpful. The contextualization packages are not related with this issue so we can discard it. I’ve tried to reproduce the issue but it has worked in the beta:
I’ve imported a vcenter 6.5 cluster
I’ve imported the datastore where the template’s disk lives
I’ve imported a CentOS 7 template with a 10 GB Virtual Hard Disk.
I’ve instantiated the template and set a 11 GB disk size.
The VM is deployed sucessfully and an fdisk -l shows the new size.
Maybe there’s a combination that is not supported when the disk is resized so we have to find out with your kind help.
Once you’ve replaced the file, you could try to deploy a new VM with an expanded size. In the /tmp directory a file called resize_test should have been created and it should contain, hopefully, valuable information that we can use to debug that error if you send it to us.
Also if you could send us the outputs of the following commands they could help us to correlate information:
onevm show VMID -xwhere VMID is the ID of a failing VM.
onetemplate show TEMPLATE_ID -x where TEMPLATE_ID is the id of the template you use to deploy the VM.
oneimage show IMAGE_ID -x where IMAGE_ID is the ID (or IDs) of the images that represent virtual disks inside the template.
As sometimes it’s difficult to reproduce issues, we would thank you in advance for any help and info that you can provide.
Thank you for your input. It seems I made the mistake and I came to find out after I imported another template. The template that gave me the error was one I had imported as a master of linked clones. It seems the error only occurs when you use a linked clone template. As a regular template the expansion works as expected. Just wish I could figure out a way to automatically expand the disk in VMware without requiring a reboot from the instantiated VM. Oh well, you can’t have everything in life.