Migrating PCS 7 V7.0 SP1 to New Hardware: ESXi vs VMware Virtualization Reference

Siemens SIMATIC PCS 7 V7.0 SP1 is a Windows XP/Server 2003-era distributed control system (DCS) that increasingly hits two walls when operated on a new Dell i7 (8th generation or later) workstation: the operating system is no longer installable on modern UEFI-only firmware, and the 32-bit Windows memory ceiling at 4 GB starves a multiproject that has grown over the years. The realistic options for keeping the existing project alive are (a) replace the controller hardware with a SIMATIC IPC that ships with a downgrade license, (b) upgrade the PCS 7 suite to a current version, or (c) virtualize the legacy guest on a modern host. This reference documents option (c) in field-deployable detail, including the CP1613/CP1623 PROFIBUS/PROFINET network card passthrough problem, the 4 GB RAM ceiling, the VMware ESXi 5.5 release boundary for Server 2003 guests, and the Siemens Industry Online Support FAQ 65910031 on PCS 7 in virtual environments as it applies to V7.0 SP1 specifically.

1. Problem Statement: Why a New Dell i7 Will Not Boot the Original PCS 7 V7.0 SP1

The original PCS 7 V7.0 SP1 multiproject was engineered on a machine running either Windows XP Professional SP2/SP3 (32-bit) or Windows Server 2003 R2 SP2 (32-bit). Three constraints converge to break this configuration on a 2024-era Dell i7 tower or rack workstation:

1. UEFI-only firmware. Dell OptiPlex, Precision, and PowerEdge models from 2017 onward ship with UEFI Class 3 firmware and no legacy BIOS compatibility mode. Windows XP and Server 2003 R2 do not contain the UEFI boot shim (they use MBR-only NTLDR), so they will not boot from a clean SATA/AHCI SSD attached to the controller.
2. No Server 2003 driver support. Windows Server 2003 SP2 lacks inbox drivers for Intel C620/Xeon Scalable chipset SATA, Intel I219-LM Gigabit, NVIDIA Quadro, or any current USB 3.x host controller. Slipstreamed F6 mass-storage drivers still must be loaded from a floppy image, which is impossible on systems without a floppy connector or PS/2 ports.
3. 32-bit 4 GB memory ceiling. Both XP Professional and Server 2003 R2 (32-bit) cap user-mode virtual address space at 4 GB; /PAE does not widen the user-mode VA window, only the kernel physical mapping. Any RAM above 4 GB on the host is invisible to the PCS 7 ES, OS, and the WinCC runtime archives.

The cumulative effect is the symptom the original poster reported: the existing host "does not respond like before," project compilation times have ballooned, the WinCC archive rotates are queued, and the SIMATIC Manager session is taking minutes to open the S7 program. The CPU is no longer the bottleneck — it is the 32-bit kernel thrashing the working set against a 3.2 GB practical address space while the multiproject's .s7p tree exceeds 1.2 GB on disk.

2. PCS 7 V7.0 SP1 Supported Operating System Matrix

The V7.0 SP1 readme locks the supported OS list. No deviation is permitted on a Siemens-supported plant-floor install.

3. The 4 GB RAM Ceiling and Why PAE Does Not Help

The 4 GB ceiling is a 32-bit Windows architectural boundary, not a license restriction. The relevant facts:

• 32-bit Windows uses a 2-level virtual address space with 4 GB of total VA. The kernel reserves the upper 2 GB by default (or upper 1 GB with /3GB boot switch) for system use.
• Physical Address Extension (PAE) widens the physical address bus from 36 to 36 bits, but user-mode applications still see only 2 GB (or 3 GB with /3GB) of VA. PAE is therefore invisible to PCS 7, WinCC, and the S7 program editor.
• Hard disk caching and the WinCC archive manager can compensate partially by using CreateFile with FILE_FLAG_NO_BUFFERING, but the PCS 7 multiproject compiler requires the entire .s7p tree to be memory-mapped during incremental compile.

Practical observed symptom: with 4 GB installed, a 6,000-tag multiproject consumes 1.8 GB in the ES process alone, leaving less than 1.2 GB for the OS, the SQL Server (MSSQL$WINCC) instance, and the WinCC graphics runtime. Disk thrashing drives compile time from 90 s to 14 min.

4. Virtualization Hypervisor Types: Type 1 vs Type 2

