Search results

Looking through most recent threads on resizing, I can see wiki links on how to do this via commands within the VM but nothing specific outside of the VM. We want to automate this so if an order comes in for an increase it can happen without user involvement or needing to get in to the VM...

Whilst that may be the case, it appears others have adjusted around any issues with cloud-init. Given that CentOS is very popular, simply sticking your feet in and saying "not our problem, get them to fix" is not a workable solution. As someone else has done, we could patch but then this is...

Just to add, similar to the other report. We have the exact same problem. dns-nameservers and dns-search are added to lo instead of eth0 # This file is generated from information provided by # the datasource. Changes to it will not persist across an instance. # To disable cloud-init's network...

Well, technically how it is done is as explained. So maybe you can add something where with a VM you set the IPs used and it creates the last example automatically based on the MAC and the IPs listed against the VM preferably via the API. Currently, in a shared environment, proxmox isn't great...

The GUI itself isn't relevant as i've explained how it works as you can see from the host node via the command line. The node sets what IPs can be used and communicate to/from the VM and this is regardless if the firewall is enabled or disabled on the VM. Even if the user sets their VM firewall...

What about where the system admin wants to limits what IPs a VM should be able to use but still allow the user to allow all traffic to those IPs? If we don't enable the firewall per VM, the IPsets where allowed IPs can be set don't work. Look at Onapp, which does do this. You set the IPs on the...

Hi All, So we're playing with "ipfilter-net*" to specifically state what IPs a VM is allowed to use - that works fine. However, if the INPUT firewall is set to ACCEPT, it allows all traffic to any IPs and not just those in the IPset. I would say that the INPUT needs to still honour what is...

Interesting. What if the user removes/stops the agent? What would then happen?

Not ideal, we don't want to do anything within the VM itself. Previous software set these rules on the host node. No, they are not. As noted, the only way to do this in the GUI would be for admin to create a rule in and out but users could then alter their own specific VM rules. There is no way...

I'm already aware of that but my question is not addressed, really. "Does Proxmox have any plans where an IP/or list of can be assigned to the VM in the interface and on the host node and ensure that only traffic to or from that/those addresses will flow." Not in the existing fire-wall rules...

With KVM VMs at least, the IPs are on a sort of free-for-all. We could create an inbound and outbound firewall route so they can only use their assigned IPs but that is quite labour intensive and still means they can at least add an IP alias and ARP will do nasty things. Does Proxmox have any...

That's all been checked. We run an identical configuration on another cluster too. Switch reports no errors in logs or errors on the ports. As the network is internal, there isn't any router to contend with.

Noted but sadly that's just not what we're seeing. I wish it was. :(

That still leaves some unanswered questions and also a possible solution, if any, to the issue where a single VM could saturate sessions, causing massive instability on a cluster with nodes rebooting all over the place. Could be hard to stop too if the nodes keep rebooting before you can...

Well, we disabled HA on all the VMs when this occurred last time so nothing had moved around this time. c1-h5-i and c1-h9-i reported "table full, dropping packet" but didnt get fenced or reboot. Could the other nodes reboot because either of those nodes tell them to? Can you tell what...

I assume that this could be any of the VMs also so any of those that have high connections could impact the node entirely. We had a far higher limit set than we were using with Xen. Although, the conntrack errors only appeared on two nodes that didn't restart at all.

It's on it's own network 10.x space on the second NIC. Backups are not enabled and looking at traffic graphs, nothing more than usual, few Mbit/s. Public traffic is on the first NIC.

Here:

Nothing as far as I am aware. Everything was stable and that was the first node that went down and some others followed after. How is it setup? Could you elaborate on what information you want so I can provide.

I can confirm tested and working without issue over an extended period of time.