DX NetOps Spectrum: How to Migrate a Container Between Landscapes Using Modeling Gateway

Products

• Network Observability
• Spectrum

Issue/Introduction

This article describes the recommended procedure to migrate a container of network devices from one DX NetOps Spectrum Landscape Server to another. Migrating containers using the Modeling Gateway Toolkit allows for the preservation of existing monitoring configurations and avoids the overhead associated with device rediscovery.

Environment

DX NetOps Spectrum (All supported versions) Modeling Gateway Toolkit

Cause

Guidance request for migrating containers between SpectroSERVER landscapes.

Resolution

Follow these steps to migrate a container using the Modeling Gateway Toolkit:

    1    Prepare the Resource File: Locate the Modeling Gateway configuration file: $SPECROOT/SS-Tools/.modelinggatewayresource.xml.
    2    Configure Export: Modify the ExportConfiguration to target the specific container instead of the default Universe. Update the RootContainerToExport element with the name of the container you intend to migrate.
    3    Perform Export: Run the Modeling Gateway export command to generate the XML file for the specified container. See Modeling Gateway Tool for Export
    4    Test Migration: It is strongly recommended to import the XML file into a lab environment first to validate model integrity before performing the migration in production.
    5    Perform Import: Use the Modeling Gateway import command to import the generated XML file onto the target landscape. See Modeling Gateway Tool for Import
    6    Post-Migration Validation: Verify the devices are modeled correctly on the target landscape. The models may initially appear in a "Blue" (Initial) state until the SpectroSERVER successfully polls the devices via SNMP or ICMP.
    7    Cleanup: Once the container has been successfully modeled and verified on the new landscape, delete the old container from the source landscape.

Additional Information

Important Considerations:

• Historical records (events and alarms) are tied to specific model handles on the source landscape and are not preserved during this migration.