The discussion thread conflates two different VMware products that behave very differently on a plant floor. The correct hypervisor choice determines whether Siemens will release a support ticket if a fault occurs.

5. VMware ESXi: The Only Released Plant-Floor Hypervisor for PCS 7

VMware ESXi is a Type 1 (bare-metal) hypervisor. There is no host Windows; the hypervisor boots directly from a USB stick or SATADOM and presents virtual machines to a vSphere client. The release boundary that matters for this migration is:

For PCS 7 V7.0 SP1 specifically, the Siemens release is silent. Siemens first publishes ESXi support with V7.1 SP2 on the ESXi 4.1 HCL. Running V7.0 SP1 on ESXi is technically possible on ESXi 5.5 but is not under a Siemens support contract for that specific combination. The pragmatic plant-floor posture is to upgrade the PCS 7 suite to V7.1 SP2 (or later) and then deploy the original project to an ESXi 5.5 host.

6. CP1613 and CP1623: Why the Network Card Is the Hard Problem

The CP1613 (PCI, 32-bit, 33 MHz) and CP1623 (PCIe x1, rev. 1.0a) are Siemens network cards for PROFINET IO and PROFIBUS DP master/slave. They are also the only cards that the SIMATIC Manager and WinCC use for the engineering channel to the AS 400 station over Industrial Ethernet. The cards are not standard Intel or Broadcom NICs — they carry an ERTEC 400 ASIC that offloads the PROFINET IRT (Isochronous Real-Time) cycle from the host CPU. Three consequences follow for virtualization:

1. Direct PCI/PCIe access is mandatory. The Siemens device driver (cp1613.sys, cp1623.sys) issues MMIO and bus-master DMA to the ERTEC 400 registers. A para-virtualized vmxnet3 or e1000e NIC emulated by the hypervisor will not be recognized by the driver, and the SIMATIC Manager will report Error 0xFFFD4061: Internal error in CP1613 driver on every project open.
2. PROFINET IRT cycle is 31.25 µs to 1 ms. Any interrupt coalescing or scheduler latency on the hypervisor side breaks the IRT window. This is why the release requires VMDirectPath I/O (also called PCI passthrough) instead of the SR-IOV alternative: VMDirectPath gives the guest sole ownership of the PCI device and its MSI-X interrupt lines.
3. VT-d (Intel) or AMD-Vi must be enabled in BIOS. Without IOMMU virtualization, the hypervisor cannot translate guest physical addresses to host physical addresses for the CP1613/CP1623 BARs, and the ESXi kernel will refuse to attach the device with the message Device :dev.fn> is not in the passthrough whitelist.

7. Dell i7 Host Sizing for ESXi 5.5 + Server 2003 R2 SP2 Guest

Target hardware: a Dell Precision 3660 or OptiPlex 7000 series with a 12th/13th generation Core i7. Sizing math below assumes a single ES guest running the full PCS 7 V7.0 SP1 multiproject, plus a single OS guest for runtime.

The RAM calculation is the most important number. The 4 GB guest RAM limit applies to a 32-bit guest. The 64 GB host is fine because the host ESXi kernel is 64-bit. The PCS 7 ES guest can therefore see 8 GB allocated to it, but the OS will only use 4 GB of that (the rest is wasted unless you apply the /PAE + /3GB boot switches and recompile the SIMATIC Manager binaries with /LARGEADDRESSAWARE — which V7.0 SP1 does not do).

8. ESXi 5.5 Installation and BIOS Prerequisites

Before booting the ESXi installer, configure the Dell i7 BIOS as follows. These settings are mandatory for the CP1623 passthrough to function.

1. Enter BIOS (F2 at Dell splash).
2. General → Boot Sequence: set UEFI boot only, disable Legacy Boot ROM.
3. Virtualization → Intel Virtualization Technology: Enabled.
4. Virtualization → VT for Direct I/O (VT-d): Enabled. This is the IOMMU flag. If the option is greyed out, the CPU stepping does not support VT-d and the build must be downgraded (e.g., to an i7-10700).
5. Security → TPM: leave Disabled (ESXi 5.5 does not use it).
6. Power Management → C-States: Disabled. C-states add 30–100 µs latency to the PROFINET IRT interrupt.
7. Power Management → SpeedStep: Disabled.
8. System Configuration → SATA Operation: AHCI (not RAID On). The ESXi 5.5 ahci driver supports AHCI; the Dell PERC controller is not in the HCL.

