Giter Site home page Giter Site logo

proxmox-api-go's Introduction

Proxmox API Go

Proxmox API in golang. For /api2/json. Work in progress.

Starting with Proxmox 5.2 you can use cloud-init options.

Contributing

Want to help with the project please refer to our style-guide.

Build

go build -o proxmox-api-go

Run

Create a local .env file in the root directory of the project and add the following environment variables:

PM_API_URL="https://xxxx.com:8006/api2/json"
PM_USER=user@pam
PM_PASS=password
PM_OTP=otpcode (only if required)
PM_HTTP_HEADERS=Key,Value,Key1,Value1 (only if required)

Note: Do not commit your local .env file to version control to keep your credentials secure.

Or export the environment variables:

export PM_API_URL="https://xxxx.com:8006/api2/json"
export PM_USER=user@pam
export PM_PASS=password
export PM_OTP=otpcode (only if required)
export PM_HTTP_HEADERS=Key,Value,Key1,Value1 (only if required)

Run commands (examples, not a complete list):

./proxmox-api-go installQemu proxmox-node-name < qemu1.json

./proxmox-api-go createQemu 123 proxmox-node-name < qemu1.json

./proxmox-api-go -debug start 123

./proxmox-api-go -debug stop 123

./proxmox-api-go cloneQemu template-name proxmox-node-name < clone1.json

./proxmox-api-go migrate 123 migrate-to-proxmox-node-name

./proxmox-api-go createQemuSnapshot vm-name snapshot_name

./proxmox-api-go deleteQemuSnapshot vm-name snapshot_name

./proxmox-api-go listQemuSnapshot vm-name

./proxmox-api-go rollbackQemu vm-name

./proxmox-api-go getResourceList

./proxmox-api-go getVmList

./proxmox-api-go getUserList

./proxmox-api-go getUser userid

./proxmox-api-go updateUserPassword userid password

./proxmox-api-go setUser userid password < user.json

./proxmox-api-go deleteUser userid

./proxmox-api-go getAcmeAccountList

./proxmox-api-go getAcmeAccount accountid

./proxmox-api-go createAcmeAccount accountid < acmeAccount.json

./proxmox-api-go updateAcmeAccountEmail accountid email0,email1,email2

./proxmox-api-go deleteAcmeAccount accountid

./proxmox-api-go getAcmePluginList

./proxmox-api-go getAcmePlugin pluginid

./proxmox-api-go setAcmePlugin pluginid < acmePlugin.json

./proxmox-api-go deleteAcmePlugin pluginid

./proxmox-api-go getMetricsServerList

./proxmox-api-go getMetricsServer metricsid

./proxmox-api-go setMetricsServer metricsid < metricsServer.json

./proxmox-api-go deleteMetricsServer metricsid

./proxmox-api-go getStorageList

./proxmox-api-go getStorage storageid

./proxmox-api-go createStorage storageid < storage.json

./proxmox-api-go updateStorage storageid < storage.json

./proxmox-api-go deleteStorage

./proxmox-api-go getNetworkList node

./proxmox-api-go getNetworkInterface node interfaceName

./proxmox-api-go createNetwork < network.json

./proxmox-api-go updateNetwork < network.json

./proxmox-api-go deleteNetwork node iface

./proxmox-api-go applyNetwork node

./proxmox-api-go revertNetwork node

./proxmox-api-go node reboot proxmox-node-name

./proxmox-api-go node shutdown proxmox-node-name

./proxmox-api-go unlink 123 proxmox-node-name "virtio1,virtio2,virtioN" [false|true]

Proxy server support

Just use the flag -proxy and specify your proxy url and port

./proxmox-api-go -proxy https://localhost:8080 start 123

Format

createQemu JSON Sample:

{
  "name": "golang1.test.com",
  "desc": "Test proxmox-api-go",
  "memory": 2048,
  "os": "l26",
  "cores": 2,
  "sockets": 1,
  "iso": {
    "storage": "local",
    "file": "ubuntu-14.04.5-server-amd64.iso"
  },
  "disk": {
    "0": {
      "type": "virtio",
      "storage": "local",
      "storage_type": "dir",
      "size": "30G",
      "backup": true
    }
  },
  "efidisk": {
    "storage": "local",
    "pre-enrolled-keys": "1",
    "efitype": "4m"
  },
  "network": {
    "0": {
      "model": "virtio",
      "bridge": "nat"
    },
    "1": {
      "model": "virtio",
      "bridge": "vmbr0",
      "firwall": true,
      "backup": true,
      "tag": -1
    }
  },
  "rng0": {
    "source": "/dev/urandom",
    "max_bytes": "1024",
    "period": "1000"
  },
  "usb": {
    "0": {
      "host": "0658:0200",
      "usb3": true
    }
  }
}

cloneQemu JSON Sample:

{
  "name": "golang2.test.com",
  "desc": "Test proxmox-api-go clone",
  "storage": "local",
  "memory": 2048,
  "cores": 2,
  "sockets": 1,
  "fullclone": 1
}

cloneQemu cloud-init JSON Sample:

{
  "name": "cloudinit.test.com",
  "desc": "Test proxmox-api-go clone",
  "storage": "local",
  "memory": 2048,
  "cores": 2,
  "sockets": 1,
  "ipconfig": {
    "0": "gw=10.0.2.2,ip=10.0.2.17/24"
  },
  "sshkeys": "...",
  "nameserver": "8.8.8.8"
}

setUser JSON Sample:

{
  "comment": "",
  "email": "[email protected]",
  "enable": true,
  "expire": 0,
  "firstname": "Bruce",
  "lastname": "Wayne",
  "groups": [
    "admins",
    "usergroup"
  ],
  "keys": "2fa key"
}

createAcmeAccount JSON Sample:

{
  "contact": [
    "[email protected]",
    "[email protected]"
  ],
  "directory": "https://acme-staging-v02.api.letsencrypt.org/directory",
  "tos": true
}

setAcmePlugin JSON Sample:

{
  "api": "aws",
  "data": "AWS_ACCESS_KEY_ID=DEMOACCESSKEYID\nAWS_SECRET_ACCESS_KEY=DEMOSECRETACCESSKEY\n",
  "enable": true,
  "validation-delay": 30
}

setMetricsServer JSON Sample:

{
  "port": 8086,
  "server": "192.168.67.3",
  "type": "influxdb",
  "enable": true,
  "mtu": 1500,
  "timeout": 1,
  "influxdb": {
    "protocol": "https",
    "max-body-size": 25000000,
    "verify-certificate": false,
    "token": "Rm8mqheWSVrrKKBW"
  }
}

createStorage JSON Sample:

{
  "enable": true,
  "type": "smb",
  "smb": {
    "username": "b.wayne",
    "share": "NetworkShare",
    "preallocation": "metadata",
    "domain": "organization.com",
    "server": "10.20.1.1",
    "version": "3.11",
    "password": "Enter123!"
  },
  "content": {
    "backup": true,
    "iso": false,
    "template": true,
    "diskimage": true,
    "container": true,
    "snippets": false
  },
  "backupretention": {
    "last": 10,
    "hourly": 4,
    "daily": 7,
    "monthly": 3,
    "weekly": 2,
    "yearly": 1
  }
}

Cloud-init options

Cloud-init VMs must be cloned from a cloud-init ready template. See: https://pve.proxmox.com/wiki/Cloud-Init_Support

  • ciuser - User name to change ssh keys and password for instead of the image’s configured default user.
  • cipassword - Password to assign the user.
  • cicustom - Specify custom files to replace the automatically generated ones at start.
  • searchdomain - Sets DNS search domains for a container.
  • nameserver - Sets DNS server IP address for a container.
  • sshkeys - public ssh keys, one per line
  • ipconfig0 - [gw=] [,gw6=] [,ip=<IPv4Format/CIDR>] [,ip6=<IPv6Format/CIDR>]
  • ipconfig1 - optional, same as ipconfig0 format

ISO requirements (non cloud-init)

Kickstart auto install

  • partition /dev/vda
  • network eth1
  • sshd (with preshared key/password)

Network is temprorarily eth1 during the pre-provision phase.

Test

You're going to need vagrant and virtualbox to run the tests:

make test

proxmox-api-go's People

Contributors

aabouzaid avatar abuisine avatar alessandrosechi avatar benediktbertsch avatar carlpett avatar claudusd avatar dandyrow avatar gentoo9ball avatar ggongaware avatar ivanpedersen avatar jqueuniet avatar knkay avatar liorokman avatar mabeett avatar matchlighter avatar mizhka avatar mleone87 avatar pgporada avatar rf152 avatar romantomjak avatar sebastian-de avatar sygibson avatar thorntonmc avatar tinyblargon avatar tnyeanderson avatar v-paranoiaque avatar weinmann-kay avatar wynro avatar yesrod avatar yukron avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

proxmox-api-go's Issues

Panic in checkid function

Buitl from current master branch

$ ./proxmox-api-go -debug -insecure checkid
panic: runtime error: index out of range [1] with length 1

goroutine 1 [running]:
main.main()
	/home/user/proxmox-api-go/main.go:256 +0x3cd5

If I pass a value, then checkid works as intended.

$ ./proxmox-api-go -debug -insecure checkid 120
{"data":null,"errors":{"vmid":"VM 120 already exists"}}

$ ./proxmox-api-go -debug -insecure checkid 121
{"data":"121"}
2021/07/23 15:53:56 Selected ID is free: 121

There should be a test for these cases.

Link local IPv6 address can not be parsed for Windows VMs

When trying to retrieve the IPs from a Windows VM I get an error that the IP could not be parsed.
This has to do with the Qemu guest agent returning the link local IPv6 address with the interface name:
fe80::b955:5aab:62c1:a1f3%3

As such the IP address cannot be parsed. I added a simple fix to prevent this but not sure if it's the proper way to handle this.

Basically I added a split in the code where the IP addresses get parsed one by one. It splits on the % sign and returns only the first part. This makes the function parse the IPv6 correctly.
a.IPAddresses[idx] = net.ParseIP((strings.Split(ip.IPAddress, "%"))[0])

Live migrating a VM via this API causes the VM to be stopped then started

Hi,

I just started using the latest proxmox ve, terraform-provider-proxmox, and this API as a result. In the proxmox web ui I am able to live migrate a VM from one host to another seamlessly. I don't believe this to be an issue with the terraform-provider-go because I didn't detect a specific shutdown message in the terraform debug output leading me to post here.

The proxmox web ui shows the following log:

()
2021-04-22 01:02:09 starting migration of VM 101 to node 'pve3' (10.1.0.203)
2021-04-22 01:02:10 starting VM 101 on remote node 'pve3'
2021-04-22 01:02:11 start remote tunnel
2021-04-22 01:02:12 ssh tunnel ver 1
2021-04-22 01:02:12 starting online/live migration on unix:/run/qemu-server/101.migrate
2021-04-22 01:02:12 set migration_caps
2021-04-22 01:02:12 migration speed limit: 8589934592 B/s
2021-04-22 01:02:12 migration downtime limit: 100 ms
2021-04-22 01:02:12 migration cachesize: 67108864 B
2021-04-22 01:02:12 set migration parameters
2021-04-22 01:02:12 start migrate command to unix:/run/qemu-server/101.migrate
2021-04-22 01:02:13 migration status: active (transferred 294227312, remaining 155041792), total 554508288)
2021-04-22 01:02:13 migration xbzrle cachesize: 67108864 transferred 0 pages 0 cachemiss 0 overflow 0
2021-04-22 01:02:14 migration speed: 256.00 MB/s - downtime 57 ms
2021-04-22 01:02:14 migration status: completed
2021-04-22 01:02:17 migration finished successfully (duration 00:00:08)
TASK OK

proxmox-live-migrate-web-ui

When I have terraform-provider-go perform that same function this text (which I expected to see) appears. However...

