Auto Commit Fails and prevents 10.2.0 Installation on ESXI 6.5

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Palo Alto Networks Approved
Palo Alto Networks Approved
Community Expert Verified
Community Expert Verified

Auto Commit Fails and prevents 10.2.0 Installation on ESXI 6.5

L4 Transporter

Hi Guys,

Auto Commit Fails and prevents 10.2.0 Installation (upgrade from 10.1.x) on ESXI 6.5 on Active-Active FW where as the peer (on Active-Passive) had no issue.

My question is, as per https://docs.paloaltonetworks.com/compatibility-matrix/vm-series-firewalls/vms-series-hypervisor-sup... we need 6.7,7.0 to run 9.1.x to 11.0.0, then, firstly, how were these running 10.1.x with no issues and how come there an issue with one FW now and the other one has no issue.

Many Thanks,

@BPry @kiwi 

PrasKtmBoy
1 accepted solution

Accepted Solutions

Cyber Elite
Cyber Elite

@Pras,

Think of the compatibility matrix in this case as more of a listing of what PAN validates things against. Just because you're running an unsupported version of ESXi doesn't exactly mean things will stop working, it just means that PAN isn't validating that it'll work and you're running in an unsupported configuration.

Depending on the reason for the auto-commit failure, this could be completely unrelated to the unsupported version of ESXi being utilized. I'm personally not a fan of upgrading VM series across major versions due to issues I've run into in the past, so I always simply rebuild the VMs on the new major version and then migrate the IPs or traffic to the new hosts. 

The downside of you running in this unsupported manner is that TAC is going to use that to stop troubleshooting as soon as they notice you aren't running on an approved version of ESXi, as it's not validated to actually function properly. That's why you generally want to validate the compatibility matrix prior to an upgrade; unsupported configurations aren't going to get a lot of attention if you run into an issue, even if the root issue is unlikely to be due to the hypervisor. 

View solution in original post

2 REPLIES 2

Cyber Elite
Cyber Elite

@Pras,

Think of the compatibility matrix in this case as more of a listing of what PAN validates things against. Just because you're running an unsupported version of ESXi doesn't exactly mean things will stop working, it just means that PAN isn't validating that it'll work and you're running in an unsupported configuration.

Depending on the reason for the auto-commit failure, this could be completely unrelated to the unsupported version of ESXi being utilized. I'm personally not a fan of upgrading VM series across major versions due to issues I've run into in the past, so I always simply rebuild the VMs on the new major version and then migrate the IPs or traffic to the new hosts. 

The downside of you running in this unsupported manner is that TAC is going to use that to stop troubleshooting as soon as they notice you aren't running on an approved version of ESXi, as it's not validated to actually function properly. That's why you generally want to validate the compatibility matrix prior to an upgrade; unsupported configurations aren't going to get a lot of attention if you run into an issue, even if the root issue is unlikely to be due to the hypervisor. 

L4 Transporter

@BPry brp

Thankyou for your suggestion. That helped!!! 🙂

 

PrasKtmBoy
  • 1 accepted solution
  • 1719 Views
  • 2 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!