Boot the ESXi 5.5 U3 installer ISO from a USB key prepared with Rufus in DD mode. The 5.5 U3 build is the last ESXi release that will install on UEFI Class 3 hosts without a legacy shim; ESXi 6.0 onward will refuse to install on systems without a CSM option.

9. ESXi 5.5 Configuration Procedure

1. After ESXi boots, press F2 and assign a static IP to the management NIC (Intel I219-LM). Example: 10.10.10.50/24, gateway 10.10.10.1, hostname pcs7esxi55.
2. From a Windows 7 or 10 client with the vSphere Client 5.5 installed, connect to https://10.10.10.50.
3. Upload the ESXi 5.5 patch bundle ESXi550-201512001.zip via Host → Update → Upload. Reboot. This patch is required to add the I219-LM NIC to the in-box ne1000 driver.
4. Create two VMFS-5 datastores: datastore1 (boot, 200 GB) and datastore2 (data, 1.6 TB).
5. Configure NTP. Host → Time Configuration → Properties → NTP: 10.10.10.1 as primary, pool.ntp.org as secondary. The PROFINET IRT cycle is sensitive to host time drift; an unsynchronized host causes sporadic AS connection loss.
6. Configure syslog to a remote collector. PCS 7 ES will dump .dmp files to C:\Users\Public\Documents\Siemens\Automation\; the host's vmkernel.log is required for the Siemens escalation.

10. VM Configuration for the Windows Server 2003 R2 SP2 Guest

Use the vSphere Client to create the ES guest with the following parameters. The 32-bit Windows guest is the bottleneck; the rest of the host can be modern.

11. PCI Passthrough of the CP1623 to the ES Guest

Once ESXi 5.5 is installed and the CP1623 is physically seated in a PCIe x1 slot, configure passthrough from the vSphere Client:

1. Host → Configuration → Advanced Settings → Configure Passthrough.
2. Locate the CP1623 PCI device by vendor ID 0x110A (Siemens AG) and device ID 0x407D. Toggle the passthrough checkbox.
3. Reboot the host to apply the IOMMU mapping.
4. Edit the ES guest: Edit Settings → Add → PCI Device → Select Siemens CP1623.
5. Boot the ES guest. Inside Server 2003, the Device Manager will show a Siemens PROFINET PCI Express entry with IRQ 16 and BAR 0 at 0xF7E00000.
6. Install the CP1623 driver from the Siemens SIMATIC NET DVD (PN-CD-V70SP1). The driver must be version 8.1.4.0 or later for the V7.0 SP1 release.
7. Open the SIMATIC Manager, then Options → Set PG/PC Interface → CP1623 (PROFINET). The interface must appear with status Active, not Not active.

If Device Manager shows the CP1623 with a yellow bang or Code 12 (insufficient resources), the host IOMMU table is not in coherence with the guest. Reset by: shutdown guest → in vSphere Client, Edit Settings → PCI Device → Reserve all memory → reboot guest.

12. PROFINET IRT Cycle Tuning Inside the Guest

Even with VMDirectPath I/O, the PROFINET IRT cycle is sensitive to interrupt latency. Apply the following tuning in the Server 2003 R2 guest:

• Disable the Windows firewall. The firewall service introduces up to 200 µs latency on packet processing and is not needed on a single-purpose ES guest.
• Set the power profile to High Performance. The default Balanced profile engages SpeedStep and adds 1 ms C-state exit latency.
• Disable Windows Update. The wuauserv service can spike the CPU during scheduled scans.
• Pin the vCPUs to physical cores. From the vSphere Client, edit the ES guest, Advanced → CPU → Latency Sensitivity = High. This reserves a physical core and removes the guest from the ESXi CPU scheduler's ready queue.
• Disable the indexing service. The cisvc process can stall disk I/O for several seconds during project scans.

After tuning, verify the PROFINET IRT cycle time in the SIMATIC Manager: Target System → PROFINET IO → Diagnostics → Cycle Time. The displayed value should be 1.000 ms with a jitter of less than 50 µs. Higher jitter indicates the CP1623 interrupt is being delayed by the hypervisor scheduler.

13. Migration Procedure: Old Host to New ESXi Host

Carry out the migration in a controlled maintenance window with the plant in a safe state.

