VM changes after 1.17.0 fail with error due to hardware version #1049

stuart-c · 2020-04-20T17:01:35Z

Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform Version

Terraform v0.12.24

vSphere Provider Version

provider.vsphere 1.17.0 - wprks
provider.vsphere 1.17.1 (and later) - does not work

Affected Resource(s)

vsphere_virtual_machine

Terraform Configuration Files

Debug Output

<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/">
    <Body>
        <ReconfigVM_Task xmlns="urn:vim25">
            <_this type="VirtualMachine">vm-88664</_this>
            <spec>
                <name>metrics01-eqx</name>
                <version>vmx-9</version>
                <guestId>ubuntu64Guest</guestId>
                <annotation>Managed via Terraform</annotation>
                <tools>
                    <afterPowerOn>true</afterPowerOn>
                    <afterResume>true</afterResume>
                    <beforeGuestStandby>true</beforeGuestStandby>
                    <beforeGuestShutdown>true</beforeGuestShutdown>
                    <beforeGuestReboot>false</beforeGuestReboot>
                    <syncTimeWithHost>false</syncTimeWithHost>
                </tools>

Panic Output

Expected Behavior

Actual Behavior

Error: The operation is not supported on the object.

Within vSphere the errors were:

A specified parameter was not correct:
The operation is not supported on the object.

Steps to Reproduce

Make a VM change (e.g. number of cpus)
Run with version 1.17.0 - works
Try name with version 1.17.1 or later
Fails

Looking at the debug logs the call which fails (ReconfigVM_Task) the only difference between the two versions is the vmx-9 tag is sent for 1.17.1 and later, which causes it to fail.

Important Factoids

vSphere Client version 6.7.0.42000

References

r/vm: Support hardware versions #1020

stuart-c · 2020-04-20T17:04:27Z

It looks like this causes it to always include the tag:

https://github.com/terraform-providers/terraform-provider-vsphere/pull/1020/files#diff-a143bd4a9f09a6894ae879c28d4a5c44R812

And I think it may only need it if the hardware version is changing?

Or is it that it isn't detecting the current hardware version correctly and is therefore trying to upgrade - the actual error message being displayed is from the UpgradeVM_TaskBody call, which isn't needed as there is no hardware upgrade needed.

stuart-c · 2020-04-20T17:04:57Z

Also, I noticed the docs are slightly wrong for hardware_version - the docs have it part of the clone option (indentation issue)

stuart-c · 2020-04-20T17:11:44Z

