search

cloudfoundry-attic / cfdev

A fast and easy local Cloud Foundry experience on native hypervisors, powered by LinuxKit with VPNKit
Apache License 2.0
227 stars 64 forks source link

Windows 10 Hyper V host.cfdev.sh mapping lost after network switch #76

Closed guptaavi closed 5 years ago

guptaavi commented 5 years ago

After initially starting cfdev on my Windows 10 laptop, applications running on cfdev are able to access the host using host.cfdev.sh. But after "pausing" the VM in Hyper-V, suspending laptop and then "resuming" the VM, the deployed applications are no longer able to access services (e.g. mongodb) running on the host using host.cfdev.sh (Exception: java.net.UnknownHostException: host.cfdev.sh). I would like to avoid having to stop and start the dev instance daily since it takes upwards of 30 minutes to start. If there any particular sequence of shutdown steps I need to follow in order to avoid having to stop/start the VM each time?

cf-gitbot commented 5 years ago

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/163857248

The labels on this github issue will be updated when the story is started.

sdawson-pivotal commented 5 years ago

Hi @guptaavi thank you for reaching out. Would you mind telling us more about your cf dev use case? We are gathering feedback from our users and your input would be much appreciated. Here is a 4 question survey: https://goo.gl/forms/pztZuTcEgoK4jSjz1 Thank you!

guptaavi commented 5 years ago

Anyone who can help with this issue? I noticed that after doing 'cf dev start' I can use the jumpbox account to ssh into the Hyper-V VM. From this ssh session, I am able to do a nslookup host.cfdev.sh. However, after a network switch, this host mapping is lost. Any ideas on how to "manually" restore the routes on the VM and on the host?

aemengo commented 5 years ago

@guptaavi Unfortunately, this is functionality that we simply do not support as of right now, primarily because Hyper-V is the component orphaning the virtual network switch, not us. As of right now, we have no resolution to advise.