UUID_INVALID

[geosword]

Hi there,
So I'm trying this out but I'm experiencing a strange problem:
Everything's installed correctly, and a terraform plan show what should be created as expected, however when I apply, I get this:
* xenserver_vm.web: API Error: UUID_INVALID sr

Checking the logs on the xenserver confirms its the server spitting this error message out. Naturally my first reaction was to check that the uuid Id specified for the SR in the vdi definition is correct (it is). For completeness here's my manifest, with the password removed, naturally:

provider "xenserver" {
        url      = "myxenserver"
        username = "username"
        password = "password"
}

resource "xenserver_vdi" "vdi" {
  sr_uuid = "3454553a-cbcc-41c5-98ef-dcba60a847a0" 
  name_label = "terraformtestvdi"
  size = 20073741824 # 20GB
}

resource "xenserver_vm" "web" {
    name_label = "terraformtest"
    base_template_name = "Debian Wheezy 7.0 (64-bit)"
    static_mem_min = 2147483648 # 2GB
    static_mem_max = 2147483648
    dynamic_mem_min = 2147483648
    dynamic_mem_max = 2147483648
    boot_order = "cdn"
    network_interface {
        network_uuid = "24a44383-990f-b337-a196-fc5944b38852"
        #mac = "<desired-mac>"
        mtu = 1500
        device = 0
    }

        vcpus = 2

    cdrom {
    	vdi_uuid = "86b1c8cd-b16f-4383-91c5-3b7b17ad9224"
    }
    hard_drive {
      vdi_uuid = "${xenserver_vdi.vdi.id}"
    }
}

Some versions / information on installed components:

# git describe --tags
v0.2.0-11-g85fe85d
# terraform -version
Terraform v0.11.3
# go version
go version go1.9.4 linux/amd64

On the xenserver:
# xl info | grep -E "xen_(major|minor|extra)"                                                
xen_major              : 4
xen_minor              : 7
xen_extra              : .2-2.2

I decided to start commenting out various sections of the vm definition in order to confirm that the problem is indeed with (as it looks) with the VDI creation, however the error continued to show. Given I cant see anyone else experiencing the same problem, my feeling is that Im doing something obviously dumb, but Im afraid I cant see what.

Can anyone offer any pointers?

[debovema]

I'm having the exact same issue.

In fact the VDI is created but the error is thrown and the plan does not get applied further.

When I tried to apply the plan a second time in a row, it does not detect that the VM nor the VDI is tainted and the plan ends in success but the VDI is not bound to the VM in XenServer.

[geosword]

Yes, upon running terraform apply again, I can confirm I get the same result. I had thought it was because terraform doesnt "Know" about the SR (since there is no SR definition in the manifest) However:

1. The error is coming from Xenserver itself
2. The SR resource is unimplemented.

[p4ulie]

The same error for me too.
After adding few custom debug logs to trace the method calls in terraform xenserver provider and go-xen-api-client API calls, it seems to break in the method VM.provision

2018/02/19 12:15:03 [DEBUG] method VM.provision params [OpaqueRef:b1d6fa99-4295-498d-a875-927db275790a OpaqueRef:3e6b48e1-4b08-4e6f-a347-6845f127b43d] 2018/02/19 12:15:03 [DEBUG] rpcResult map[Status:Failure ErrorDescription:[UUID_INVALID sr <nil>]]

there is a mention of sr parameter in my trace log few lines before that, with empty value (sr=""):

2018/02/19 12:15:03 [DEBUG] method VM.set_other_config params [OpaqueRef:b1d6fa99-4295-498d-a875-927db275790a OpaqueRef:3e6b48e1-4b08-4e6f-a347-6845f127b43d map[mac_seed:0b5d575b-9ded-6d35-20ec-76d066ddd5a3 disks:<provision><disk bootable="true" device="0" size="8589934592" sr="" type="system"/></provision> linux_template:true base_template_name:CentOS 6 (64-bit) install-methods:cdrom,nfs,http,ftp install-distro:rhlike import_task:OpaqueRef:55c96b6a-de99-48d4-846c-f357ce5b2c20 rhel6:true]]

[joncave]

The problem is that the default XenServer templates include disk provisioning XML in their other_config. The VM.provision API call attempts to automatically create disks based on this information. Given that no SR is defined in this XML it breaks.

There is no problem if a template that was converted from a VM is used since those templates do not have disk provisioning XML, instead they have actual disks already.

In order to allow the default templates to be used then I would suggest that this provider detect if the disks XML is present in the clone template and removing it prior to provisioning. This is how the "New VM" XenCenter wizard works: https://github.com/xenserver/xenadmin/blob/0f31a6f857e3abde74c45563eefcc25f6318b121/XenModel/Actions/VM/CreateVMAction.cs#L383. The wizard only uses the XML to pre-populate the "Storage" page: https://github.com/xenserver/xenadmin/blob/master/XenAdmin/Wizards/NewVMWizard/Page_Storage.cs#L105-L112.

Temporary 'fix' for users would probably be to manually create a new VM and then use XenCenter to convert it to a template. This can then be referenced in base_template_name.

[dot1q]

I found a workaround for myself by mimicking what that xenadmin does.

Of course this breaks ever being able to use the template specified VBD, but I always specify them myself anyway.