Veeam Backup & Replication 12.2 - File Level Restore - API cannot assign correct network

[dmanolis]

Hello,

I have a question regarding the File Level Restore in Veeam 12.2. I am trying to restore files from linux using “Temporary Helper Appliance” through the api. In the request payload i am specifying what network to use ( the network is under a dvSwitch), but instead it creates a new network that isn't connected with the server and it cannot access the restore point. I tried both Network / DVSNetwork as the type but the result was the same.

API Endpoint: /api/v1/restore/flr

Payload

Code: Select all

{
    "restorePointId": "{restore_point}",
    "type": "Linux",
    "autoUnmount": {
        "isEnabled": true,
        "noActivityPeriodInMinutes": 10
    },
    "reason": "",
    "helperAppliance": {
        "platformResourceSettings": {
            "type": "VMware",
            "host": {
                "platform": "VMware",
                "hostName": "{hostname}",
                "name": "{name}",
                "type": "Host",
                "objectId": "host-{id}"
            },
            "resourcePool": {
                "platform": "VMware",
                "hostName": "{hostname}",
                "name": "{name}",
                "type": "ResourcePool",
                "objectId": "resgroup-{id}"
            },
            "network": {
                "platform": "VMware",
                "hostName": "{hostname}",
                "name": "{name}",
                "type": "Network",
                "objectId": "dvportgroup-{id}"
            }
        },
        "networkSettings": {
            "IPv4Settings": {
                "ipAddress": "{ip_address}",
                "subnetMask" : "{netmask}",
                "defaultGateway": "{gateway}",
                "preferredDNSServer": "1.1.1.1"


            }
        }
    }
}

[oleg.feoktistov]

This does look like a bug. I asked our QA to have a look. Will follow up on the thread once we have an update. Thanks!

[oleg.feoktistov]

An update - we couldn't reproduce the same issue in QA labs for v12.2. So please contact our support engineers so that we could investigate it deep on our side and share your case id here. Thanks!

[dmanolis]

From our extensive testing we have concluded that there is indeed a bug on the FLR Linux appliance API regarding distributed networks.

When we tried using a standard Network (ESXI Standard vSwitch) the FLR helper appliance was deployed successfully. When we did the same thing with a distributed (dvPortgroup) network (using all the required fields as you can se below) we ended up with a "dummy" standard network that only existed as-long-as the appliance was online. (until connection timeout)

The test were run on Versions 12.2 and 12.3 with both versions of the API 1.1-rev2,v1.2-rev0.


I will share with you below the samples from the Svc.Veeam.VBR.RestAPI.log from our latest test (12.3,v1.2-rev0) but we get the same output with the other versions: (i have only replaced ip addresses data)

Code: Select all

