Restoring to GCP changes all my network parameters

[ibarizz]

Hello,

I'm into an issue with a customer who's trying to restore backups from their on-premise repositories to GCP.
The restore itself goes pretty well, no major issues.
The thing is that the network parameters from the VM change after placing it to GCP.

For example:
A windows VM that has a static IP, after restoring to GCP it changes to a dynamic IP with DHCP, even though our subnet in GCP is configured to allow static internal IPs.
But it gets worse as I tried the same with with a Debian VM.
After restoring to GCP the network interface was changed (from ens33 to eth0). Also the IP was changed to a dynamic one. Our bash path from /usr/sbin changed aswell, and the name servers from /etc/resolv.conf changed to those from google.
To sum it all up, the restored VM is similar to the one from on-premise, but not the same to the way we backed it up. And this is a huge problem for us as there many things to modify after restoring, and we also don't know what other things are changed...

Is this a normal or is there any misconfiguration from the Veeam side or from the GCP side that I'm not aware of?
Thank you in advance and sorry for the long text..

Cheers.

[Mildur]

Hi Ibarizz

A windows VM that has a static IP, after restoring to GCP it changes to a dynamic IP with DHCP, even though our subnet in GCP is configured to allow static internal IPs.

If Hardware and Mac addresses have changed, windows will recognize those NICs as new devices and may use the default setting DHCP for those new NICS. Same for Linux.

But it gets worse as I tried the same with with a Debian VM.
After restoring to GCP the network interface was changed (from ens33 to eth0). Also the IP was changed to a dynamic one. Our bash path from /usr/sbin changed aswell, and the name servers from /etc/resolv.conf changed to those from google.

The resolv.conf file may have been updated by the DHCP client. But I cannot explain the /usr/sbin path without some research myself.

Best,
Fabian

[doktornotor]

But it gets worse as I tried the same with with a Debian VM.
After restoring to GCP the network interface was changed (from ens33 to eth0). Also the IP was changed to a dynamic one. Our bash path from /usr/sbin changed aswell, and the name servers from /etc/resolv.conf changed to those from google.

Good luck with expecting static network configuration and /etc/resolv.conf to survive moving to another HW (physical or virtual) in systemd era... I'd say you need to check and revise your workflow. It simply doesn't work like that.

On another note, the way you noticed it works gives your networking up and running on those machines after restoring. That would not be the case if things worked the way you expect them to work.

[ibarizz]

Thank you guys for all your responses.

There has to be something in the workflow or in the GCP configuration that is leading me into this problem. I simply don't get why it wouldn't be possible to restore a VM with the same networking parameters even if it's placed in a different HW. This would make it very difficult to use GCP as a disaster recovery solution.
Again, I must be missing something, but I have already checked the VPC network details, the subnet configuration and it's everything configured as expected...

Cheers.

[ibarizz]

Hello, sorry for bumping this thread again!

But I figured out that in the GCP Cloud Storage created by Veeam there are some 'suspicious' scripts that might be creating this issue, specially one from powershell that takes care of configuring the network interface to use DHCP, allowing the computer to automatically obtain an IP address, subnet mask, default gateway, and DNS servers from a DHCP server on the network.

This is the script:

Code: Select all

#  Copyright 2021 Google Inc. All Rights Reserved.
#
#  Licensed under the Apache License, Version 2.0 (the "License");
#  you may not use this file except in compliance with the License.
#  You may obtain a copy of the License at
#
#      http://www.apache.org/licenses/LICENSE-2.0
#
#  Unless required by applicable law or agreed to in writing, software
#  distributed under the License is distributed on an "AS IS" BASIS,
#  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
#  See the License for the specific language governing permissions and
#  limitations under the License.

# Ensure the network interface is configured to use DHCP.
# This script assumes there is only one network adapter.

$adapter = Get-NetAdapter | ? {$_.Status -eq "up"}
$interface = $adapter | Get-NetIPInterface -AddressFamily IPv4

If ($interface.Dhcp -eq "Disabled") {
  Write-Host "Translate: $($interface.InterfaceAlias) does not have DHCP enabled. Enabling DHCP."
  # Remove existing gateway
  If (($interface | Get-NetIPConfiguration).Ipv4DefaultGateway) {
    Write-Host "Translate: Removing IPv4 default gateway for $($interface.InterfaceAlias)."
    $interface | Remove-NetRoute -Confirm:$false
  }

  # Enable DHCP
  Write-Host "Translate: Enabling DHCP for $($interface.InterfaceAlias)."
  $interface | Set-NetIPInterface -DHCP Enabled

  # Configure the DNS Servers automatically
  Write-Host "Translate: Configure the DNS to use DNS servers from DHCP for $($interface.InterfaceAlias)."
  $interface | Set-DnsClientServerAddress -ResetServerAddresses

  # Restart the network adapter
  Write-Host "Translate: Restarting network adapter: $($adapter.Name)."
  $adapter | Restart-NetAdapter

  # Give the network time to initialize.
  & ping 127.0.0.1 -n 30
} else {
  Write-Host "Translate: $($interface.InterfaceAlias) is configured for DHCP."
}

# Log DNS Server information
Write-Host 'DNS client configuration:'
$interface | Get-DnsClientServerAddress

# Test connection to packages.cloud.google.com and log results.
Write-Host 'Testing connection to packages.cloud.google.com:'
Test-NetConnection -ComputerName packages.cloud.google.com -Port 443
Test-NetConnection -ComputerName packages.cloud.google.com -Port 80

Now, what I see is that this script is created by Google but it's placed in the bucket from the cloud storage created by Veeam!!
What I don't know is if it's Veeam the one who's allowing this or it's GCP. Strange...
Thank you!

[Mildur]

Hi ibarizz

I expect that this script is from us and is used for preparing the network inside the VM so you can reach it in GCP. But I have forwarded your question to one of my colleagues to confirm the behavior.

Best,
Fabian

[ibarizz]

I wonder if it's possible to avoid that script, or if it's really needed for the whole restore process to GCP.
Other than that, I'll wait for the answer.

Thank you Fabian!
Cheers.

[veremin]

These are not our scripts, but Google ones. This is how GCP import procedure works: it processes imported VM, detects its Operating System, installs necessary components, and sets up network configuration. We don't control import VM operation and you cannot disable the scripts used within it. Thanks!