Proxmox Datacenter Manager - First Alpha Release

I think I communicated that the wrong way - is the PDM API and the docs publicly available now, or is it something that will come in the future?
It's not easily available in a nicely prebuild form, but you could manually build the docgen binary from the source code to let it spit out the JSON definition of the current API.

The prebuild publicly available web app allowing one to browse the API comfortably, like it exists for PVE or PBS already, is indeed something that will come in the future.
 
Last edited:
when adding endpoint, I have noticed duplicate of the node that I have used for initial connection.
 

Attachments

  • Capture d’écran du 2024-12-20 07-40-02.png
    Capture d’écran du 2024-12-20 07-40-02.png
    85.8 KB · Views: 58
  • Capture d’écran du 2024-12-20 07-40-28.png
    Capture d’écran du 2024-12-20 07-40-28.png
    131.7 KB · Views: 56
Will we get some sort of embeded fully featured Webinterface which proxies the calls via PDM to PVE/PBS so that we don't have to ever go onto the Webinterfaces directly?
Quite probably: no. The PVE interface and functionality is very complex as it offers a ton of functionality, that while all of it is important for some set of users, a lot of it is not often required by all users equally, or is going to be used only occasionally (e.g., setup once, check only on problems). The PDM reimplementing all that plus the not so small interfaces of all other projects like PBS and PMG would make it rather unusable.

In a very reduced essence it's intended to let PDM cover the most of the basic daily/weekly operations and provide an overview for resource usage and potential problems, allowing one to move stuff between different nodes/clusters even if they are not connected and a global SDN view/management and so on, but not to re-expose every knob PVE or PBS have. For the edge cases already offers a link directly to the resource – this can still be improved w.r.t. accessing the correct URL or potentially proxying that connection over the PDM, but that's for the next months to flesh out.
Also, can we specify which address is used to open links to the Webinterfaces? My Browser can't access my PVE Nodes via the same IP's as my PDM can and i can't use Split DNS since they have different ports due to me using reverse proxy for browser access.
Yeah, that will be a problem for a few users and definitively something we try to improve on. The simplest thing might be to allow defining a "web URL base template" for remotes that is used for the open-resource UI functionality.
 
Last edited:
when adding endpoint, I have noticed duplicate of the node that I have used for initial connection.
Yes, that is a bit bare bones now, how to better detect all FQDNs/addresses the PDM and that cluster can talk with each other is also something we would like to improve.
 
I have a bug, I have added multiple remotes, and I only have the rrds for the last one I have added

1734678821828.png1734678858461.png


BTW, as it's a new product, couldn't it be better to use some kind of metric database like prometheus,victoria metrics, .... instead rrd files ? This could help to have better graph precision, be able to add new counters easily (rrd suck for this), query across multiples vms. (vm loadbalancer ?) , have alerting metrics , ....
 
I seem to be having trouble migrating a VM between clusters, getting the error message "api error (status = 501 Not Implemented)" when I click migrate. The VM is offline, and the source and destination clusters are using Ceph. Host nodes both have Community subscriptions, and I've made sure that libpve-storage-perl is up to date.

1734681246682.png
 
I seem to be having trouble migrating a VM between clusters, getting the error message "api error (status = 501 Not Implemented)" when I click migrate. The VM is offline, and the source and destination clusters are using Ceph. Host nodes both have Community subscriptions, and I've made sure that libpve-storage-perl is up to date.

View attachment 79474
IIRC that is a red herring and indicate that the source remote cannot resolve the hostname of the target remote.
Definitively something to improve, not only implementation wise but also w.r.t. more telling error handling :)
 
IIRC that is a red herring and indicate that the source remote cannot resolve the hostname of the target remote.
Definitively something to improve, not only implementation wise but also w.r.t. more telling error handling :)
Interesting. Is there a way I can try to verify that? Running dig from both sides against each others' hostnames seems to be working as expected.
 
Yeah, that will be a problem for a few users and definitively something we try to improve on. The simplest thing might be to allow defining a "web URL base template" for remotes that is used for the open-resource UI functionality.
This would definitely be useful. We use an alias which is different from the hostname when accessing the PVE UI. Making this experience consistent when coming from PDM is desirable.
 
thats so cool, just wanted to say thank you to the whole team. Thats exactly what I needed. I've installed it in a lab environment and it runs great so far. I am very looking forward to the further development of PDM.

Btw. I couldn't find the repo under git.proxmox.com - it it maybe not publicly listed yet?

Merry Christmas and happy new year!
Alex
 
Last edited:
  • Like
Reactions: 4f1sh3r
This is a huge step in the right direction!

I just hope that you can effectively combine the essential functions of vCenter and Cloud Director. Once this is achieved, Prox will become a real competitor to Broadcom, especially for small companies and clusters. VMware's Cloud Essential is really lacking—it’s expensive and, as a result, not suitable for small users.