[05.12.2024 16:18:14.461]    <65>    Info (3)    [User: Administrator][POST] request to [/api/v1/restore/flr] deserialized. Message: [{
[05.12.2024 16:18:14.461]    <65>    Info (3)        "restorePointId": "94351c0a-e810-43b7-a529-5f6a7532e9dd",
[05.12.2024 16:18:14.461]    <65>    Info (3)        "type": "Linux",
[05.12.2024 16:18:14.461]    <65>    Info (3)        "autoUnmount": {
[05.12.2024 16:18:14.461]    <65>    Info (3)            "isEnabled": true,
[05.12.2024 16:18:14.461]    <65>    Info (3)            "noActivityPeriodInMinutes": 10
[05.12.2024 16:18:14.461]    <65>    Info (3)        },
[05.12.2024 16:18:14.461]    <65>    Info (3)        "reason": "napana",
[05.12.2024 16:18:14.461]    <65>    Info (3)        "helperAppliance": {
[05.12.2024 16:18:14.461]    <65>    Info (3)            "platformResourceSettings": {
[05.12.2024 16:18:14.461]    <65>    Info (3)                "type": "VMware",
[05.12.2024 16:18:14.461]    <65>    Info (3)                "host": {
[05.12.2024 16:18:14.461]    <65>    Info (3)                    "platform": "VMware",
[05.12.2024 16:18:14.461]    <65>    Info (3)                    "hostName": "x.x.x.141", //vcenter ip
[05.12.2024 16:18:14.461]    <65>    Info (3)                    "name": "x.x.x.140", // host ip
[05.12.2024 16:18:14.461]    <65>    Info (3)                    "type": "Host",
[05.12.2024 16:18:14.461]    <65>    Info (3)                    "objectId": "host-10"
[05.12.2024 16:18:14.461]    <65>    Info (3)                },
[05.12.2024 16:18:14.461]    <65>    Info (3)                "resourcePool": {
[05.12.2024 16:18:14.461]    <65>    Info (3)                    "platform": "VMware",
[05.12.2024 16:18:14.461]    <65>    Info (3)                    "hostName": "x.x.x.141", //vcenter ip
[05.12.2024 16:18:14.461]    <65>    Info (3)                    "name": "TestPool1",
[05.12.2024 16:18:14.461]    <65>    Info (3)                    "type": "ResourcePool",
[05.12.2024 16:18:14.461]    <65>    Info (3)                    "objectId": "resgroup-1003"
[05.12.2024 16:18:14.461]    <65>    Info (3)                },
[05.12.2024 16:18:14.461]    <65>    Info (3)                "network": {
[05.12.2024 16:18:14.461]    <65>    Info (3)                    "platform": "VMware",
[05.12.2024 16:18:14.461]    <65>    Info (3)                    "name": "dv-MGMT[234]",
[05.12.2024 16:18:14.461]    <65>    Info (3)                    "hostName": "x.x.x.140", //vcenter ip
[05.12.2024 16:18:14.461]    <65>    Info (3)                    "type": "DVSNetwork",
[05.12.2024 16:18:14.461]    <65>    Info (3)                    "objectId": "dvportgroup-2068"
[05.12.2024 16:18:14.461]    <65>    Info (3)                }
[05.12.2024 16:18:14.461]    <65>    Info (3)            },
[05.12.2024 16:18:14.461]    <65>    Info (3)            "networkSettings": {
[05.12.2024 16:18:14.461]    <65>    Info (3)                "IPv4Settings": {
[05.12.2024 16:18:14.461]    <65>    Info (3)                    "ipAddress": "x.x.x.150",
[05.12.2024 16:18:14.461]    <65>    Info (3)                    "subnetMask" : "255.255.255.0",
[05.12.2024 16:18:14.461]    <65>    Info (3)                    "defaultGateway": "x.x.x.254",
[05.12.2024 16:18:14.461]    <65>    Info (3)                    "preferredDNSServer": "1.1.1.1"
[05.12.2024 16:18:14.461]    <65>    Info (3)                }
[05.12.2024 16:18:14.461]    <65>    Info (3)            }
[05.12.2024 16:18:14.461]    <65>    Info (3)        }

Beneath the initial request log we get the following that only specifies the network name and doesn't change when we test with standard and distributed networks nor it includes out objectId as it does with the resourcepool.

Code: Select all

<LinuxViFlrOptionsInfo FolderRef="" StorageContainerId="" NetworkAdapterId="">
	<CommonOptionsXml>
		<LinuxCommonFlrOptions IsMountToOriginal="False">
			<HostId>f635db96-285e-4ba6-b148-30a66055350c</HostId>
			<UseNovellAppliance>False</UseNovellAppliance>
			<ProductionNetworkVlanId>0</ProductionNetworkVlanId>
			<RemoteMountHostId>00000000-0000-0000-0000-000000000000</RemoteMountHostId>
			<RemoteMountHostName />
			<ViNetInfo>
				<Network>
					<Name>dv-MGMT[234]</Name>
				</Network>
			</ViNetInfo>
			<IPProperties>
				<UseStaticIp>True</UseStaticIp>
				<StartFtp>False</StartFtp>
				<StaticIp>x.x.x.150</StaticIp>
				<SubnetworkMask>255.255.255.0</SubnetworkMask>
				<DefaultGateway>x.x.x.254</DefaultGateway>
				<UseStaticDns>True</UseStaticDns>
				<PreferredDns>1.1.1.1</PreferredDns>
				<AlternateDns />
			</IPProperties>
			<IPv6Properties>
				<UseStaticIp>False</UseStaticIp>
				<StaticIp />
				<SubNetworkMaskPrefixLength>0</SubNetworkMaskPrefixLength>
				<DefaultGateway />
				<UseStaticDns>False</UseStaticDns>
				<PreferredDns />
				<AlternateDns />
			</IPv6Properties>
		</LinuxCommonFlrOptions>
	</CommonOptionsXml>
	<ResourcePoolRef>resgroup-1003</ResourcePoolRef>
</LinuxViFlrOptionsInfo>

Also upon inspected the generated veeamflr helper appliance's vmx file we only see the following regarding the network:

ethernet0.present = "TRUE"
ethernet0.virtualDev = "vmxnet3"
ethernet0.addressType = "vpx"
ethernet0.generatedAddress = "00:50:56:bf:97:c0"
ethernet0.uptCompatibility = "TRUE"
ethernet0.networkName = "dv-MGMT[234]"
ethernet0.pciSlotNumber = "192"

without containing any information about the distributed switch or the objectId


Note: Starting an FLR session from the Veeam UI works normally and connects to the DVNetwork properly.

Please let us know if you think there is an issue from our side and how we could fix it, and if you need more info for debugging.
Thank you in advance i hope all this help you with figuring out the issue.

[oleg.feoktistov]

Hi,

Just to let you know that this thread is not forgotten. The issue is currently pending confirmation from QA. Will follow up here once we have any updates.

Best regards,
Oleg

[oleg.feoktistov]

Hi @dmanolis,

Unfortunately, our QA couldn't reproduce the issue you described in their labs. In their labs your scenario worked both for 12.2 and 12.3. So I'd suggest to contact our support and let engineers dive deep into the logs. Please also shared case id here once submitted.

Thanks,
Oleg