Search results

Are there any plans to improve this? Having to log in to each node to check the logs/tracking/queue seems a bit add odds with the clustered nature. At least, it would be a good idea to be able to do this via the GUI to select a node like that can be done with PVE.

This does not work. The only way to work around it is disable the fw at datecentre level which means all HV nodes as well as VMs are unprotected. We'll check out the SDN stuff once it becomes non-experimental.

The issue is the same as reported. Whilst the thread is from 2015, there is at least one other post from Feb 2020 which had no reply hence why I opened this afresh. Essentially this relates to conn tracking. In our case, we're running BGP with VRRP against two difference proxmox servers (with...

As per https://forum.proxmox.com/threads/firewall-enabled-in-datacenter-prevent-bridge-vm-comunication-on-the-same-node.21372/page-2, this appears to affect many. The suggested rule change of iptables -D PVEFW-FORWARD -m conntrack --ctstate INVALID -j DROP does "resolve" this although may not...

We'd love that to be true but it isn't. Over 60% of our customers administer/play with their settings on a regular basis.

Nope, these would be for shared/reseller hosting customers. So one install per customer would be unworkable.

Thanks for confirming that. It would be nice if you could tie entries like white lists, rules and so on to domain - so when the domain is deleted, they are too to prevent domains being removed and things being left in the system for non-existent names,

I did consider that although I think it would get quite and overly complex. Users would want to change their own settings, which they can do right now, so removing that would cause an increase in queries for us to do things manually. We also use S/E and things like blocking protected archives...

I've been playing with PMG this afternoon and whilst I like the idea and clustered setup of the platform, i'm not too sure if this is suitable for a hosting environment (many servers, users between them). The settings appear to be fairly global with no ability to add a domain and have specific...

Already using them for wider management and for our internal VMs but would like to do this filtering on customer VM which they cannot see or change which as far as I know won't help with. Some ports need to be blocked at the entry point to stop those customers who have VMs which are just not...

This isn't so much a support request but a feature improvement. Currently you can set firewall rules on the cluster/dc level, hv/node and VM. We would like to apply some rules at the highest level that filter down to VM, such as ports we want to block for all users (i.e malicious ports used...

As requested. proxmox-ve: 6.1-2 (running kernel: 5.0.15-1-pve) pve-manager: 6.1-3 (running version: 6.1-3/37248ce6) pve-kernel-5.3: 6.0-12 pve-kernel-helper: 6.0-12 pve-kernel-5.0: 6.0-11 pve-kernel-5.3.10-1-pve: 5.3.10-1 pve-kernel-5.0.21-5-pve: 5.0.21-10 pve-kernel-5.0.15-1-pve: 5.0.15-1...

Is there a fix on this? Still an issue on the latest release.

We had this issue with Deb 10 in latest proxmox. So with a bit of config changes and additions to cloud.cnf in the image now works fine. Add a known working resolver to resolv.conf in the image (i.e 8.8.8.8 - this will get overwritten). The the following to the bottom of cloud.cfg. I've left...

proxmox-ve: 6.0-2 (running kernel: 5.0.21-2-pve) pve-manager: 6.0-12 (running version: 6.0-12/0a603350) pve-kernel-helper: 6.0-12 pve-kernel-5.0: 6.0-11 pve-kernel-4.15: 5.4-6 pve-kernel-5.0.21-5-pve: 5.0.21-10 pve-kernel-5.0.21-2-pve: 5.0.21-7 pve-kernel-5.0.21-1-pve: 5.0.21-2...

We've upgraded to the latest release 0-12 but this still fails, even when setting the storage on the command line. root@i:/mnt/pve/images/dump# qmrestore vzdump-qemu-162-2019_11_22-02_35_22.vma.gz 90003 --storage core-hdd restore vma archive: zcat...

Sorry, I don't have the steps or any access to OnApp any longer.

Can be done, requires a bit of work but was a while ago now so don't have the exact steps. Essentially it was get the running VM on OnApp to an image, copy it over, mount the disk and dd it across. We have them all running now on Proxmox.

It may be worth posting what version of cloud-init should be used (as a minimum). The one in CentOS 7 seems to suffer the same issue.

Great thanks. Will wait for that to be pushed out to an update. :)