Recent content by aaron

The API approach (e.g. with pvesh) is probably the best approach. If you are unsure which calls are of interest, do the procedure via the web UI and take a look at the browser's developer tools, especially the network tab, to see which API calls are involved in each step.

My guess is, since host mem usage and mem usage show the same value, that the VM does not report back any detailed information. You can check that in the Monitor submenu of the VM and run info balloon there. Compare the output from a VM that reports it correctly to see the difference in infos...

VLAN tag 1 is usually the default untagged VLAN. As in, those packets won't get a VLAN tag added when they leave the physical interface. But whenever you assign one of the SDN VNETs to a guets virtual NIC, any packet leaving the host should get the set VLAN tag assigned. One can check that with...

looks better :) the subnets are useful to define as the info there will pre-populate firewall aliases. you then need to apply it on the main SDN panel

Having multiple vmbr interfaces with the same physical bridge port doesn't sound like a good idea. I would definitely recommend that you set up a SDN VLAN zone with vmbr0 as the base bridge for it and go from there for all the VLANs that should be accessible by the guests.

VLANs can be tricky to debug. If your switch supports it, give it an IP in the VLAN, then you can check if the connection to the switch works. For guests, by now I recommend that you use the SDN VLAN zone. It is one easy place to have every VLAN. In a cluster it makes life a lot easier, but also...

The post-stop won't show up in the task log (if that is what you mean), as it will be run after that task has finished by the daemon cleaning up after a VM has shut down. Writing to a file would be one way to check if the post-stop ran. If there is a bug, please report it at our bugtracker...

This is a screenshot from pre PVE 9, though, right?

Sehr cool! Hast du überlegt, das, in welcher Form auch immer, direkt bei Virtio als Installationsschritt upzustreamen?

Besides the Ballooning Device being enabled, is the BalloonService running in the Windows VM? Does it go down after a bit of waiting? In the screenshot, the VM has an uptime of 36 seconds... chances are that the VM hasn't fully booted yet and therefore the BalloonService might not be running yet.

This looks like something went wrong with the installation medium. Verify that the ISO you downloaded is correct, and that it is copied correctly to the install medium: https://pve.proxmox.com/pve-docs/pve-admin-guide.html#installation_prepare_media

https://pve.proxmox.com/wiki/Upgrade_from_8_to_9#VM_Memory_Consumption_Shown_is_Higher this should answer it :)

You mean booting the OS itself from a multipathed LUN? It might be technically possible to do so, especially when converting a Debian installation to Proxmox VE, but this is not a scenario we test for or have in mind with the Proxmox installer.

You could set the multiqueue for the virtual NIC(s). But not higher than the number for vCPUs the VM has.

? If you use the same encryption key you will get good dedup. For example, in a Proxmox VE cluster, you will use one encryption key per storage config. So if you have a second Proxmox VE cluster that is using the same PBS and datastore (ideally separated by namespace), you could upload the same...