$ terraform apply
proxmox_vm_qemu.le-clone[0]: Refreshing state... [id=pve1/qemu/101]

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # proxmox_vm_qemu.le-clone[0] will be updated in-place
  ~ resource "proxmox_vm_qemu" "le-clone" {
        id                     = "pve1/qemu/101"
        name                   = "le-clone-0"
      ~ target_node            = "pve1" -> "pve2"
        # (32 unchanged attributes hidden)


        # (2 unchanged blocks hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

proxmox-api-migrate

Attached is a terraform-provider-go trace log from my vagrant cluster that shows all the HTTP POST/GETs. I can see that the migration is correctly being called with online=1.
api.log

Thank you!

/access/ticket": x509:

pveum role add TerraformProv -privs "VM.Allocate VM.Clone VM.Config.CDROM VM.Config.CPU VM.Config.Cloudinit VM.Config.Disk VM.Config.HWType VM.Config.Memory VM.Config.Network VM.Config.Options VM.Monitor VM.Audit VM.PowerMgmt Datastore.AllocateSpace Datastore.Audit"
pveum user add terraform-prov@pve
pveum aclmod / -user terraform-prov@pve -role TerraformProv
pveum user token add terraform-prov@pve terraform-token --privsep=0
┌──────────────┬──────────────────────────────────────┐
│ key │ value │
╞══════════════╪══════════════════════════════════════╡
│ full-tokenid │ terraform-prov@pve!terraform-token │
├──────────────┼──────────────────────────────────────┤
│ info │ {"privsep":"0"} │
├──────────────┼──────────────────────────────────────┤
│ value │ 477e8ccc-838f-404a-927f-342864e971fe │
└──────────────┴──────────────────────────────────────┘

PM_API_URL=https://192.168.200.211:8006/api2/json
PM_PASS=477e8ccc-838f-404a-927f-342864e971fe
PM_USER=terraform-prov@pve

└─# ./proxmox-api-go -debug start 103
2022/11/26 06:27:43 Post "https://192.168.200.211:8006/api2/json/access/ticket": x509: certificate signed by unknown authority

user not found even when it exists

A bug was introduced in daf13c5 by using the new listUsersPartial() function in CheckUserExistence(), instead of listUsersFull() which is the renamed version of the original listUsers() function.

This causes the error user does not exist or has insufficient permissions on proxmox: <user>

GetVmRefsByName Crash (Downstream terraform-provider-proxmox)

As described in this comment, it looks like whenever the terraform Proxmox provider attempts to use the api to get a VM by reference, it crashes:

Stack trace from the terraform-provider-proxmox plugin:

panic: interface conversion: interface {} is nil, not []interface {}

goroutine 43 [running]:
github.com/Telmate/proxmox-api-go/proxmox.(*Client).GetVmRefsByName(0x14000314460, {0x1400011e670, 0x5})
	/Users/clbx/go/pkg/mod/github.com/!telmate/[email protected]/proxmox/client.go:197 +0x768
github.com/Telmate/proxmox-api-go/proxmox.(*Client).GetVmRefByName(...)
	/Users/clbx/go/pkg/mod/github.com/!telmate/[email protected]/proxmox/client.go:187
github.com/Telmate/terraform-provider-proxmox/proxmox.resourceVmQemuCreate(0x14000212f00, {0x1028bef80, 0x140003144b0})
	/Users/clbx/Projects/terraform-provider-proxmox/proxmox/resource_vm_qemu.go:795 +0x12ac
github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*Resource).create(0x140003bc700, {0x1029fd900, 0x14000718000}, 0x14000212f00, {0x1028bef80, 0x140003144b0})
	/Users/clbx/go/pkg/mod/github.com/hashicorp/terraform-plugin-sdk/[email protected]/helper/schema/resource.go:695 +0x170
github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*Resource).Apply(0x140003bc700, {0x1029fd900, 0x14000718000}, 0x1400052e270, 0x14000212d80, {0x1028bef80, 0x140003144b0})
	/Users/clbx/go/pkg/mod/github.com/hashicorp/terraform-plugin-sdk/[email protected]/helper/schema/resource.go:837 +0xc14
github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*GRPCProviderServer).ApplyResourceChange(0x1400000f140, {0x1029fd858, 0x1400011a700}, 0x140001445a0)
	/Users/clbx/go/pkg/mod/github.com/hashicorp/terraform-plugin-sdk/[email protected]/helper/schema/grpc_provider.go:1021 +0xedc
github.com/hashicorp/terraform-plugin-go/tfprotov5/tf5server.(*server).ApplyResourceChange(0x140000ea3c0, {0x1029fd900, 0x14000111830}, 0x14000708000)
	/Users/clbx/go/pkg/mod/github.com/hashicorp/[email protected]/tfprotov5/tf5server/server.go:812 +0x574
github.com/hashicorp/terraform-plugin-go/tfprotov5/internal/tfplugin5._Provider_ApplyResourceChange_Handler({0x1029b4a20, 0x140000ea3c0}, {0x1029fd900, 0x14000111830}, 0x1400010eb40, 0x0)
	/Users/clbx/go/pkg/mod/github.com/hashicorp/[email protected]/tfprotov5/internal/tfplugin5/tfplugin5_grpc.pb.go:385 +0x1c0
google.golang.org/grpc.(*Server).processUnaryRPC(0x140000b6700, {0x102a09ba0, 0x140004024e0}, 0x14000700000, 0x140003d4ba0, 0x102ecb140, 0x0)
	/Users/clbx/go/pkg/mod/google.golang.org/[email protected]/server.go:1283 +0xc88
google.golang.org/grpc.(*Server).handleStream(0x140000b6700, {0x102a09ba0, 0x140004024e0}, 0x14000700000, 0x0)
	/Users/clbx/go/pkg/mod/google.golang.org/[email protected]/server.go:1620 +0xa34
google.golang.org/grpc.(*Server).serveStreams.func1.2(0x1400042c540, 0x140000b6700, {0x102a09ba0, 0x140004024e0}, 0x14000700000)
	/Users/clbx/go/pkg/mod/google.golang.org/[email protected]/server.go:922 +0x94
created by google.golang.org/grpc.(*Server).serveStreams.func1
	/Users/clbx/go/pkg/mod/google.golang.org/[email protected]/server.go:920 +0x1f0

Error: The terraform-provider-proxmox plugin crashed!

This is always indicative of a bug within the plugin. It would be immensely
helpful if you could report the crash with the plugin's maintainers so that it
can be fixed. The output above should help diagnose the issue.
> pveversion
pve-manager/7.1-7/df5740ad (running kernel: 5.13.19-2-pve)
Terraform v1.1.9
on darwin_arm64
+ provider registry.terraform.io/telmate/proxmox v2.9.10

Feature request: HA support for LXC containers

First off, I apologize for the state of this issue, but my Go knowledge is limited. If anything I say is completely incorrect, please let me know.

Looking at the existing state of this API, it appears that the LXC container part doesn't handle HA configuration, but the QEMU VM part does. Specifically, the LXC container part is missing the hastate parameter.

If I'm reading the code correctly, the UpdateVMHA() function at https://github.com/Telmate/proxmox-api-go/blob/master/proxmox/client.go#L1172 should support setting up the HA resource for a LXC container already. If that is correct, then the LXC container part just needs a few things to also support HA, and config_qemu.go could be used as a reference to add that support.

Unfortunately, I don't understand the code well enough yet to make an attempt on my own to add this support. I would greatly appreciate if someone more familiar with the code could add this support.

Support PCI passthrough to vm

We are trying to configure VMs with infiniband devices being passed through from the host.

I found Telmate/terraform-provider-proxmox#299, which states, that passing through PCI devices is currently not supported and that work has to be done within this repo to make it happen.

I'd love to help make this happen as it would simplify our setup and prevent some tedious manual work when provisioning new VMs for our k8s cluster.

Any advice on where to start? What to consider?

cloudinit can't config ifconfig

get error like this.

