Default settings of containers and virtual machines
- Thread starter iprok
- Start date
Hi,
the feature would still need to implemented: https://bugzilla.proxmox.com/show_bug.cgi?id=3500 The request does not include the "users should not be able to change them at all" yet. That would add more complexity and is rather independent of the other feature.
the feature would still need to implemented: https://bugzilla.proxmox.com/show_bug.cgi?id=3500 The request does not include the "users should not be able to change them at all" yet. That would add more complexity and is rather independent of the other feature.
That would be a great (and presumable easy to implement) quality of life upgrade
Before making this search, I compiled a list of the defaults I would like to change and the values I would like to set to streamline this process.
I imagine that veteran users mostly don't use the wizard at all, because the default are highly conservative and almost always inappropriate for my purposes !
The list
template -> debian 11
disk -> 1000G
cpu -> 32 cores
memory -> 24G
swap -> 24G
network ipv4 -> dhcp
network ipv6 -> dhcp
firewall -> off
start after created -> yes
(not a wizard option but)
console mode -> shell
Of course, beyond the defaults, it would make sense to have templates for the wizards like
"low memory linux"
"windows with gpu passthrough"
"high performance linux desktop"
"DOS"
"emulators"
"Linux CT with GPU passthrough for AI"
Do veteran users instead create CT/VM templates and then clone the template instead of using the wizard maybe ? Personnally, I hagve not figured out how to do the equivalent of "sysprep" from windows, but on linux, so I prefer to start fresh each time.
Before making this search, I compiled a list of the defaults I would like to change and the values I would like to set to streamline this process.
I imagine that veteran users mostly don't use the wizard at all, because the default are highly conservative and almost always inappropriate for my purposes !
The list
template -> debian 11
disk -> 1000G
cpu -> 32 cores
memory -> 24G
swap -> 24G
network ipv4 -> dhcp
network ipv6 -> dhcp
firewall -> off
start after created -> yes
(not a wizard option but)
console mode -> shell
Of course, beyond the defaults, it would make sense to have templates for the wizards like
"low memory linux"
"windows with gpu passthrough"
"high performance linux desktop"
"DOS"
"emulators"
"Linux CT with GPU passthrough for AI"
Do veteran users instead create CT/VM templates and then clone the template instead of using the wizard maybe ? Personnally, I hagve not figured out how to do the equivalent of "sysprep" from windows, but on linux, so I prefer to start fresh each time.
Here are a few more people asking the same thing
And the confirmation that the current workaround is to create templates and clone them, that is clunky
https://forum.proxmox.com/threads/change-defaults-when-creating-a-new-vm.71943/
https://forum.proxmox.com/threads/why-are-the-proxmox-7-default-vm-settings-so-bad.112704/
And the confirmation that the current workaround is to create templates and clone them, that is clunky
https://forum.proxmox.com/threads/change-defaults-when-creating-a-new-vm.71943/
https://forum.proxmox.com/threads/why-are-the-proxmox-7-default-vm-settings-so-bad.112704/
Yeah I for one really want to be able to customise the cluster-wide defaults for provisioning new VMs/CTs. The proposal in the listed bug report of also having profiles for configs can be useful too, but for me at least being able to _change_ the defaults would be really great! There's multiple defaults that I need to change _every single time_ and building templates is not a good enough universal solution.
This may be the only viable option. Create it youself so that it fits your needs.
Yes, templates suck because requirements change a lot. Do automatic (network) installations and customization. This is the only way to get exactly what you want.
Network booting has no real capability of configuring the VM/LXC objects within Proxmox VE itself, which really is what this is about.
I certainly love the ability in Open Source stuff to write our own integrations/automations, but I do believe genuinely long-term this is worthwhile for the Proxmox VE Ecosystem. Being able to at a minimum change the defaults for creating new VMs/LXCs, but if we could get profiles that would be a cherry on top, so to say.
For containers, I get the netboot part, yet for VMs? I don't understand, can you please elaborate?
We have pxe boot and dhcp-based profiles so that we can create create a VM, register the mac in the dhcp and automatically install the VM based on defined profile. After the install is done, we have a fully configured and updated VM ready to serve.
I'm talking about configurations at the hypervisor level, not the guestOS level. This supersedes network boot for anything as that's post-BIOS init.
I'm talking about changing the default configurations when trying to create a new LXC/VM within Proxmox VE, the defaults as Proxmox sees them.
I do believe you're getting muddled up here.
Thank you for clearing this up. Yes, I feel you and we just switched over to create the VMs via the API how we like it.
Ahh nice! I can see the appeal of APIs, but there's use-cases I have where the webGUI is the method used, hence interest in this.
+1 for this as well. I like having the templates for the OS etc, but I still need to enter the same information every time on the creation wizard to actually get the container created.
If we could set defaults it'd be a lot slicker.
I like the idea of setting up different named 'profiles' of those defaults, relevant to containers or VMs. That would be even better.
To be clear, I do this to make it an actual 'LXC template' https://doofer.org/2024/06/07/making-a-proxmox-vm-in-to-an-lxc-template/
If we could set defaults it'd be a lot slicker.
I like the idea of setting up different named 'profiles' of those defaults, relevant to containers or VMs. That would be even better.
To be clear, I do this to make it an actual 'LXC template' https://doofer.org/2024/06/07/making-a-proxmox-vm-in-to-an-lxc-template/
Last edited:
As part of the Create LXC/VM dialog overhaul, I suggest that it could pipe settings directly from helperscripts.com
It would be create to just hit create LXC, choose vaultwarden, paste your ssh key and click create, and this could work forever script available on that platform
It would be create to just hit create LXC, choose vaultwarden, paste your ssh key and click create, and this could work forever script available on that platform
This aspect SHOULD NOT rely on a third party from the Proxmox group itself. Those scripts are well intentioned, but are NOT sufficiently vetted for security functions. Proxmox VE clusters are used in many sensitive environments and this can lead to very real, and potentially wide-spread, security risks.
@BloodyIron
The alternative to using, the only and best sources of these scripts, is for the proxmox script to either vet or remake all of these scripts, which obviously they do not have anywhere near the resources to do.
Sometimes we cannot let security try to wrap the entire planet in bubble wrap because there is no possible end to the "security concerns".
And sure if we had infinite time to burn gas on this issue then yes, it could be made the extra 0.00001% more secure, but some of us, actually have things to do beside muck about in a convoluted web interface.
I'm sorry that making proxmox more usable could make the business model of doing it for other people less economically viable, but proxmox should get with the times already.
I for one, am very tired of wasting whole weekends making simple things works. I want it to work and stop this endless wastage of our time, re-solving the same problem over and over again.
Which, BY THE WAY, rolling your own interpretation of a vaultwarden server, compared with running the script, do you really think that in most case that's more likely to be secure ? I don't think so. I don't think it's even a reasonable position to believe that.
The alternative to using, the only and best sources of these scripts, is for the proxmox script to either vet or remake all of these scripts, which obviously they do not have anywhere near the resources to do.
Sometimes we cannot let security try to wrap the entire planet in bubble wrap because there is no possible end to the "security concerns".
And sure if we had infinite time to burn gas on this issue then yes, it could be made the extra 0.00001% more secure, but some of us, actually have things to do beside muck about in a convoluted web interface.
I'm sorry that making proxmox more usable could make the business model of doing it for other people less economically viable, but proxmox should get with the times already.
I for one, am very tired of wasting whole weekends making simple things works. I want it to work and stop this endless wastage of our time, re-solving the same problem over and over again.
Which, BY THE WAY, rolling your own interpretation of a vaultwarden server, compared with running the script, do you really think that in most case that's more likely to be secure ? I don't think so. I don't think it's even a reasonable position to believe that.
This isn't about making it more secure, this is about NOT making it less secure by placating a bad idea which would tangibly make the supply chain of software less secure. I'm not going to sit here and give you the education you need on why supply chain matters... _especially when we're talking about a clustered hypervisor that can run thousands of VMs at any one time_.
If you have issues with _specific features that exist_ filing reports for feature improvements or bug reports is the most productive thing for you to do to help the ecosystem. That's actually how a lot of positive change has happened within the Proxmox VE environment for decades now, so go make your bugzilla account and go down that avenue.