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.