{"data":{"upid":"UPID:r7208:003377E3:0C58F6D4:5BC59E4D:qmclone:9999:hmy@pam:","pid":3373027,"user":"hmy@pam","id":"9999","status":"stopped","starttime":1539677773,"exitstatus":"OK","pstart":207156948,"node":"r7208","type":"qmclone"}})
2018/10/16 16:16:34 >>>>>>>>>> REQUEST:
%!(EXTRA string=POST /api2/json/nodes/r7201/qemu/10000/config HTTP/1.1
Host: wxpve1.vphotos.cn:8006
User-Agent: Go-http-client/1.1
Content-Length: 85
Accept: application/json
Content-Type: application/x-www-form-urlencoded
Cookie: PVEAuthCookie=PVE:hmy@pam:5BC59E4D::ZeFGuZeV9nNeulIzdWBXu/tJPdEsv/cFm2IKH7+JAqzUHraqgzxgvNM94zo3OgvWkOg1JEQZvIynSBdM6KCsCtXaeIh/lro4wDs5U6D2zBqB4lcP8Y22297bKbrd1GX4mwWdB2Tw/aafKxTwYNU0jejc8lvQ9yhhGMlNR8uf/yjc6AKfrXM566EpFigZ6PYOO6aMc10U+Il+jqPTyKsO8LCr6JQpz4hpbEHUDeGSPGYbbaINplBxwJ6j69/QmRhnemMG5XOdlHmAmRL0lSorSlm/Y5JETwSTlC78oB/tsVLIouWF6wm3YsRc2vWSfWCeH53bo0TGg2Dpeat1r51opA==
Csrfpreventiontoken: 5BC59E4D:X4cwA1Q/KgXsFfebliU/6+AmcUc
Accept-Encoding: gzip

cores=2&description=Test+proxmox-api-go+clone&memory=2048&net0=%2Cbridge%3D&sockets=1)
2018/10/16 16:16:34 <<<<<<<<<< RESULT:
%!(EXTRA string=HTTP/1.1 400 Parameter verification failed.
Connection: close
Content-Length: 97
Cache-Control: max-age=0
Content-Type: application/json;charset=UTF-8
Date: Tue, 16 Oct 2018 08:16:34 GMT
Expires: Tue, 16 Oct 2018 08:16:34 GMT
Pragma: no-cache
Server: pve-api-daemon/3.0

{"errors":{"net0":"invalid format - missing key in comma-separated list property\n"},"data":null})
2018/10/16 16:16:34 Complete
2018/10/16 16:16:34

CreateVm assumes ISO is always required for VM create

In proxmox/config_qemu.go, the CreateVm call assumes that all VM creations require an ISO for the VM is specified. This causes a VM Create to fail when a blank/empty VM is created but does not need the ISO attached. Subsequently, a user must attach a blank/empty ISO just to create the VM.

As a user, I would like to CreateVm, but not be required to specify a superfluous ISO.

QEMU VMs with 2+ ide devices will override iso parameter

when creating a qemu vm with more than 2 ide disks, 'iso' param is no longer honored.

{
  "name": "proxmox-api-go-test",
  "desc": "Test proxmox-api-go",
  "memory": 2048,
  "os": "l26",
  "cores": 2,
  "sockets": 1,
  "vmid": 123,
  "iso": "local:iso/ubuntu-18.04.5-live-server-amd64.iso",                                // supposedly  alias for ide2
  "disk": {
    "0": {
      "type": "virtio",
      "storage": "local-thinlvm",
      "storage_type": "lvmthin",
      "size": "30G",
      "backup": false
    },
    "1" :{
      "type": "ide",
      "storage": "whatever",
      "size": "1",
      "media": "cdrom",
      "backup": false,
      "slot": 0,                                                          // not used
      "volume": "local:iso/some.iso"
    },
    "2" :{
      "type": "ide",
      "storage": "whatever",
      "size": "1",
      "media": "cdrom",
      "backup": false,
      "slot": 3,                                                          // not used
      "volume": "local:iso/some.iso"
    }
  },
  "network": {
    "0": {
      "model": "virtio",
      "bridge": "vmbr0",
      "firewall": true,
      "tag": -1
    }
  }
}

the first iso is always mounted as ide1 then the next one is meant to be ide3 or ide0 that are available but proxmox-api-go overrides the ide2 instead.

request made by this client:
agent=0&cores=2&description=Test+proxmox-api-go&ide1=local%3Aiso%2Fsome.iso%2Csize%3D1%2Cmedia%3Dcdrom&ide2=local%3Aiso%2Fsome.iso%2Csize%3D1%2Cmedia%3Dcdrom&kvm=1&memory=2048&name=proxmox-api-go-test&net0=virtio%3DC2%3AC5%3A48%3A3E%3A9C%3ADD%2Cbridge%3Dvmbr0%2Cfirewall%3D1&numa=0&onboot=0&ostype=l26&sockets=1&virtio0=local-thinlvm%3A30&vmid=123

shouldn't this api client honor "slot" param or exclude ide2 to be assigned in the disk config section when iso param exists?

Improve Cloud-Init ipconfig[n]

While working with packer-plugin-proxmox, which also uses this project, I had a look at how ipconfig-entries for Cloud-Init are handled.
The way it works right now makes it quite clumsy to add the relevant support to Packer.

Right now a config block looks like this:

{
  "network": {
    "0": {
      "model": "virtio",
      "bridge": "vmbr0",
    }
  }
  "ipconfig0": "gw=10.0.2.2,ip=10.0.2.17/24"
}

I would like to define the ipconfig inside every network card block like this:

{
  "network": {
    "0": {
      "model": "virtio",
      "bridge": "vmbr0",
      "ipconfig": "gw=10.0.2.2,ip=10.0.2.17/24"
    }
  }
}

I know that this is a breaking change, but I think this makes the configuration (and code) a lot cleaner.
I'm making a PR ready, please let me know what you think!

converting nic's link_down integers to bool for qemu

I use the terraform-provider-proxmox. When I run terraform import, I got this error:
Error: network.1.link_down: '' expected type 'bool', got unconvertible type 'int'
I see there is a pull request resolve a similar error for firewall: #97
Can we do the same fix for link_down?

JSON Format: disk and network sections