One major upgrade that’s needed, either for this or directly for VE, is the ability to configure and visualize CEPH Crush mappings. Currently, everything has to be done via the CLI. It would also be great if it were possible to automatically combine HA groups and CEPH Crush zones without the need for extra planning and documentation.

It would also be nice to have a performance advisory feature in the future, which would monitor resource usage and allocation at the cluster, host, and VM levels. This could help optimize resource usage as efficiently as possible. For example, it could track real memory and CPU usage and suggest adjustments, such as reducing resources for a VM that isn’t utilizing them fully, or increasing resources where needed. This would be especially useful since RAM ballooning and KSM are not recommended in production environments.

Additionally, it would be great if we could finally get an active load scheduler in Proxmox, either controlled by PDM or VE. In many cases, it’s easier to move VMs with lower intensity workloads to another host when a specific VM is doing intensive work. The current auto-balance on start is no longer enough if Proxmox is to be considered a serious platform for selling capacity. In this case, over-provisioning becomes essential, and the importance of tools to manage that over-provisioning increases significantly.
 
  • Like
Reactions: 4f1sh3r
IIRC that is a red herring and indicate that the source remote cannot resolve the hostname of the target remote.
Definitively something to improve, not only implementation wise but also w.r.t. more telling error handling :)
Following up on this, I can see pveproxy on the source remote returning 501 in the access.log:
"POST /api2/extjs/nodes/prox-cpu1/lxc/105/remote_migrate HTTP/1.1" 501 -

When I use pvesh to query the available methods for the above resource, there's no `remote_migrate` endpoint.
Code:
root@prox-cpu1:~# pvesh create nodes/prox-cpu1/lxc/105/
nodes/prox-cpu1/lxc/105/clone         nodes/prox-cpu1/lxc/105/interfaces    nodes/prox-cpu1/lxc/105/resize        nodes/prox-cpu1/lxc/105/snapshot      nodes/prox-cpu1/lxc/105/termproxy
nodes/prox-cpu1/lxc/105/config        nodes/prox-cpu1/lxc/105/migrate       nodes/prox-cpu1/lxc/105/rrd           nodes/prox-cpu1/lxc/105/spiceproxy    nodes/prox-cpu1/lxc/105/vncproxy
nodes/prox-cpu1/lxc/105/firewall      nodes/prox-cpu1/lxc/105/pending       nodes/prox-cpu1/lxc/105/rrddata       nodes/prox-cpu1/lxc/105/status        nodes/prox-cpu1/lxc/105/vncwebsocket

I actually fully rebooted the node, just to be sure there wasn't some old process running somewhere.
 
We have successfully installed PDM on a system and have configured your clusters.

The Migration of a VM (Online) from one cluster to another Worked so far.
If I encounter any problem and Bug i will make a future Post.

Thank you for this cool and helpful Tool :)
 
Adding a node with self-signed certificate does not work.
1734697217824.png
1734697238791.png

Using pveproxy-ssl.pem fingerprint also does not work. :(
1734697276798.png
1734697417933.png
On port 8006 of the host I see the following fingerprint:
Bash:
$ openssl s_client -connect host.fqdn.local:8006 < /dev/null 2>/dev/null | openssl x509 -fingerprint -sha256 -noout -in /dev/stdin
sha256 Fingerprint=BA:94:E6:94:CC:15:D0:DA:C5:C2:18:54:21:6E:93:F7:EF:38:2B:44:D5:A4:6C:45:A2:2E:89:41:4C:22:BB:F0
 
Quite probably: no. The PVE interface and functionality is very complex as it offers a ton of functionality, that while all of it is important for some set of users, a lot of it is not often required by all users equally, or is going to be used only occasionally (e.g., setup once, check only on problems). The PDM reimplementing all that plus the not so small interfaces of all other projects like PBS and PMG would make it rather unusable.

In a very reduced essence it's intended to let PDM cover the most of the basic daily/weekly operations and provide an overview for resource usage and potential problems, allowing one to move stuff between different nodes/clusters even if they are not connected and a global SDN view/management and so on, but not to re-expose every knob PVE or PBS have. For the edge cases already offers a link directly to the resource – this can still be improved w.r.t. accessing the correct URL or potentially proxying that connection over the PDM, but that's for the next months to flesh out.
Just an iFrame which proxies the Connection via PDM and uses PDM's authentication to show PVE's Webinterface would already be a good Solution and should be relatively easy to implement.
But if your considering jumping ship from ExtJS to Rust for PVE too, then it might make sense to develop the New Rust PVE Webinterface as a package for PDM and once its feature complete, ship it on PVE, replacing the old ExtJS one.

Yeah, that will be a problem for a few users and definitively something we try to improve on. The simplest thing might be to allow defining a "web URL base template" for remotes that is used for the open-resource UI functionality.
Good to hear, can't wait.
 
How to I add a translation?
I want to contribute to translation
 
Last edited:

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!