4

I've been setting up a Windows Server 2008 R2 locally - all went well, and I added the Hyper-V role. Then I created a new VM using the Hyper-V Manager, and added a dynamic VHD.

I could start the VM and connect to it, within Hyper-V Manager. I did not, at that point, install an OS on it.

Up to that point, the host computer had been running on my local network. Then, it was shipped to a colocation company, and now has a new IP address.

It has an IPSEC policy assigned, that allows IP traffic from my local IP address, so I can remote into it via RDP, and my userid, which is in the Administrators group for the host server.

However, I can no longer connect to the VM within Hyper-V Manager. I can see that it's running from the thumbnail, but connecting to it seems to time out.

Would appreciate any suggestions. I've tried deleting and recreating the VM, but the result is the same.

Edit:

In case I wasn't clear:

  • There is no OS on the VM
  • I could connect to the VM from the Hyper-V manager before the host machine was shipped to the colo, now I can't

(Yet) another edit!

This is what my IPSEC filter looks like now:

enter image description here

But I still can't connect.

Final edit:

It doesn't let you create a rule where the source and destination IPs are the same, but reasoning that any traffic from 'My IP address' must be Ok, I added the following rule, and it seems to do the trick:

enter image description here

Still not really sure why the more complicated one isn't allowing the local traffic, but I seem to be Ok now. My thanks for the suggestions.

Improve this question
13
  • Are you connecting to Hyper-V manager on the physical host (say after RDP-ing in, or using Hyper-V manager from your desktop? I've had numerous instances where a VM goes unreachable by Hyper-V manager but is still accessable via RDP, so I'm wondering if the whole IPSec thing is just a red herring and the "Real Problem" is related to Hyper-V manager.
    – OldTroll
    May 28, 2011 at 20:29
  • Yes. RDP in to the host's desktop. Start up the HV Manager.. there's the VM running, thumbnail showing it's running. Try to connect - it just times out. I might add, that's how I connected to it before, except that the host machine was on my local network at the time.
    – ChrisA
    May 28, 2011 at 21:34
  • When you say "Just times out", what do you mean? I'd get a message about not being able to reach the VM. Typically if I shutdown the client, I could re-establish control via HVM, then usually I found that the client software was out of sync with the Hyper-V host's version. I don't think that's strictly applicable here, but still.
    – OldTroll
    May 28, 2011 at 22:05
  • Edited to show what happens when it fails. I've tried shutting down and restarting the guest, stopping and restarting the VM Manager Service, even deleting and recreating the Guest.
    – ChrisA
    May 28, 2011 at 22:27
  • That's the error I got too. There's no OS on the VM, right? Any other VM's on the host? Are they normal or not? Any reason to not reboot the host? It's a craptastic solution, but since my encounters were all on my Hyper-V Development system, I never dug deeper.
    – OldTroll
    May 28, 2011 at 22:34

2 Answers 2

Reset to default
1

I would suggest looking at the IPSEC policy.

It has an IPSEC policy assigned, that allows IP traffic from my local IP address

What about the localhost address? and it's own external address?

The Hyper-V connection tool must connect to it, too, and it does not come from your home address. The IpSec policy possibly filters that traffic out.

Improve this answer
5
  • I did wonder about this. I didn't want to unassign the policy to test it though, since the host is exposed to the internet. I've added a rule to the policy, allowing traffic using 'Any' protocol, with a Source of the external IP, and a destination of 'My IP address'. It still doesn't work - how do I add the localhost one?
    – ChrisA
    May 28, 2011 at 12:27
  • 127.x.x.x (whole A network) is localhost. 127.0.0.1 the normal registration for localhost. This is the most likely one to be used.
    – TomTom
    May 28, 2011 at 13:41
  • Ok, question edited to show the new IPSEC rule. Still no good, have I done something wrong?
    – ChrisA
    May 28, 2011 at 15:23
  • Yes. What about localhost TO LOCALHOST? ;) Your target address still onl allows the public IP, not access to the localhost from localhost. 127.0.0.1 -> 127.0.0.1 and :1 to :1 should be allowed.
    – TomTom
    May 28, 2011 at 15:51
  • Ok, edited again to show the latest version of the IPSEC filter list - but still no go. It won't let me enter a filter where the source and destination are the same, so I'm not sure how to do it as you say here. I appreciate your patience btw!
    – ChrisA
    May 28, 2011 at 17:26
-1

If you have locked yourself out of the VM with its guest OS level configuration(s), then one possible approach may be to:

  • create another VM without the guest OS misconfiguration and with a NIC assigned to the internal VM-Net
  • configure the new VM as a DHCP server for the internal VM-Net with a similar configuration to your local IP net (e.g. the mis-configured limitation of your subject VM)
  • add an additional NIC to the problematic VM assigned the internal VM-Net

The result will be where the new VM should be able to access your subject VM based upon it now being able to mimic your local net across the internal VM-Net - which is the mis-configuration of your subject VM.

Improve this answer
2
  • Sorry, I don't understand this. There's no OS on the VM. Even if I delete the VM and create a new one, I still can't connect to it.
    – ChrisA
    May 28, 2011 at 11:57
  • -1. This is not "guest level", this is host level. The conneciton tool goes to the simulated hardware. It basically "IS" an attached monitor. The Client does not even know whether the connection tool just looks at it.
    – TomTom
    May 28, 2011 at 12:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .