Retrospect Clients on Windows computers with Hyper-V enabled

[JamesOakley]

This is not a post about running Retrospect (or clients) within a virtual machine.

I have a Retrospect Client running on a Windows 10 machine on which I needed to run the Android emulator that comes with Visual Studio. In order to do that, you have to turn on virtualisation / virtualization / hyper-v options within Windows.

As soon as I did that, my Retrospect Professional installation could no longer see the client (Client Not Found). I tried reinstalling the client software, but that didn't help. When I looked at the client properties in Professional, I had a hunch as to why - the IP address of the client was not the one I was expecting. It was outside the subnet I use for my local area network; I forget what IP it was, but it was still in one of the ranges reserved by IANA for local networks. Conclusion: Enabling Hyper-V must, behind the scenes, create a new network with a different subnet mask to set up a NAT system that lets any virtual machines communicate with each other and the wider network. So each virtual machine, and the host physical machine, share the same "public" IP (the IP on my actual network), and have their own internal IP that is only for VMs to communicate with each other. Somehow, the Retrospect Client had picked up that internal IP, and was broadcasting it to Retrospect Professional, so that my Professional installation was trying to use that IP address to locate the client. Not surprisingly, it failed - any traffic that doesn't originate somewhere on that client machine needs to use the single address the client has on my main network.

The solution was actually not too painful - remove the client from Professional, and re-add it, giving the IP address manually. Re-create the subvolumes etc., and everything worked.

Until, randomly, last night the client settings switched back to using a local loop IP again. So I had to remove and re-add the client. Again.

This is solvable, and not happening too often, but is clearly a bug in the way Retrospect Client thinks it's found the IP address that should be used to contact it.

Using 15.6.1.104.

[Nigel Smith]

In my experience, RS Client binds to the first interface it finds to be active -- I often see this when someone has wireless enabled but unused while they are actually using ethernet. Sounds like yours is (sometimes) seeing the virtual interface before the real one.

Instead of deleting/re-adding the client, try the instructions here <https://www.retrospect.com/en/support/kb/client_ip_binding> -- whether you use the "temporary" or "permanent" solution will probably depend on whether that machine is DHCPd or on a static IP.

[JamesOakley]

Helpful - thanks!

I'm on static IPs, and I've just discovered that I can edit that IP in the clients list in the main Retrospect Desktop application.

The annoying thing is, randomly (not every time) after rebooting the WiFi network or the client computer, the IP address gets reset to the one on the virtual interface, and I then have to reset it again in the main application.

I still think this is not how it's supposed to work!

[Nigel Smith]

It's how it *does* work with Retrospect client (and has for the last umpteen years), and I've seen other IP-listener daemons do the same.

Since you are on a static, just run

retroclient.exe /ipsave <static-address>

(from the page linked above) on the client and it will always behind to your external interface rather than the virtual one -- no messing with RS Server required.