Hey,
[1] is the place for things like this. You can perform bulk actions based on tags, and tags are basically (more flexible) folders :)
[1] https://bugzilla.proxmox.com/
Hey,
looks like the host (127.27.1.3) does not tag its traffic. You probably want to move the IP assignment from vmbr0 to vmbr0.1
auto vmbr0.1
iface vmbr0.1 inet static
address 172.27.1.3/24
gateway 172.27.1.1
so the host traffic is tagged.
Alternatively bridge-pvid 1 is also an...
Den cluster namen solltest du auch über /cluster/config/totem [1] bekommen. Sollte cluster_name sein, also data.cluster_name in deinem Beispiel dann.
[1] https://pve.proxmox.com/pve-docs/api-viewer/index.html#/cluster/config/totem
Yes. You should try to keep nodes as close as possible version wise, but it is not a requirement to have them at the exact same versions. Live migrations also work, as long as:
*major version, so PVE 7, PVE 8. Within the same major version it'll always be supported.
Also for the upgrade please...
I see, 7.4 will work just as well for that. The cluster is usually also fine with not running the same version, since at least during the upgrade there will be nodes with different PVE versions in the same cluster. Just make sure your nodes run the same major ceph version. And before upgrading...
Hey,
the allowed IPs appear to be
r-inkas.ru. 86400 IN TXT "v=spf1 mx ip4:185.86.134.11 ip4:194.84.103.61 ip4:194.84.103.188 ip4:81.9.114.34 ip4:81.9.122.86 ip4:81.9.122.87 ip4:81.9.122.88 ip4:185.86.134.242 -all"
you'll have to update the SPF DNS record and either
- add one to...
Hey,
did you update[1] /etc/pve/corosync.conf? Also take a look at [2], that should walk you through how to update the corosync config properly, since it is a little involved.
For future reference the easiest way would probably be to add a second link with the new IP, then deleting the old...
Hey,
you can see the boot mode in the node summary. But generally VMs neither care, nor do they know how the host was booted, or basically anything else host specific.
Based on the screenshots you posted it looks like 192.168.100.2 is running the openvpn, if that is not the case replace 192.168.100.2 with the IP of the openvpn server(the VM that can reach 192.168.101.0/24) in the following.
In your ping example 192.168.100.5 can't answer the ping because it...
The problem is that 192.168.100.5 does not know how to reach 192.168.101.0/24, so it receives the ping package, but can't answer.
1. You can either set a route to 192.168.101.0/24 through 192.168.100.2 on your default gateway
2. or, setup NAT on 192.168.100.2
1. is probably what you want though.
Is IPv4 forwarding enabled in the VM? You can check this with sysctl net.ipv4.ip_forward, it should be 1. If it should be 0 you can enable it by adding net.ipv4.ip_forward = 1 to /etc/sysctl.conf and reloading it with sysctl -p.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.