Minimizing downtime
-
One of my pfSense installations runs as a VM under vSphere (ESX). It is currently running pfSense 2.2.6, and I want to upgrade it to 2.3.2. I am concerned because this system needs to have minimum downtime, and I had another pfSense 2.3 upgrade where the automatic process did not work correctly.
Ideally, I would like to clone the system and perform the upgrade on the clone, either using a clone in VMWare or copying the pfSense configuration to a fresh install. However, I'm particularly concerned about having two gateways running on the same network, especially if they are both running DHCP servers.
I would appreciate any suggestions on how to manage this. Sorry if this has been covered before; I didn't find anything when I searched the forum.
-
just put the virtual lan_nic on an isolated virtual switch ?
-
But if you assign the LAN to a virtual switch, you make it hard to access the pfSense web interface.
-
you don't need the webinterface todo an update. you can update using the vsphere console, to open up the pfsense console. (option 13)
-
One of my pfSense installations runs as a VM under vSphere (ESX). It is currently running pfSense 2.2.6, and I want to upgrade it to 2.3.2. I am concerned because this system needs to have minimum downtime, and I had another pfSense 2.3 upgrade where the automatic process did not work correctly.
Ideally, I would like to clone the system and perform the upgrade on the clone, either using a clone in VMWare or copying the pfSense configuration to a fresh install. However, I'm particularly concerned about having two gateways running on the same network, especially if they are both running DHCP servers.
I would appreciate any suggestions on how to manage this. Sorry if this has been covered before; I didn't find anything when I searched the forum.
You can't have two gateways running on the same network, especially with the same IP. The thing is, you can easily avoid this.
- first on old pfSense, at each interface configuration make sure you fill in the MAC addresses of the existing interfaces. This is important so that if you move config to another machine, your interface MAC addresses would stay the same (otherwise some Windows PCs will ask the users what kind of network is the new…Home/Office/Public)
- create a client virtual machine with Windows or Ubuntu desktop, just to manage the system
- connect it to a network where you can access the old pfSense from, save config xml from the web interface to that machine
- simply create a second pfSense from scratch with the same hardware parameters as previous one, same number of nics
- prepare a dummy virtual switch and connect the new pfSense's LAN port to the client created above
- disconnect cables from all the nics of the new pfSense
- install pfSense from ISO
- az network setup, make sure you add only the LAN port to the dummy switch above, leave all the other interfaces unconfigurd
- after finisted pfSense install, re-connect client's NIC to the dummy switch; it will get a default IP from the vanilla pfSense system 192.168.1.x.
- access the new pfSense on 192.168.1.1, and upload the config.
- IMPORTANT: Watch the virtual console closely. when the system reboots, pause or power off the machine.
- now with the new pfSense powered off, reconnect each NIC to it.
- shut down the old pfSense (from web interface, or ACPI)
- when it powered off, power on the new pfSense
- DONE!
Your downtime will only last as long as the new pfSense boots up. As extra bonus, you still have the old pfSense as an untouched spare which you can go back to if something goes wrong.
-
:)
