Closed mpdude closed 5 years ago
It seems to be because Parallels disconnects virtual network cable for guest during sleep. It is possible to disable this behaviour be specifying flag "devices.net.sleep_disconnects_link=0" in the VMConfiguration -> Hardware -> Boot Order -> Advanced
(there shoud be a way to do this via prlctl, let me know if you want me to find out the command for this)
@dskr99 I've read man prlctl and also looked through prlctl list --info --full --json output. To me it seems this setting is not covered by prlctl?
It is possible to configure VM for system flags with command prlctl set "ubuntu 18.04" --system-flags "devices.net.sleep_disconnects_link=0" (multiple flags can be specified separating them with semicolon)
What about prlctl list --info: it looks like prlctl cannot show flags of VM :-(
Is this something this plugin here should be able to configure/set?
@mpdude Yes, that could be set by adding the following section to Vagrantfile
:
config.vm.provider "parallels" do |prl|
prl.customize ["set", :id, "--system-flags", "devices.net.sleep_disconnects_link=0"]
end
Thanks!
Reopening as this seems not to resolve the issue.
How can I verify that is actually the cause of the problem?
Similar report at https://forum.parallels.com/threads/network-and-external-drive-disconnects-upon-mac-sleep.338699/.
I'm not sure the recommended flag does even exist, but can't find a list of available system flags either.
Filed an issue with Parallels support a week ago, they're still investigating.
@dskr99 Could you please confirm that devices.net.sleep_disconnects_link=0
is correct that way? That setting does not seem to make a difference.
Another setting I've found is devices.net.track_link_status=0
. Might that help as well? What is the purpose of that?
@mpdude Hi, the flag devices.net.sleep_disconnects_link=0 controls whether sleep of macOS disconnects the virtual cable in guest network card. The setting devices.net.track_link_status=0 controls the case of Bridged Networking. It controls whether cable status of physical network adapter to which the guest's NIC is bound is reflected to the guest.
Please try the combination of flags devices.net.sleep_disconnects_link=0 and devices.net.dhcp.notify=0 (ok to enter with semicolon ';' as a separator)
The flag devices.net.dhcp.notify=0 controls whether vm_app could force guest to renew the dhcp address. 0 means that we never force the renew.
devices.net.sleep_disconnects_link=0; devices.net.track_link_status=0
does not solve the problem.
Will try devices.net.sleep_disconnects_link=0; devices.net.dhcp.notify=0
now.
@dskr99 devices.net.sleep_disconnects_link=0; devices.net.dhcp.notify=0
also does not solve the issue.
Any other ideas? Any kind of logging I could turn on to figure out what`s going on?
Just found this in /Library/Logs/parallels.log
after the problem appeared again:
02-07 19:45:57.170 F /disp:249:35075/ On enter : dev_type = 15 dev_name = 14600000 event_code = 1
02-07 19:45:57.170 F /disp:249:35075/ Device change: skip refresh (system sleeping), mask = 0x8000
02-07 19:45:58.512 F /disp:249:34819/ System events monitor: host was wakeup, prepare
02-07 19:45:58.549 F /disp:249:34819/ System events monitor: host was wakeup, done
02-07 19:45:58.644 F /prl_net:379:775/ bridge bridge0 is nonactive (0x1), skipping
02-07 19:45:58.988 W /prl_naptd:379:775/ IPv6 default route is present on host
02-07 19:45:58.988 W /prl_naptd:379:775/ dns_filter_ipv6 = 0 on net0
02-07 19:45:58.988 F /lib_nat:379:775/ port 22; vm_id {18aba22f-d6bd-4981-94de-4b62402e9936}
02-07 19:45:58.988 W /prl_naptd:379:775/ Forwarding TCP port 2222 to 0.0.0.0:22
02-07 19:45:58.988 F /lib_nat:379:775/ port 80; vm_id {18aba22f-d6bd-4981-94de-4b62402e9936}
02-07 19:45:58.988 W /prl_naptd:379:775/ Forwarding TCP port 8080 to 0.0.0.0:80
02-07 19:45:58.989 F /lib_nat:379:775/ port 35729; vm_id {18aba22f-d6bd-4981-94de-4b62402e9936}
02-07 19:45:58.989 W /prl_naptd:379:775/ Forwarding TCP port 35729 to 0.0.0.0:35729
02-07 19:45:58.989 F /lib_nat:379:775/ port 3000; vm_id {18aba22f-d6bd-4981-94de-4b62402e9936}
02-07 19:45:58.990 W /prl_naptd:379:775/ Forwarding TCP port 3000 to 0.0.0.0:3000
02-07 19:45:58.990 F /lib_nat:379:775/ port 3001; vm_id {18aba22f-d6bd-4981-94de-4b62402e9936}
02-07 19:45:58.990 W /prl_naptd:379:775/ Forwarding TCP port 3001 to 0.0.0.0:3001
02-07 19:45:58.991 F /lib_nat:379:775/ port 22; vm_id {cd48fd21-2f5a-4ee6-88c4-c5e402d5c8e9}
02-07 19:45:58.991 W /prl_naptd:379:775/ Forwarding TCP port 2224 to 0.0.0.0:22
02-07 19:46:03.860 F /disp:249:775/ System time change detected.
...
So, maybe Parallels disables port forwardings while the host is sleeping? Since I am connecting into the vagrant box through forwarded ports, that would probably be a reason why the sessions gets terminated.
@mpdude
So, maybe Parallels disables port forwardings while the host is sleeping?
Yes. It is really so. When host wakes up, the parallels shared networking daemon checks how long Mac was sleeping and restarts if sleep longed for more then 2 minutes. It is made so in one of the first versions of Parallels Desktop since when host goes to sleep in one network location and wakes up in another the macos tcp-stack not always detected that TCP-connection no longer exists.
We will think how to improve this behaviour. May be we should restart Shared Networking only if network location had changed while host was sleeping.
Consider the use case that I close my MacBook at home, re-open it at the office and would like an SSH session between OS X and the Vagrant box to remain open...
Would it make sense to provide a system flag for this?
Note to self: Maybe I should connect to port 22 on the VM’s IP address instead of the Vagrant-managed forwarded SSH port. Other protocols (HTTP especially) are stateless and not affected.
Note to self: Maybe I should connect to port 22 on the VM’s IP address instead of the Vagrant-managed forwarded SSH port. Other protocols (HTTP especially) are stateless and not affected.
I believe that if you are connecting to VMs from localhost, then better to use directly VM-ip or it's name: we register VM name in /etc/hosts when VM in Shared or HostOnly networking is started.
Consider the use case that I close my MacBook at home, re-open it at the office and would like an SSH session between OS X and the Vagrant box to remain open...
I'm afraid that this would be hard for us to track whether a connection should be closed or leaved connected. The TCP stack doesn't reset connections for us in this case and this causes that some network applications inside guest will still think that connection is established, causing too much inconvenience. In described case connections will be definitely closed by Parallels Shared Networking.
Will now try to keep the devices.net.sleep_disconnects_link=0; devices.net.dhcp.notify=0
(just to be sure...) and SSH into VMs directly, i. e. without port forwarding.
Will report back here.
Not using port forwarding to SSH into VMs seems to resolve the issue 👍.
Closing for now. Thanks to everyone helping out!
@mpdude Sorry to bother you, I also encountered this problem, can you tell me how your Vagrantfile is configured to solve this problem?
@zhengweidi I think you don't need anything special at all, just use port 22 and the IP of the virtual machine to connect.
I also have this, but think that it's not needed after all:
config.vm.provider "parallels" do |prl|
....
prl.customize ["set", :id, "--system-flags", "devices.net.sleep_disconnects_link=0; devices.net.dhcp.notify=0"]
end
This is something that I did not notice before when using Vagrant with Virtualbox, and that has surprised me a few times already since I switched to Parallels:
When I have an SSH session open into the VM and close my MacBook, the session will terminate (or be terminated) once I wake OS X from sleep.
Any idea where this might come from? Is this a special setting in Parallels?