1. Pre-migration backup. On the old Server 2003 R2 host, run a full image backup of C: and D: using Acronis True Image 9 or a similar tool that supports Server 2003. Also export the PCS 7 multiproject via SIMATIC Manager → File → Multiproject → Archive to a network share.
2. Build the new host. Install ESXi 5.5 U3 on the Dell i7, configure BIOS per Section 8, and create the ES and OS guests per Sections 9–10.
3. Restore Server 2003 R2 base. Restore the Acronis image to the C: drive of the ES guest. Boot into Safe Mode with the acpitabl.dat removed; the ESXi ACPI HAL will panic the Server 2003 ACPI HAL on first boot.
4. Install VM guest drivers. Install VMware Tools for Windows 2003 (vSphere 5.5 still ships a 32-bit Tools ISO). This adds the vmmouse, vmci, and vmhgfs drivers.
5. Re-license the SIMATIC Manager. Reattach the USB license dongle to the ES guest (USB passthrough is supported in ESXi 5.5). Alternatively, port the AX NF ZZ license key file from the old host to C:\Program Files\Siemens\Automation\.
6. Compile the multiproject. From the ES guest, SIMATIC Manager → Options → Multiproject → Compile All. Compilation must complete with zero errors; warnings about SFC library version are acceptable if the project was originally compiled on V7.0 SP1.
7. Download to the AS 400. From the ES guest, connect to the AS 400 station over the CP1623 PROFINET interface and download the recompiled program. Verify the AS 400 is in RUN with no SF (system fault) LED.
8. Online test. Force a few I/O points and verify the value updates in the WinCC OS guest. Confirm the WinCC archive is logging to D:\Archive\ on the OS guest.
9. Decommission the old host. Once the plant is stable for 72 hours, power off and image the old host for spares.

14. Verification Checklist

Run this checklist after each migration. Any failed item blocks the production cutover.

15. Troubleshooting Matrix

16. The Realistic Alternative: PCS 7 Suite Upgrade

All of the engineering effort in Sections 5–15 exists because PCS 7 V7.0 SP1 is end-of-support. The supported path is to upgrade the suite. The most cost-effective migration is:

1. Upgrade to PCS 7 V9.0 SP2 (or the current release) on a SIMATIC IPC 647E or IPC 847E. These ship with a Windows 10 IoT 2019 LTSC image and a Siemens-supported driver set, and they have an on-board Intel I210 NIC that replaces the CP1623.
2. Run the Siemens-provided project migrator to convert the V7.0 SP1 multiproject to V9.0 SP2. The migrator handles the S7 program, the WinCC graphics, and the archive tags. Field-proven migrators exist for V7.0 → V9.0 with a project recompile step of typically 30–90 min per AS.
3. Reuse the existing field I/O. The ET 200M, ET 200S, ET 200SP, and PROFIBUS DP slaves do not change; only the controller program must be recompiled and downloaded.

The virtualized V7.0 SP1 path described in this reference is appropriate only for a plant that must keep the original project running for a quarter or two while the V9.0 SP2 upgrade is scoped, budgeted, and scheduled. It is not a permanent production platform.

17. Common Configuration Pitfalls

• Forgetting to enable VT-d. Without it, ESXi will not allow the CP1623 to be added to the passthrough list, and the engineer loses three days chasing a red herring.
• Using ESXi 6.x or later. These releases do not support Server 2003 R2 as a guest and will refuse to create the VM with the message Operating system not supported.
• Allocating more than 4 GB RAM to the Server 2003 guest. The 32-bit OS will not use it, and the reservation will starve the OS guest on the same host.
• Leaving C-states enabled. The hypervisor will park idle cores, and the PROFINET IRT interrupt will land on a parked core with millisecond exit latency.
• Mixing para-virtualized and passthrough NICs on the same vSwitch. vSwitch security policies apply per-port-group; mixing the two will silently drop the passthrough traffic.
• Skipping the Latency Sensitivity = High setting on the ES guest. Without it, the guest is scheduled on the fair-share scheduler and can be pre-empted by the OS guest during a WinCC archive checkpoint.

18. Related Documentation and Standards

When escalating to Siemens support, cite the following references in the ticket:

• Siemens FAQ 65910031 — PCS 7 in virtual environments
• Siemens FAQ 1137643 — CP1613 installation and configuration
• Siemens FAQ 1137644 — CP1623 installation and configuration
• SIMATIC PCS 7 product page
• PROFINET installation guidelines

FAQ