Looking at the state file it does have the hardware_version listed as 9:

    {
      "module": "module.metrics",
      "mode": "managed",
      "type": "vsphere_virtual_machine",
      "name": "virtual_machine",
      "each": "list",
      "provider": "provider.vsphere",
      "instances": [
        {
          "index_key": 0,
          "schema_version": 3,
          "attributes": {
            "alternate_guest_name": "",
            "annotation": "Managed via Terraform",
            "boot_delay": 0,
...
            "hardware_version": 9,

stuart-c · 2020-04-20T17:21:27Z

I'm not sure why it is trying to upgrade the hardware version. The web client confirms the existing version is 9. The UpgradeVM_TaskBody call is trying to upgrade to vmx-9 though.

I'm trying to follow the code, but I don't get why the if statement here isn't matching https://github.com/terraform-providers/terraform-provider-vsphere/pull/1020/files#diff-f8ef493fad928634f3515e7a57e998a5R900-R902

bill-rich · 2020-04-22T17:20:01Z

Hi @stuart-c! That is interesting that including the hardware version is causing your config to fail. Even though it is sending the hardware version each time, it shouldn't cause any changes unless the version being sent is different than the one in the config. Would it be possible to get the full debug output so I can get a better idea of what is going on through the process?

stuart-c · 2020-04-22T21:20:04Z

This is the error response from the ReconfigVM_Task that includes the Version:

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
 xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
 xmlns:xsd="http://www.w3.org/2001/XMLSchema"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<WaitForUpdatesExResponse xmlns="urn:vim25">
    <returnval>
        <version>1</version>
        <filterSet>
            <filter type="PropertyFilter">session[52816cb2-c195-547e-8815-2aabf1c555bc]52cab62a-400b-d759-6397-296fd9348fb7</filter>
            <objectSet>
                <kind>enter</kind>
                <obj type="Task">task-708969</obj>
                <changeSet>
                    <name>info</name>
                    <op>assign</op>
                    <val xsi:type="TaskInfo">
                        <key>task-708969</key>
                        <task type="Task">task-708969</task>
                        <name>ReconfigVM_Task</name>
                        <descriptionId>VirtualMachine.reconfigure</descriptionId>
                        <entity type="VirtualMachine">vm-88664</entity>
                        <entityName>xxxx</entityName>
                        <state>error</state>
                        <cancelled>false</cancelled>
                        <cancelable>false</cancelable>
                        <error>
                            <fault xsi:type="InvalidArgument"></fault>
                            <localizedMessage>A specified parameter was not correct: </localizedMessage>
                        </error>
                        <reason xsi:type="TaskReasonUser">
                            <userName>xxxx</userName>
                        </reason>
                        <queueTime>2020-04-20T17:10:41.552525Z</queueTime>
                        <startTime>2020-04-20T17:10:41.561071Z</startTime>
                        <completeTime>2020-04-20T17:10:41.566017Z</completeTime>
                        <eventChainId>12508460</eventChainId>
                    </val>
                </changeSet>
            </objectSet>
        </filterSet>
    </returnval>
</WaitForUpdatesExResponse>
</soapenv:Body>
</soapenv:Envelope>

(no error without that extra tag)

stuart-c · 2020-04-22T21:22:24Z

And these are the commands it executes (failure situation):

2020-04-20T18-08-38.855997000 - 0001:    206ms (*methods.RetrieveServiceContentBody)
2020-04-20T18-08-38.957028000 - 0002:     96ms (*methods.LoginBody)
2020-04-20T18-08-39.646273000 - 0003:     17ms (*methods.RetrievePropertiesBody)
2020-04-20T18-08-39.685623000 - 0004:     20ms (*methods.FindByUuidBody)
2020-04-20T18-08-39.706563000 - 0005:     19ms (*methods.RetrievePropertiesBody)
2020-04-20T18-08-39.744148000 - 0006:     35ms (*methods.RetrievePropertiesBody)
2020-04-20T18-08-39.792618000 - 0007:     23ms (*methods.RetrievePropertiesBody)
2020-04-20T18-08-39.936723000 - 0008:    126ms (*methods.ShutdownGuestBody)
2020-04-20T18-08-39.956982000 - 0009:     17ms (*methods.CreatePropertyCollectorBody)
2020-04-20T18-08-39.977027000 - 0010:     17ms (*methods.CreateFilterBody)
2020-04-20T18-08-39.996671000 - 0011:     17ms (*methods.WaitForUpdatesExBody)
2020-04-20T18-10-41.521519000 - 0012: 121519ms (*methods.WaitForUpdatesExBody)
2020-04-20T18-10-41.539861000 - 0013:     16ms (*methods.DestroyPropertyCollectorBody)
2020-04-20T18-10-41.567254000 - 0014:     24ms (*methods.ReconfigVM_TaskBody)
2020-04-20T18-10-41.585537000 - 0015:     16ms (*methods.CreatePropertyCollectorBody)
2020-04-20T18-10-41.604837000 - 0016:     17ms (*methods.CreateFilterBody)
2020-04-20T18-10-41.624480000 - 0017:     18ms (*methods.WaitForUpdatesExBody)
2020-04-20T18-10-41.644041000 - 0018:     16ms (*methods.DestroyPropertyCollectorBody)
2020-04-20T18-10-41.682346000 - 0019:     35ms (*methods.RetrievePropertiesBody)
2020-04-20T18-10-41.727743000 - 0020:     23ms (*methods.UpgradeVM_TaskBody)
2020-04-20T18-10-41.749022000 - 0021:     18ms (*methods.CreatePropertyCollectorBody)
2020-04-20T18-10-41.770564000 - 0022:     18ms (*methods.CreateFilterBody)
2020-04-20T18-10-41.791578000 - 0023:     18ms (*methods.WaitForUpdatesExBody)
2020-04-20T18-10-41.811680000 - 0024:     16ms (*methods.DestroyPropertyCollectorBody)

I've no idea why it is sending UpgradeVM_TaskBody as it is already v9 (in Terraform state & vSphere UI) and that's what it is being upgraded to.

stuart-c · 2020-04-22T21:27:53Z

@bill-rich is there anything in particular you'd like to look at?

Comparing the between 1.17.0 & 1.17.1 the only difference is the addition of the <version>vmx-9</version> tag for the ReconfigVM_TaskBody.

bill-rich · 2020-05-01T15:53:44Z

This should be fixed in #1055. Please let me know if you're still running into the issue with the latest version of the provider.

ghost · 2020-06-01T05:10:00Z

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!

stuart-c added the bug Type: Bug label Apr 20, 2020

bill-rich added the waiting-response Status: Waiting on a Response label Apr 22, 2020

ghost removed the waiting-response Status: Waiting on a Response label Apr 22, 2020

bill-rich mentioned this issue Apr 26, 2020

Only include hardware version in CreateSpecs #1055

Merged

bill-rich closed this as completed May 1, 2020

ghost locked and limited conversation to collaborators Jun 1, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

VM changes after 1.17.0 fail with error due to hardware version #1049

VM changes after 1.17.0 fail with error due to hardware version #1049

stuart-c commented Apr 20, 2020

stuart-c commented Apr 20, 2020

stuart-c commented Apr 20, 2020

stuart-c commented Apr 20, 2020

stuart-c commented Apr 20, 2020

bill-rich commented Apr 22, 2020

stuart-c commented Apr 22, 2020

stuart-c commented Apr 22, 2020

stuart-c commented Apr 22, 2020

bill-rich commented May 1, 2020

ghost commented Jun 1, 2020

VM changes after 1.17.0 fail with error due to hardware version #1049

VM changes after 1.17.0 fail with error due to hardware version #1049

Comments

stuart-c commented Apr 20, 2020

Community Note

Terraform Version

vSphere Provider Version

Affected Resource(s)

Terraform Configuration Files

Debug Output

Panic Output

Expected Behavior

Actual Behavior

Steps to Reproduce

Important Factoids

References

stuart-c commented Apr 20, 2020

stuart-c commented Apr 20, 2020

stuart-c commented Apr 20, 2020

stuart-c commented Apr 20, 2020

bill-rich commented Apr 22, 2020

stuart-c commented Apr 22, 2020

stuart-c commented Apr 22, 2020

stuart-c commented Apr 22, 2020

bill-rich commented May 1, 2020

ghost commented Jun 1, 2020