I'm afraid you are absolutely right about that. It can still be done from the host using VBoxManage (menu support planned), though due to a bug it is not fully reliable in 4.3.22.emg wrote:Relevant setup information
Host: Windows Professional 7 Service Pack 1, two monitors
Guest: Arch Linux, kernel 3.18.6, xorg server 1.17.1, xrandr 1.4.3
In 4.3.20, disabling one of the two monitors in the guest caused the corresponding virtualbox window on the host to close (e.g. xrandr --output VBOX1 --off). With 4.3.22 disabling the monitor causes the window to go blank, but remain open.
I think it is related to this from the changelog:
X11 guests: prevent unwanted hiding of guest screens on multi-monitor guests (bug #13287)
But what about wanted (as opposed to unwanted) hiding of guest screens? I found it very useful. Is it possible in 4.3.22 to close a virtual box window from inside the guest?
Discuss the 4.3.22 release
Re: Discuss the 4.3.22 release
Re: Discuss the 4.3.22 release
How do you do that? Forgive me, I've read through the VBoxManage help many times and played around with it but I haven't found a way to do that while the guest is running. All I've found is the ability to add or remove monitors with modifyvm --monitorcount, but that requires a lock on the vm which is already held while it is running. What am I missing?michael wrote:I'm afraid you are absolutely right about that. It can still be done from the host using VBoxManage (menu support planned), though due to a bug it is not fully reliable in 4.3.22.
-
- Posts: 2
- Joined: 24. Feb 2015, 18:51
Re: Discuss the 4.3.22 release
to answer my own question issue is still present if you wanna do anything other than "browse" linux and actually need to compile something and use the cpu it will make mouse jitter for guest and host... unusablethor2002ro wrote:does this version still have that horrible mouse jitter when you start compiling something in the vm guest and uses 100% of the cpu? this was the only thing keeping me from moving from the horrible vmware....
sighhhh.... guess back to vmware
![Crying or Very sad :cry:](./images/smilies/icon_cry.gif)
and I don't have a paper pc.... FX8320 5ghz 32gb ddr3 1866 ssd and everything...
Re: Discuss the 4.3.22 release
VBoxManage controlvm ... setvideomodehint ...emg wrote:How do you do that? Forgive me, I've read through the VBoxManage help many times and played around with it but I haven't found a way to do that while the guest is running. All I've found is the ability to add or remove monitors with modifyvm --monitorcount, but that requires a lock on the vm which is already held while it is running. What am I missing?michael wrote:I'm afraid you are absolutely right about that. It can still be done from the host using VBoxManage (menu support planned), though due to a bug it is not fully reliable in 4.3.22.
Re: Discuss the 4.3.22 release
Regarding NIC LINK FLAPPING: it appears this problem is only in "Attached to" field value "NAT" ... if you choose "NAT Network" (which is intened to be EXPERIMENTAL), all works fine!!!
I say: better switch to "NAT Network" (which means other VMs on the same NAT network can see each other, they are behind "one" virtual router on one virtual segment, rather than "virtually physically" separated each behind its own "sw minigateway"), than using TESTing/bleeding release of whole VirtualBox package...
I even put two NICs on the virtual machine , one "NAT" and one "Nat Network" and when swapping between them, it was obvious the latter only worked properly, both using "virtio" driver and swithing them without reboots of the VM, no other parameters were changed, which I find to be enough strong empiric proof that "NAT" is broken but "NAT Network" works (maybe only thanks to the developpers having forgotten to implement that "improvement" also into "NAT Network"...?).
I say: better switch to "NAT Network" (which means other VMs on the same NAT network can see each other, they are behind "one" virtual router on one virtual segment, rather than "virtually physically" separated each behind its own "sw minigateway"), than using TESTing/bleeding release of whole VirtualBox package...
I even put two NICs on the virtual machine , one "NAT" and one "Nat Network" and when swapping between them, it was obvious the latter only worked properly, both using "virtio" driver and swithing them without reboots of the VM, no other parameters were changed, which I find to be enough strong empiric proof that "NAT" is broken but "NAT Network" works (maybe only thanks to the developpers having forgotten to implement that "improvement" also into "NAT Network"...?).
Re: Discuss the 4.3.22 release
based on some previous comments (hiding screens) and my today's experience, it would actually be very nice, if Virtualbox team just stopped producing broken "alfa" releases, and wrote some comprehensive documentation revealing all non-documented features and functions!
Re: Discuss the 4.3.22 release
We try to keep a balance between adding new features and stablisation work. Sometimes things do break. As we are a small team and this is an open source product we regularly put out test builds so that people in the wide world can help us to spot regressions. If you feel that we need more testing you might want to help encourage more people to try them out. And unfortunately, like many much larger teams, we do not have time to document everything to the last detail. This is also an area where users can contribute if they feel that the documentation needs improving.cepal wrote:based on some previous comments (hiding screens) and my today's experience, it would actually be very nice, if Virtualbox team just stopped producing broken "alfa" releases, and wrote some comprehensive documentation revealing all non-documented features and functions!
-
- Posts: 3
- Joined: 25. Feb 2015, 22:34
- Primary OS: Mac OS X other
- VBox Version: OSE other
- Guest OSses: OS X, Windows 7
Re: Discuss the 4.3.22 release
Well that wasn't fun, and took up time.
Popup from Virtualbox there's a new version "4.3.22", so having not had a problem with final builds before, I updated. Then going mad that PXE isn't working and messing around with network settings, cables, switching VMs, checking connectivity, checking the PXE server... then looking on here... BINGO, a bad update.
Ok, maybe PXE isn't that big a deal for everyone... ISOs work too, but come up, looking at the other issues, surely 4.3.22 in it's current form should have been pulled, or swiftly replaced by one of these test builds? Would have just saved me and possibly many others a wasted afternoon/evening.
Grumble over, as you were.
Popup from Virtualbox there's a new version "4.3.22", so having not had a problem with final builds before, I updated. Then going mad that PXE isn't working and messing around with network settings, cables, switching VMs, checking connectivity, checking the PXE server... then looking on here... BINGO, a bad update.
Ok, maybe PXE isn't that big a deal for everyone... ISOs work too, but come up, looking at the other issues, surely 4.3.22 in it's current form should have been pulled, or swiftly replaced by one of these test builds? Would have just saved me and possibly many others a wasted afternoon/evening.
Grumble over, as you were.
-
- Oracle Corporation
- Posts: 3362
- Joined: 7. Jun 2007, 09:11
- Primary OS: Debian Sid
- VBox Version: PUEL
- Guest OSses: Linux, Windows
- Location: Dresden, Germany
- Contact:
Re: Discuss the 4.3.22 release
The PXE boot problem exists only on Windows hosts, i.e. on one of the four major hosts we support. Every regression is annoying but most people will never experience one of them.
-
- Posts: 15
- Joined: 18. Aug 2014, 08:24
- Primary OS: MS Windows 7
- VBox Version: PUEL
- Guest OSses: W7-64, W10-64
- Location: Zürich, Switzerland
Re: Discuss the 4.3.22 release
Based on these fixes I have played around a little and updated all my guests accordingly.Frank Mehnert wrote:Discuss the 4.3.22 release here. See the changelog for details. Please concentrate on regressions. Of course, positive feedback is also welcome
Regarding the Shared Folders problem with Windows Guests: this seems to be a GAs snafu. Fixed GAs can be downloaded here.
Regarding the more or less frequent connection drops with NAT/NAT Network on Windows host: Fixed package can be downloaded from the test builds area.
Regarding PXE boot regression on Windows hosts: Fixed package can be downloaded from the the test builds area.
And this is the very first time ever since 4.3.14 that everything is just working fine and flawless.
My system: W7-64 Pro. host with various Windows guests (XP-32, W7-64 Pro, W8.1-64 Home, W8.1-64 Pro, W10-64 Preview, Server 2012R2)
Thanks to the development team and all contributors. Finally a great job!
Re: Discuss the 4.3.22 release
NETWORK ISSUE - new observation:
I've updated to the experimantal 4.3.23 (including guest additions) and found out - not sure if this is also in 4.3.22 but I assume it is:
- NAT Network: DHCP "service" provides only IP, but not DNS information (nameserver & search), so if these aren't in ie /etc/network/interfaces interface section (dns-servres and dns-search - works even for "dhcp" devices), you end up with EMPTY /etc/resolv.conf
- NAT (not network): DHCP service provides also DNS information, so that guest's /etc/resolv.conf is filled in - interestingly, it doesn't "copy" all search domains but only the dns suffix of the host
I changed dhclient.conf to DEMAND dns information - that stalled the client as it kept waiting in case of "NAT network", unlike in case of pure "NAT"...
just for the record:
host: Win7/64bit
guest: Lubuntu 14.04 LTS / 32bit (rolling upgrades since 11.10)
Virtualbox: 4.3.23 r98520
guest additions: 4.3.23_98490
I've updated to the experimantal 4.3.23 (including guest additions) and found out - not sure if this is also in 4.3.22 but I assume it is:
- NAT Network: DHCP "service" provides only IP, but not DNS information (nameserver & search), so if these aren't in ie /etc/network/interfaces interface section (dns-servres and dns-search - works even for "dhcp" devices), you end up with EMPTY /etc/resolv.conf
- NAT (not network): DHCP service provides also DNS information, so that guest's /etc/resolv.conf is filled in - interestingly, it doesn't "copy" all search domains but only the dns suffix of the host
I changed dhclient.conf to DEMAND dns information - that stalled the client as it kept waiting in case of "NAT network", unlike in case of pure "NAT"...
just for the record:
host: Win7/64bit
guest: Lubuntu 14.04 LTS / 32bit (rolling upgrades since 11.10)
Virtualbox: 4.3.23 r98520
guest additions: 4.3.23_98490
Re: Discuss the 4.3.22 release
I updated to 4.3.23 a few days ago and all worked quite well, but today the problem is back!!? Have tried rebooting etc. but problem persists.pl2014 wrote:VPN Problem
After upgrade to 4.3.22, when using VPN I have frequent disconnects and reconnects. This happens with less than one minute intervals and make the connection unusable.
Host OS is Windows 7 with latest patches. Guest OS is also Windows 7 with latest patches.
Connecting through VPN from the host OS works fine, problem only shows up when working in a machine in VirtualBox.
I am running a Cisco VPN from inside the VirtualBox and the VPN disconnects and reconnects all the time.
My Network is specified as NAT.
Any advice?
Update:
Problem solved - it was only partly related to Virtualbox and not a regression in 4.3.22. I will post the details for the record and in case others run into similar issues:
The problem of the Cisco Anyconnect VPN program flapping the connection every minute is a known problem ( http://www.cisco.com/c/en/us/support/do ... =286281272 ) and is related to the MTU of the connection being too big. I reduced the MTU and all worked well. Note: The problem only occurred when running the Anyconnect program inside the Virtualbox, not when running in the native Win environment. So apparently the setting of MTU within Virtualbox is per default is too high for some scenarios? Also adding to the challenge here is the fact that the problem only occurred when I was connected via WiFi to my router provided by my Internet cable provider; when connected by cable or using 3G modem I never had the problem.
Last edited by pl2014 on 1. Mar 2015, 15:26, edited 1 time in total.
-
- Oracle Corporation
- Posts: 2973
- Joined: 19. Dec 2007, 15:45
- Primary OS: MS Windows 7
- VBox Version: PUEL
- Guest OSses: Any and all
- Contact:
Re: Discuss the 4.3.22 release
So what changed? If it wasn't VirtualBox, what was it?pl2014 wrote:I updated to 4.3.23 a few days ago and all worked quite well, but today the problem is back!!?
Re: Discuss the 4.3.22 release
I was having the same problem. Running 4.3.22 and it was dropping and reconnecting every minute. It became really annoying. I'm running it on a Windows 7 64bit PC (completely updated), with the VM running Windows XP (completely updated). I just installed 4.2.23 r98674, and after 5min, it hasn't dropped the connection. I'll try to update later on whether this sticks or not, but working nicely so far.
Re: Discuss the 4.3.22 release
I was having the same problem (Constant network (ssh) disconnects, due to "carrier-change" detected) [or carrier-changed for search engines] , super annoying.
Anyway, I'm just posting to second that switching to a NAT Network as mentioned above (versus upgrading to the dev stream) fixed this issue as well (at least an hour of running well)
I also wanted to add those words so search engines find this post, because it wasn't easy to figure out the issue...
Anyway, I'm just posting to second that switching to a NAT Network as mentioned above (versus upgrading to the dev stream) fixed this issue as well (at least an hour of running well)
I also wanted to add those words so search engines find this post, because it wasn't easy to figure out the issue...