This post will be a collection of thoughts and my own experiences when migrating from a physical C160 to a virtual C100V appliance. Other IronPort ESA P2V appliances may be similar so it’s worth reading on!
Firstly let’s talk about the Configuration Migration Tool that Cisco developed. Unfortunately it has not been maintained or developed over the years so it probably won’t be very helpful for you… it certainly wasn’t for me. The latest version (last updated in 2013) can only support the following models:
“For ESA migration from hardware to virtual, version must be 7.6.x*
(for instance, 7.6.1 or 7.6.0.444).
For ESA migration from virtual to hardware, version must be 8.0.0*
(for instance, 8.0.0 or 8.0.0.671).”
Also, don’t even bother trying to migrate from a physical appliance running AsyncOS 8.x to a virtual appliance running 9.X unless you want to know how it feels to go insane.
The best way to perform the migration is to have both physical and virtual appliances on the same version.
As of this post, you can download two versions of the virtual appliance. 8.5.6 and 9.0. The aim is to get the physical and virtual appliances on the same version so that the configuration backup and restore can be as pain free as possible (and maintain our sanity).
Note that in my case, AsyncOS 9.X will not be supported on the C160 hardware so I made sure my physical appliance was on the most up to date 8.5.6 release and downloaded the 8.5.6 virtual appliance.
Matching up the physical and virtual interfaces
Now, on the virtual appliance, you’ll have three interfaces. Management, Data 1 and Data 2. On the C160 you only have Data 1 and Data 2 so you won’t be able to just import your config without making some (really easy) modifications.
What I did was:
- export the configuration from the virtual appliance and find the sections labelled <interface_name>Management</interface_name> and
<ethernet_interface>Management</ethernet_interface> - Export the physical appliance config
- Replace the sections listed above in the physical config from the ones in the virtual config
Note that if you are bringing up the virtual appliance in the same network as the currently live physical appliance then you will want to change the hostname and IP addresses (in the config file or after the restore but before the commit) or you’re going to have a bad time. In my case, I changed the management address but kept the other interfaces the same but disconnected in VMWare.
Correcting the update server
Before continuing, you will also need to make a change to the update server on the virtual appliance as it will not be correct.
You will know if your update server needs fixing if you cannot download the latest anti-spam definitions, feature keys or get any of the following errors:
Web UI: Failure downloading upgrade list
CLI: Failure downloading upgrade list: Received invalid update manifest response
To fix the issue:
- Log in to CLI
- Run the command updateconfig then subcommand dynamichost
- Make sure the server is update−manifests.sco.cisco.com:443
- Commit
See this URL for more information @ http://www.cisco.com/c/en/us/support/docs/security/email-security-appliance/118065-maintainandoperate-esa-00.pdf
License/Feature Keys
I generated and imported the license keys after the config restore so it probably doesn’t matter which way you do this.
Note that you need to import the licence file via the CLI using the command loadlicence
Dormant Feature Keys
If you see ‘Dormant’ in the ‘Status’ column in the feature keys section then you will need to click in to those sections in the web interface and accept the EULA otherwise those features will remain disabled – annoying but that’s the way it’s done.
For example, if Sophos Anti-Virus is dormant then you need to go to:
- Security Services
- Sophos
- Edit Global Settings…
- Accept EULA
- Done
That’s it as far as my notes go – I will update this post if I come across anything else that could be useful.
Feel free to comment using the comment section below.
6 replies on “Migrating from a Physical IronPort ESA to a Virtual IronPort Appliance”
A couple of tips:
First, You don’t actually need to replace the interface section of the physical appliance config – you can simply delete it. If the ESA doesn’t find an expected section in the config, it will just leave that section unchanged in the new config. At least, that was my experience when I migrated from C380’s to C600V’s recently.
Second, the dynamichost command is actually a hidden subcommand of the “updateconfig” command. So in the CLI you need to issue the “updateconfig” command THEN type “dynamichost” to change the update server. Clearly you already know this, but this post as it stands won’t work 🙂
Thanks Tim for your helpful comments. Forgot about the updateconfig command so I’ll update my post to address the oversight.
Hi Mikail,
I don’t know if there is a way to copy config from ESA with 7.6 AsyncOS to a vESA with 9.7?
When i migrate I have the “SSHv1 enabled” error.
Best regards.
It won’t be easy at all which is why in my post I recommend getting the physical and virtual on the same version or as close to the same version as possible.
Which physical appliance do you have? Can you upgrade your physical appliance to 9.7?
Thank you so much for your reply.
the ESA C370 who it is with 7.6 is in the client side. I will upgrade it to ESA C380. In my lab i would like to know his config and I installed a vESA and I’m trying to past the config in the lab environment.
What are your recommendation for migrating a C370 cluster to C380 cluster?
Best regards.
Unfortunately I have not worked with clusters but some things I can suggest:
– If you want to migrate from physical to virtual then you should make the versions the same – if this is a client’s ESA then that may not be possible
– If you want to migrate from one physical hardware to another model (which is what it sounds like what your client wants) then again, keep old and new models on the same version then you should be able to export & import the config to the new hardware. Some things to keep in mind for the HW migration is that if the C380 has more/less physical network interfaces (including management interfaces) then you will need to reflect this in the configuration file. For example, if C370 has 1 network interface and C380 has 2 then the configuration won’t import successfully (as far as I remember).
I guess if you really want to lab it up in a virtual appliance then try to convince the client to download the latest version of AsyncOS (there’s no downside really and in fact will probably have to do it because the new appliance will most likely ship with the latest AsyncOS) then get a virtual appliance on the same version.