Search results

Probably not, but the presence of that message suggests there are optimizations available for you to take advantage of. My original suggestion stands ;)

You must have missed this part.

As explained, thats not what you did. Its also not possible until zfs 2.3 gets rolled out. You're gonna need to destroy the pool and recreate.

alua is a feature on the target. The host will attempt to distribute traffic as allowed. Read the documentation of your storage for proper configuration of multipathd.

Ensure that: 1. store iscsi_data is set up shared, and that the destination node is included in the allowed node list. 2. store iscsi_data ISNT SET TO LVM-THIN.

... I wont correct you, but you really should go back and read how networking works in a linux hypervisor environment. Suffice it to say it doesnt work like you think it does.

I gather from this that you are using a single interface for all traffic, including corosync. This is bad practice and can lead to the exact behavior you are seeing. If you want to eliminate the possibility of corosync interruption, do not comingle other traffic with it on the same interface...

Was responding to your quoted question. I dont have any idea how you would do it, as it wouldnt occur to me to try- and if it was possible I'd be reporting it as a bug.

as long as you have enough resources in the "small" section, just move the workload over, then shut down all nodes in the "large" section. perform your required maintenance and boot them back up. edit there is another possibility; keep both the old switch and new switches connected...

It effectively undoes the whole point of a container. may as well do whatever it is you're doing on the host since you don't have meaningful separation doing it in the way you are.

Thats also in the logs. If I have to guess, its a networking issue. post the content of /etc/network/interfaces and /etc/pve/corosync.conf for validation and recommendations.

All answers are in your logs. start there.

Yes. Wrong audience. HyperV can and does work well, but this is a Proxmox forum ;) No. whatever you do, make sure to architect the STORAGE first as so much of the rest of the deployment (HA, performance) is going to be tied to it. you're gonna have to get statistics from your current...

so, allow me to summarize your argument: You have customers who dont want three nodes. Those customers balk at having a quorum device that looks like a pve node, or a quorum witness appliance. for reasons. Is that about the gist? Let me ask you something else: what, exactly, are the services...

OK, but that's a whole lot different than sweeping statements with respect to what the industry is doing. PVE lacks proper tooling to use shared block storage (be it iscsi, fc, NVOF, SBP, etc) to its full potential. Those are still the preferred way to handle shared storage for virtualization...

VRRP is a router protocol. If you run your routers on your cluster already, you already have a single IP that you can use for reverse proxy. the rest of the software doesnt serve any actual purpose.

Understand that H264/265 codecs are NOT FREE PRODUCTS, and they require a license. see https://accessadvance.com/ for more information.

You can. its not ideal but it would work. THIS.

While I can agree with your assessment for FC, what brings you to the conclusion that the "industry" moved away from iscsi? in favor of what? dont confuse the limitations of PVE with limitations of iscsi as a storage transport- which, incidentally, apply to fc as well. FC storage solutions are...

OK, so you have a router controlling NAT between your outside and inside traffic, right? start by looking at that documentation for a reverse proxy feature (might be called virtual server or similar) since, by definition, you can only reach your ROUTER from outside to begin with.