The example in the README seems to be in a strange format, certainly not JSON:

  "network": {
    0: {
      "model": "virtio",
      "bridge": "nat"
    },
    1: {
    ...
    },

Shouldn't it look more like an array, the indices could be made implicit, couldn't they?

  "networks":
  [
    { "name": "eth0",
      "bridge": "vmbr0",
      "ip": "dhcp",
      "ip6": "dhcp"
    },
    {
    ...
    },
  ],

Or if the indices of the "disk" and "network" sections cannot be made implicit, they should be strings and not integers?

Also, there is a missing bracket:

"disk": {
    0: {
      "type": "virtio",
      "storage": "local",
      "storage_type": "dir",
      "size": "30G",
      "backup": true
  },
}, <- bracket should be here, to close the "disk" section
      before the "network" section beings
"network": {
...

Removing a disk does not work

Removing a disk do not remove the disk in proxmox. The configure task command in Proxmox do not mention the disk I want to remove. I think not mentioning is not removing.

I proxmox you have to detach the disk first and then delete it.

Deletion task:

update VM 287: -delete unused0

Further information:

No method to create a PXE based Virtual Machine

It's perfectly valid to create an empty VM and set the boot directives to network boot (PXE) first. This allows external provisioning systems that utilize DHCP / TFTP / PXE boot methods to build Virtual Machines.

As an operator, I would like the ability for the CreateVm function to support the PXE boot options. This might be done by specifying an appropriate boot config directive that specifies the Network Boot options. In addition, a Config directive of pxe should be added to allow downstream use of the feature.

Custom HTTP headers for Proxmox API url

I wanted to ask If there can be an option to add custom headers for request to Proxmox API?
I have Proxmox behind Cloudflare Access and for accessing Proxmox I need to add 2 custom headers to request https://developers.cloudflare.com/cloudflare-one/identity/service-tokens/ so then in: https://registry.terraform.io/providers/Telmate/proxmox/latest I could specify those "secrets" in order to access Proxmox hosted in homelab which is behing Cloudflare Access using Terraform Cloud.

Something like this: https://github.com/hashicorp/terraform-provider-nomad/blob/main/nomad/provider.go#L103

Thanks,

Dynamically build list of available functions

Currently, the way to use this code appears to be having two terminals open. One session with the API client and another session looking at the case statements in main.go to see a list of available functions. This feels obtuse.

It would be nice to have the following or something like it

$ ./proxmox-api-go -h
Usage of ./proxmox-api-go:
  -function_list

$ ./proxmox-api-go -function_list
createQemuSnapshot
listQemuSnapshot
rollbackQemu
sshforward
sshbackward
...

[request] allow for self signed certificates

When I try this with my Proxmox Server to start/stop a VM, I get the error msg:
x509: certificate is valid for ...

I suspect it would be because of the self-signed certificate.

My command:

./proxmox-api-go -debug start 105

This works with another server which has a valid certificate.

Regards,
Shantanu

Support for latest Proxmox API

Hey, I'd like to help to add the vast majority of options available through the Proxmox API. I do have some concerns about client compatibility as I am certain not all options are supported by all versions of Proxmox's API, but unfortunately I have no experience building clients that support multiple versions of APIs.

Couple of questions to get the ball rolling:

  • What would be the best approach to get started on this?
  • What API versions does this client supports?
  • How can the latest version be supported?

Thanks!

Return a value for storage_type when reading qemu disks (or remove the need for it entirely)

I'm working on a pull request for the terraform provider, and it looks like the qemuDisk's attribute storage_type is required for the creation/update of disks within a qemu resource, but that value is not returned by a call to NewConfigQemuFromApi. This is unfortunate as I'm not able to be sure of the current value to use for storage_type after creation (to detect drift and correctly update the terraform state).

Ideally, we could remove the need for storage_type as it appears to only be used here: https://github.com/Telmate/proxmox-api-go/blob/master/proxmox/config_qemu.go#L900 in order to format the disk path correctly. Perhaps we could issue another API query to proxmox to list storage types (/storage/<storage_name>) and pull out the type attribute from there? Then we wouldn't need storage_type at all.

Or, if not the above, when a VM is read perhaps we can re-use the logic from line 900 above to return the storage_type format required (dir vs rbd for example).

Thoughts? I'm happy to attempt a contribution of either approach depending on preference.

config file prompted even for targets that dont require config

#164 created the following issue for me.

Part of my workflow involves getting a list of all VMs. This does not normally require a config file, however since GetConfig is always called now, it expects some sort of config to be directed in from stdin (which hangs indefinitely if nothing is directed) .

Is this intended? If not, I can create the PR to resolve this issue -- I just wanted to make sure if this was the intended workflow or not.

How do you compile this

Hi I have no knowledge on go . When I tried following the steps mentioned I get

[sunil@gitlab-runner ~]$ go build -o proxmox-api-go
/usr/local/go/src/proxmox-api-go/main.go:6:2: cannot find package "github.com/Telmate/proxmox-api-go/proxmox" in any of:
/usr/local/go/src/vendor/github.com/Telmate/proxmox-api-go/proxmox (vendor tree)
/usr/local/go/src/github.com/Telmate/proxmox-api-go/proxmox (from $GOROOT)
/home/sunil/projects/src/src/github.com/Telmate/proxmox-api-go/proxmox (from $GOPATH)
[sunil@gitlab-runner ~]$

Can you please help me solve this

Add missing option for QEMU VM startup order

Currently there is no option to set the startup order for QEMU VMs. The Proxmox API does provide this option.

I've already implemented the required changes, and today I'll be submitting two PRs. One for this issue, as a prerequisite for the Terraform provider, and one for Telmate/terraform-provider-proxmox#525. Both are tested and working as expected on my end.

random mac address

Hello

I have an issue with mac address randomization ( sorry for my english )
the affair :
a random mac address is correctly generated and affected, but it's impossible to setup an ip address

after boot, no ip address is set. configuration is good
when i try to ifup the interface ( eth0 ) , a have this error :

.. Cannot assign requested address ..

I change the mac address and everything works fine

I found some explanations on the web.
https://askubuntu.com/questions/423530/cant-change-my-mac-address-cant-assign-requested-address

Mac address must be a Locally Administered Unicast MAC Address ( Not sure 100% )
https://www.hellion.org.uk/cgi-bin/randmac.pl?scope=local&type=unicast

Regards

Arnaud

_root is not defined in scheme. Occuring in SetVmConfig post request, using terraform-proxmox-provider.

vmParams: map[description: onboot:false sockets:1 cores:1 memory:1024 0:media=disk,size=32,file=local-lvm:vm-103-disk-1 net0:macaddr=XX:XX:XX:XX:XX:XX,bridge=vmbr0,model=virtio]

response: &{400 Parameter verification failed. 400 HTTP/1.1 1 1 map[Date:[Day xx Nov xxxx xx:xx:xx xxx] Pragma:[no-cache] Server:[pve-api-daemon/3.0] Content-Length:[120] Content-Type:[application/json;charset=UTF-8] Expires:[Day, xx Nov xxxx xx:xx:xx xxx] Cache-Control:[max-age=0]] {{"errors":{"_root":"property is not defined in schema and the schema does not allow additional properties"},"data":null}} 120 [] true false map[] 0xc000228e00 0xc00028e8f0}

Also your vmParams net0 interface is using "type" instead of "model", throws a param verification error also

DeleteVm silently ignores a 501 response

When I call DeleteVm, it calls DeleteVmParams, which seems to ignore an error returned by the server.
After turning debug on, I get the following:

Request:

DELETE /api2/json/nodes/vme/qemu/105 HTTP/1.1
Host: vme.test:8006
User-Agent: Go-http-client/1.1
Content-Length: 2
Accept: application/json
Cookie: PVEAuthCookie=...
Csrfpreventiontoken: ...
Accept-Encoding: gzip

""

Response:

HTTP/1.1 501 Unexpected content for method 'DELETE'
Connection: close
Cache-Control: max-age=0
Date: Thu, 04 Mar 2021 19:02:38 GMT
Expires: Thu, 04 Mar 2021 19:02:38 GMT
Pragma: no-cache
Server: pve-api-daemon/3.0

However, as a caller, I get err = nil in the result of the call to DeleteVm


When I call the endpoint manually:

curl \
  -H 'Accept: application/json' \
  -H 'Cookie: PVEAuthCookie=...' \
  -H 'Csrfpreventiontoken: ...' \
  -X DELETE https://vme.test:8006/api2/json/nodes/vme/qemu/105 \
  -d '' \
  --verbose -k

it works fine and proxmox removes the VM.


This happens on 7008020 and Proxmox version: 6.3-4 (I also observed it on 6.2-11)

Interface conversion error in NewConfigQemuFromApi

One of the changes in #78 is causing an error when NewConfigQemuFromApi is called:

panic: interface conversion: interface {} is float64, not bool
goroutine 52 [running]:
github.com/Telmate/proxmox-api-go/proxmox.NewConfigQemuFromApi(0xc000443528, 0xc0005f6640, 0x0, 0x0, 0x0)
	/home/johnpc/go/src/github.com/Telmate/proxmox-api-go/proxmox/config_qemu.go:457 +0x3235

This is used by the getConfig command as well as the Terrform Proxmox Provider when cloning a template or VM.

Additionally, this flag needs to be defaulted to true where possible, otherwise it keeps the default value of false which is then passed to Proxmox when creating or updating a VM.

Add node shutdown | reboot option

Hi!

I'm working on an API to manage my personal/lab infra; I'm using this package as a go library to perform some operations over the VM but I want to also manage the node.

AFAIK, I didn't see the option to shut down and/or reboot the proxmox node.
I'll open a PR with the implementation I'm working on; let me know if you already considered not adding these features to this go library because of whatever reason.

Thanks

Adding network support

I have begun adding support to create networks on Proxmox hosts in the project dandyrow/proxmox-api-go.

Currently I have implemented createNetwork and applyNetwork functions with plans to implement the rest of the network API functionality in the near future (it is a work in progress).

Is this something that could be merged into the main project?
I'm willing to take on board suggestions to improve how I'm implementing these features to make them better / more compatible and maintainable in line with the rest of the project.

Feature Reqest: New Cli

In Tinyblargon/proxmox-api-go:CLI-Overhaul I have started working on a new CLI for the project using cobra. this library is commonly used to create a CLI in GO. it has build in features like "--help" making the project more accessible for new users.
The goal is to eventually replace the big switch statement in main with this new CLI.
The new CLI has to be enabled manually, this can be done by setting the environment variable "NEW_CLI" to "true".

Is this CLI rewrite usefull for the project?
If so should it be merged as one big pull request once the whole CLI is rewritten? Or create pull requests as i go?

createQemu gives invalid vmid error

executing the command:
./proxmox-api-go -insecure createQemu 123 pve < ../config.json
gives the following error.

error status: {"data":null,"errors":{"vmid":"invalid format - value does not look like a valid VM ID\n"}}

Clone qemu interface is nil

Performing the following request
./proxmox-api-go --debug cloneQemu cloudinit px01 < ../cloud.json
being the content of cloud.json

{
  "name": "cloudinit.test.com",
  "desc": "Test proxmox-api-go clone",
  "storage": "local",
  "memory": 2048,
  "cores": 2,
  "sockets": 1,
  "ipconfig0": "gw=10.0.0.2,ip=10.0.0.201/24",
  "sshkey" : "ssh-rsa #mysshpublic_key",
  "nameserver": "8.8.8.8",
  "fullclone": 1,
  "disk": {
    "0": {
      "type": "virtio",
      "storage": "local",
      "storage_type": "dir",
      "size": "30G",
      "backup": true
    }
  }
}

Expected result

The machine gets cloned and running with the specified parameters.

Current result

Application exits with the following error:

2018/11/22 13:37:05 >>>>>>>>>> REQUEST:
%!(EXTRA string=GET /api2/json/nodes/px01/tasks/UPID:px01:000066AE:14300677:5BF6A2ED:qmclone:9000:root@pam:/status HTTP/1.1
Host: px01.mycompany.com:8006
User-Agent: Go-http-client/1.1
Accept: application/json
Cookie: PVEAuthCookie=Authcookie
Csrfpreventiontoken: 5BF6A2ED:XNIPbOOoLdnZyjHbAHfDQn8VncM
Accept-Encoding: gzip

)
2018/11/22 13:37:05 <<<<<<<<<< RESULT:
%!(EXTRA string=HTTP/1.1 200 OK
Content-Length: 231
Cache-Control: max-age=0
Connection: Keep-Alive
Connection: Keep-Alive
Content-Type: application/json;charset=UTF-8
Date: Thu, 22 Nov 2018 12:37:06 GMT
Expires: Thu, 22 Nov 2018 12:37:06 GMT
Pragma: no-cache
Server: pve-api-daemon/3.0

{"data":{"node":"px01","pid":26286,"pstart":338691703,"exitstatus":"OK","status":"stopped","upid":"UPID:px01:000066AE:14300677:5BF6A2ED:qmclone:9000:root@pam:","starttime":1542890221,"id":"9000","user":"root@pam","type":"qmclone"}})
panic: interface conversion: interface {} is nil, not string

goroutine 1 [running]:
github.com/Telmate/proxmox-api-go/proxmox.ConfigQemu.CreateQemuDisksParams(0xc000452080, 0x12, 0xc0004520a0, 0x19, 0x0, 0x800, 0x0, 0x0, 0x2, 0x1, ...)
	/Users/myuser/go/src/github.com/Telmate/proxmox-api-go/proxmox/config_qemu.go:615 +0xd04
github.com/Telmate/proxmox-api-go/proxmox.ConfigQemu.UpdateConfig(0xc000452080, 0x12, 0xc0004520a0, 0x19, 0x0, 0x800, 0x0, 0x0, 0x2, 0x1, ...)
	/Users/myuser/go/src/github.com/Telmate/proxmox-api-go/proxmox/config_qemu.go:147 +0x39b
github.com/Telmate/proxmox-api-go/proxmox.ConfigQemu.CloneVm(0xc000452080, 0x12, 0xc0004520a0, 0x19, 0x0, 0x800, 0x0, 0x0, 0x2, 0x1, ...)
	/Users/myuser/go/src/github.com/Telmate/proxmox-api-go/proxmox/config_qemu.go:134 +0x46c
main.main()
	/Users/myuser/Development/proxmox-api-go/main.go:132 +0xfa9

The VM is cloned and remains stopped with the memory and CPU assigned but without the requested disk size.

Versions

MacOS 13.0
go 1.11.2 darwin/amd64
Latest proxmox-api-go at branch master
Proxmox 5.2-9

Output from GetNodeList is duplicated for each node

Example output from a 2 node cluster with #132

{"data":[{"level":"","type":"node","mem":191429849088,"status":"online","node":"mynode01","ssl_fingerprint":"xx:xx:xx","cpu":0.355811468877603,"maxmem":270162763776,"uptime":352804,"maxcpu":24,"id":"node/mynode01","disk":4448075776,"maxdisk":11384602624},{"type":"node","id":"node/mynode02","status":"offline","node":"mynode02","ssl_fingerprint":"xx:xx:xx"}]}
{"data":[{"cpu":0.355811468877603,"disk":4448075776,"id":"node/mynode01","level":"","maxcpu":24,"maxdisk":11384602624,"maxmem":270162763776,"mem":191429849088,"node":"mynode01","ssl_fingerprint":"xx:xx:xx","status":"online","type":"node","uptime":352804},{"id":"node/mynode02","node":"mynode02","ssl_fingerprint":"xx:xx:xx","status":"offline","type":"node"}]}

Prettily displayed as

{
  "data": [
    {
      "level": "",
      "type": "node",
      "mem": 191429849088,
      "status": "online",
      "node": "mynode01",
      "ssl_fingerprint": "xx:xx:xx",
      "cpu": 0.355811468877603,
      "maxmem": 270162763776,
      "uptime": 352804,
      "maxcpu": 24,
      "id": "node/mynode01",
      "disk": 4448075776,
      "maxdisk": 11384602624
    },
    {
      "type": "node",
      "id": "node/mynode02",
      "status": "offline",
      "node": "mynode02",
      "ssl_fingerprint": "xx:xx:xx"
    }
  ]
}


{
  "data": [
    {
      "cpu": 0.355811468877603,
      "disk": 4448075776,
      "id": "node/mynode01",
      "level": "",
      "maxcpu": 24,
      "maxdisk": 11384602624,
      "maxmem": 270162763776,
      "mem": 191429849088,
      "node": "mynode01",
      "ssl_fingerprint": "xx:xx:xx",
      "status": "online",
      "type": "node",
      "uptime": 352804
    },
    {
      "id": "node/mynode02",
      "node": "mynode02",
      "ssl_fingerprint": "xx:xx:xx",
      "status": "offline",
      "type": "node"
    }
  ]
}

Discussion: Project structure/design

Currently there is this huge package called proxmox and this huge Client class. I'm proposing at some point in the future we move the project to a new structure/design. As this project matures some things will have to change which will end up breaking peoples code. In my opinion the sooner we decide what kind of action to take the less people we will possibly upset with breaking changes.

#Proposal 1
Would it be an idea to move toward a structure where the project is a bit more split up?
So instead of having this one package called proxmox we have lots of smaller packages. Packages like qemu lxc acmeplugin acmeaccount client metrics storage user util node session validate
Example:
Currently there is a proxmox.ConfigLxc and proxmox.ConfigQemu struct.
Wouldn't it be more logical if these would be lxc.config and qemu.config

#Proposal 2
Would it be an idea to reduce the size of the Client class and move that into the qemu lxc acmeplugin acmeaccount metrics storage user node files? as currently a lot the functions in this class are only referenced once and only add a url and pass on the params map[string]interface{} variable.
Example:
this function would be moved into pool.go

func (c *Client) UpdatePoolComment(poolid string, comment string) error {
	return c.UpdateItem(map[string]interface{}{
		"poolid":  poolid,
		"comment": comment,
	}, "/pools/"+poolid)
}

And would be written as the following:

func UpdatePoolComment(c *Client , poolid string, comment string) error {
	return c.UpdateItem(map[string]interface{}{
		"poolid":  poolid,
		"comment": comment,
	}, "/pools/"+poolid)
}

#Conclusion
I understand that making these kind of changes would drastically change the look of the project.
But there is a benefit to these changes. It would give new devs and users of the project a better idea of where to find things/put new things.

By splitting up the project the auto-completion/proposals of the ide get more usable. For example: the Client class has over 120 functions which makes it difficult to use if your new to the project, and can be quite daunting if your importing this as a library.

Currently only the LXC, Qemu and pool related functions have been used in the terraform provider. Which means moving all the other code to the new style would be relatively quick. The LXC, Qemu and pool could be moved slowly with small parts at the time as to not break compatibility with the terraform provider.

#Feedback
I am wondering how my fellow contributors feel about these proposed changes.

Disk format parameter is ignored

In config_qemu format disk parameter is ignored and not sent:

https://github.com/Telmate/proxmox-api-go/blob/master/proxmox/config_qemu.go#L1088

	// Keys that are not used as real/direct conf.
	ignoredKeys := []string{"key", "slot", "type", "storage", "file", "size", "cache", "volume", "container", "vm", "mountoptions", "storage_type", "format"}

	// Rest of config.
	diskConfParam = diskConfParam.createDeviceParam(disk, ignoredKeys)

I'm using packer to create vms and disks are created only in raw format.

Why is it ignored? Is it a bug/typo?

terraform apply fails Error: vm 'ubuntu-2004-cloudinit-template' not found

Hi,
I am trying to create a VM using terraform and the cloudinit template that I have but for some reason I keep getting the error that the template is not found. The template is there

proxmox_vm_qemu.test_server[0]: Creating...

Error: vm 'ubuntu-2004-cloudinit-template' not found

  on main.tf line 22, in resource "proxmox_vm_qemu" "test_server":
  22: resource "proxmox_vm_qemu" "test_server" {

I am not sure what I am doing wrong?

`ConfigQemu.Sshkeys` are not properly URL encoded by `ConfigQemu.UpdateConfig()`

This issue shows itself when attempting to update a resource with an SSH key that has : in a comment, which is common in workflows involving smartcards and GPG-agent. Users of this package attempting to add an offending key (including through downstream projects such as in this case in the terraform proxmox provider will get an error.

For example, one of my keys ends like this:

ssh-rsa AAAA...== cardno:18 228 342

This URL encoding currently happens in ConfigQemu.UpdateConfig() on line 456.

Feature Proposal: qemu disk structure change

In the current implementation it is only possible to configure 31 disks in total. Proxmox allows you to configure 4 ide, 6 sata, 16 virtio and 31 scsi drives for a total of 57 drives. I was thinking about re-implementing this at some point in this project and the terraform provider.

Current structure

"disk": {
	"0": {},
	"1": {},
	"2": {},
	"3": {},
	"4": {},
	"5": {},
	"6": {},
	"7": {},
	"8": {},
	"9": {},
	"10": {},
	"11": {},
	"12": {},
	"13": {},
	"14": {},
	"15": {},
	"16": {},
	"17": {},
	"18": {},
	"19": {},
	"20": {},
	"21": {},
	"22": {},
	"23": {},
	"24": {},
	"25": {},
	"26": {},
	"27": {},
	"28": {},
	"29": {},
	"30": {}
}

Proposed structure

"disk": {
	"ide": {
		"0": {},
		"1": {},
		"2": {},
		"3": {}
	},
	"sata": {
		"0": {},
		"1": {},
		"2": {},
		"3": {},
		"4": {},
		"5": {}
	},
	"virtio": {
		"0": {},
		"1": {},
		"2": {},
		"3": {},
		"4": {},
		"5": {},
		"6": {},
		"7": {},
		"8": {},
		"9": {},
		"10": {},
		"11": {},
		"12": {},
		"13": {},
		"14": {},
		"15": {}
	},
	"scsi": {
		"0": {},
		"1": {},
		"2": {},
		"3": {},
		"4": {},
		"5": {},
		"6": {},
		"7": {},
		"8": {},
		"9": {},
		"10": {},
		"11": {},
		"12": {},
		"13": {},
		"14": {},
		"15": {},
		"16": {},
		"17": {},
		"18": {},
		"19": {},
		"20": {},
		"21": {},
		"22": {},
		"23": {},
		"24": {},
		"25": {},
		"26": {},
		"27": {},
		"28": {},
		"29": {},
		"30": {}
	}
}

disk creation error

I have setup terraform 0.11.11 + terraform-provider-proxmox + proxmox-api-go
I can create vm ( qemu ) without disk , with no problem

When i try to add a disk , terraform aplly hangs with this error

resource "proxmox_vm_qemu" "ljrsrv1" {
name = "ljrsrv1"
desc = "SSO VM"
target_node = "${var.vm_node}"
memory = 4096
sockets = 1
cores = 4
iso = "VMs:iso/ljrsrv1.iso"
network = {
id = 0
model = "${var.vm_net_driver}"
bridge = "${var.vm_net_bridge}"
}
disk = {
id = 0
type = "virtio"
storage = "VMs"
storage_type = "dir"
size = "50"
format = "raw"
}
}

1 error(s) occurred:

  • proxmox_vm_qemu.ljrsrvsso1: 1 error(s) occurred:
  • proxmox_vm_qemu.ljrsrvsso1: Cannot create VM disk VMs:101/vm-101-disk-1.raw

with debug mode :
2018-12-29T14:32:00.450Z [DEBUG] plugin.terraform-provider-proxmox: 2018/12/29 14:32:00 >>>>>>>>>> REQUEST:
2018-12-29T14:32:00.450Z [DEBUG] plugin.terraform-provider-proxmox: %!(EXTRA string=POST /api2/json/nodes/lrjhyp1/storage/VMs/content HTTP/1.1
2018-12-29T14:32:00.450Z [DEBUG] plugin.terraform-provider-proxmox: Host: 89.31.146.4:8006
2018-12-29T14:32:00.450Z [DEBUG] plugin.terraform-provider-proxmox: User-Agent: Go-http-client/1.1
2018-12-29T14:32:00.450Z [DEBUG] plugin.terraform-provider-proxmox: Content-Length: 49
2018-12-29T14:32:00.450Z [DEBUG] plugin.terraform-provider-proxmox: Accept: application/json
2018-12-29T14:32:00.450Z [DEBUG] plugin.terraform-provider-proxmox: Content-Type: application/x-www-form-urlencoded
2018-12-29T14:32:00.450Z [DEBUG] plugin.terraform-provider-proxmox: Cookie: PVEAuthCookie=PVE:root@pam:5C278560::YcY/5F982RVfJcrQCOptIQr6terrtsy+ds49L4Lf7eGRd9gjDB1NmmNchEqaln5+vvkt7xfVBfm+ItD1jZCgv9yUmHAulvRgLPw5Zls2USwTJisFrHWRpBTKLZSr6V/4o8v2y9mFySALjCTGc9YbJ8lYpVT5xRZAu67PHCJA4meZbYMNp9jlfBx7AW0hDGZ+czfQIkYqovsvPx4rqA6nZzUCS5JB1ahqPlGeEIirMx6gDWKBog35K3UXKD8UorVO7WdRKQ1CrvA+A89TskN0xuJwKGgD7NMPBQuYalE6W38AZrH7zaIjBtofXWI4e2ukAuAYEIackkgE4Qpnhy9aSQ==
2018-12-29T14:32:00.450Z [DEBUG] plugin.terraform-provider-proxmox: Csrfpreventiontoken: 5C278560:5Ms3bpxrWNhthstAxML68Tv+tkg
2018-12-29T14:32:00.450Z [DEBUG] plugin.terraform-provider-proxmox: Accept-Encoding: gzip
2018-12-29T14:32:00.450Z [DEBUG] plugin.terraform-provider-proxmox:
2018-12-29T14:32:00.450Z [DEBUG] plugin.terraform-provider-proxmox: filename=101%2Fvm-101-disk-1.raw&size=50&vmid=101)
2018-12-29T14:32:00.485Z [DEBUG] plugin.terraform-provider-proxmox: 2018/12/29 14:32:00 <<<<<<<<<< RESULT:
2018-12-29T14:32:00.485Z [DEBUG] plugin.terraform-provider-proxmox: %!(EXTRA string=HTTP/1.1 500 unable to parse volume filename '101/vm-101-disk-1.raw'
2018-12-29T14:32:00.485Z [DEBUG] plugin.terraform-provider-proxmox: Connection: close
2018-12-29T14:32:00.485Z [DEBUG] plugin.terraform-provider-proxmox: Content-Length: 13
2018-12-29T14:32:00.485Z [DEBUG] plugin.terraform-provider-proxmox: Cache-Control: max-age=0
2018-12-29T14:32:00.485Z [DEBUG] plugin.terraform-provider-proxmox: Content-Type: application/json;charset=UTF-8
2018-12-29T14:32:00.485Z [DEBUG] plugin.terraform-provider-proxmox: Date: Sat, 29 Dec 2018 14:32:00 GMT
2018-12-29T14:32:00.485Z [DEBUG] plugin.terraform-provider-proxmox: Expires: Sat, 29 Dec 2018 14:32:00 GMT
2018-12-29T14:32:00.485Z [DEBUG] plugin.terraform-provider-proxmox: Pragma: no-cache
2018-12-29T14:32:00.485Z [DEBUG] plugin.terraform-provider-proxmox: Server: pve-api-daemon/3.0
2018-12-29T14:32:00.485Z [DEBUG] plugin.terraform-provider-proxmox:
2018-12-29T14:32:00.485Z [DEBUG] plugin.terraform-provider-proxmox: {"data":null})
2018/12/29 14:32:00 [ERROR] root: eval: *terraform.EvalApplyPost, err: 1 error(s) occurred:

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.