>>mhmm.. in the backend we don't actually have a limit, maybe it's time >>to remove the limit in the ui >>altogether? it does not help anyway:
>>for numbers that are not too big (too many for qemu, too many for the >>host) >>it's not the right limit (qemu) or we don't know at that point in the >>gui (host cores) >>but in case next year there is e.g. a 512 core machine, the limit is >>too low again... >>so i'd be either for >>* removing the limit at all >>* limit to the qemu limits (but maybe also in the backend?) >>* use the number of cores of the current host as limit in the gui >>(should be possible, but an >>additional api call) >> >>what do you think? Yes, indeed the backend don't have any limit. We could indeed remove the limit in the gui. I think we shouldn't limit based on the current host, as anyway, we can create && migrate the vm on antoher host just after the create. Maybe an improvement in qemu-server, could be to add additional check at vm start, (maybe a simple warn), depending of qemu version or setup. For example, 1024 cores only works with q35 && qemu 8.1, it could be interesting to give an clean hint mesage to user instead a qemu process error. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
