mirror of
https://github.com/luthermonson/go-proxmox.git
synced 2026-04-26 01:15:57 +03:00
[GH-ISSUE #145] API calls for doing a disk import? #35
Labels
No labels
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/go-proxmox#35
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @justinclift on GitHub (Apr 29, 2024).
Original GitHub issue: https://github.com/luthermonson/go-proxmox/issues/145
Trying to do a disk import, as would be done using
qm disk import, but remotely using the API:Not really seeing anything obviously correct for this, and nothing suitable is showing up in the official API viewer either as I look through it.
Anyone have suggestions? 😄
@justinclift commented on GitHub (Apr 29, 2024):
Hmmm, this might be the correct API call:
https://pve.proxmox.com/pve-docs/api-viewer/#/nodes/{node}/storage/{storage}/content
Will probably try that out later on today. 😄
@justinclift commented on GitHub (Apr 30, 2024):
That API end point can indeed create new VM disk/volume definitions:
That creates the new ZFS volume in the
local-zfsstorage, and also creates the matching (empty) ZFS volume in the backend ZFS pool.I'm not (yet) seeing how to fill that volume with actual disk data though. If the Go code was running on the server then it could just directly write into the disk device.
But how to do it remotely? That's the next needed step.
@justinclift commented on GitHub (Apr 30, 2024):
Looking at the
qmsource code, it seems like the loading of data into the newly created volume is done byqemu-imgrunning on the node itself and writing directly into the destination device:github.com/proxmox/qemu-server@54aa98cea5/PVE/QemuServer/ImportDisk.pm (L76)github.com/proxmox/qemu-server@54aa98cea5/PVE/QemuServer.pm (L7835-L7862)That may mean there's no mechanism in place (yet) for uploading disk images remotely via the API. Well, data other than ISO images and templates.
Will probably need to ask on the Proxmox forum somewhere, or pve-devel mailing list. 😄
@justinclift commented on GitHub (May 23, 2024):
Looks like this isn't yet possible. 😦
https://forum.proxmox.com/threads/proxmox-api-import-disk.68171/
@luthermonson commented on GitHub (May 23, 2024):
well that's a bummer
@AndreiLacatos commented on GitHub (Nov 29, 2025):
Kinda late to the party but figured out you can import a disk by specifying
STORAGE_ID:0andimport-from.The following snippet is the equivalent of the above
curlrequest:Notice that it requires root auth credentials instead of API token. Have not figured out how replace that with an API token, seems like it refuses to do anything even if the API token is issued for
root@pam@justinclift commented on GitHub (Nov 30, 2025):
While that's useful, it seems like the Proxmox API still doesn't allow for directly passing the actual image content itself in the call. So, it's still relying on a previous upload of the image to a location accessible via (for example)
file://.Really wish they'd get the last outstanding piece of this puzzle implemented, so people could just pass the entire image via API instead. Without that last piece, the API isn't complete enough to be a replacement for just a series of ssh calls. ☹️
@AndreiLacatos commented on GitHub (Nov 30, 2025):
If you have the luxury to edit files on the Proxmox environment:
Found a dirty hack/workaround that you can apply to the authorization process.
/usr/share/perl5/PVE/Storage.pmhandles path check & authorization, that is where theOnly root can pass arbitrary filesystem paths.error originates from. Instead of$user ne 'root@pam'you could do something like$user ne 'johndoe@pam!sometoken'to allow a specific API token.Could be fine if you are running Proxmox in a sealed/sandboxed environment in single node setup as hobbyist.
Note: with high probability, Proxmox updates at one point might overwrite these changes
Note: production usage strongly discouraged
@jqueuniet commented on GitHub (Nov 30, 2025):
Regarding the API token issue, it's indeed related to
root@pambeing hardcoded all over the source code. There's a patch for adding asys.Rootpermission that has been rotting away on mailing lists and butrackers for years.https://bugzilla.proxmox.com/show_bug.cgi?id=2582