Import disk from file using API

[anzure]

I know that you can import disk from file to VM using CLI:
qm importdisk 9000 bionic-server-cloudimg-amd64.img local-lvm

However I want to do this using the API, but there is no endpoint for that.
I have attempted to change the configuration and move the disk..

VM config is set to:
POST /api2/json/nodes/pve/qemu/9000/config

vmid=        9000
name=        ubuntu-tmp
net0=        virtio,bridge=vmbr0
memory=        2048
scsihw=        virtio-scsi-pci
scsi0=        local:iso/bionic-server-cloudimg-amd64.img
ide2=        local-lvm:cloudinit
bootdisk=    scsi0
boot=        c

Moving the disk:
POST /api2/json/nodes/pve/qemu/9000/move_disk

disk=        scsi0
storage=    local-lvm

Every attempt has just resulted in "no bootable devices found" (bios error).
And it works perfectly fine when using the CLI importdisk command.

Any suggestions for a workaround?

 

[anzure]

Bump

 

[fiona]

Hi,
we are working on adding such an API endpoint. Could you try placing the image as images/9000/bionic-server-cloudimg-amd64.qcow2 rather than as an ISO image? Use qemu-img info bionic-server-cloudimg-amd64.img to make sure the format is actually qcow2 first. (It was for the image I found online.)

 

[supermario87]

A bit of necroposting confirming that taking the image file from storage:iso/image does not work with the API endpoint move_disk

It only works with qm importdisk cli utility(in fact, importdisk can take the image from any path)

Any updates on the importdisk functionality in the API endpoint @Fabian_E ??

 

[fiona]

Any updates on the importdisk functionality in the API endpoint @Fabian_E ??

Sadly, I cannot give any time estimate when the feature will be available. I'm afraid it might still take a while.

 

[fiona]

The feature is available with qemu-server >= 7.1-5. Rather than it's own API endpoint, there is an import-from property that can be used when setting the VM drive. For example

pvesh set /nodes/pve701/qemu/105/config --scsi1 local:0,discard=on,import-from=myzpool:vm-123-disk-0
...
create full clone of drive scsi0 (myzpool:vm-123-disk-0)
...
scsi1: successfully created disk 'local:105/vm-105-disk-1.raw,discard=on,size=103M'

with <target storage>:0 being required syntax. This can also be used upon VM creation.

EDIT: For completeness, I should mention that you can also specify an absolute path as an import source.

 

[dermorz]

with <target storage>:0 being required syntax. This can also be used upon VM creation.

EDIT: For completeness, I should mention that you can also specify an absolute path as an import source.

I cannot confirm that:

curl -XPOST --silent -v --insecure -H "Authorization: PVEAPIToken=$(cat ./proxmox-api-token.txt)" -H "Content-Type: application/json" \                                                              
--data '{"vmid": 102, "scsihw": "virtio-scsi-pci", "virtio0": "local:0,import-from=/var/lib/vz/template/iso/ubuntu-server-cloudimg-amd64.img", "agent": 1, "serial0": "socket"}' \
https://192.168.121.209:8006/api2/json/nodes/bullseye/qemu
HTTP/1.1 500 Only root can pass arbitrary filesystem paths. at /usr/share/perl5/PVE/Storage.pm line 539.

 

[fiona]

I cannot confirm that:

curl -XPOST --silent -v --insecure -H "Authorization: PVEAPIToken=$(cat ./proxmox-api-token.txt)" -H "Content-Type: application/json" \                                                             
--data '{"vmid": 102, "scsihw": "virtio-scsi-pci", "virtio0": "local:0,import-from=/var/lib/vz/template/iso/ubuntu-server-cloudimg-amd64.img", "agent": 1, "serial0": "socket"}' \
https://192.168.121.209:8006/api2/json/nodes/bullseye/qemu
HTTP/1.1 500 Only root can pass arbitrary filesystem paths. at /usr/share/perl5/PVE/Storage.pm line 539.

The error message tells you exactly what the problem is. Being able to pass arbitrary paths is a security risk, so it needs to be limited.

 

[dermorz]

I don't disagree on that. I was just confused that it didn't match with what you said earlier in this thread. I was btw authenticated with root@pam with an unrestricted API Token, so the error message was also a bit misleading.

 

[fiona]

You just need the proper permissions to do it. Being authenticated with an API token for root@pam is not the same as being authenticated as root@pam. Otherwise, tokens for root@pam would be a security risk too.

 

[dermorz]

Alright, good to know. But even if I had the proper permissions, it would fail again in the end by telling me that the image not an image, but an iso. Right? (See https://forum.proxmox.com/threads/new-vm-from-cloud-init-image-via-api.111091/#post-482517)

Thanks for all the answers!

 

[fiona]

It should work. IIRC, the content type check shouldn't be done when using absolute paths.

 

[dermorz]

Interesting. Maybe this is worth exploring then. But on the other hand, I am not sure if it's a good idea to require the user of an integration to have full permissions, if that integration's purpose is just to spin up VMs.

But just for completeness sake: Would the absolute path always be /var/lib/vz/template/iso/<filename> or does it depend on the storage attached and used, right? Would there be a deterministic way to get the absolute path via API?

 

[fiona]

Interesting. Maybe this is worth exploring then. But on the other hand, I am not sure if it's a good idea to require the user of an integration to have full permissions, if that integration's purpose is just to spin up VMs.

Yes, of course. I agree that there is no good workflow for this at the moment. I just created the relevant enhancement request.

But just for completeness sake: Would the absolute path always be /var/lib/vz/template/iso/<filename> or does it depend on the storage attached and used, right? Would there be a deterministic way to get the absolute path via API?

It does depend on the storage. You can GET /storage/<storage ID> whose result includes the base path of the storage. The rest of the path is template/iso/<name of image>