Custom Query (16363 matches)
Results (589 - 591 of 16363)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #7700 | invalid | A windows 7 x64 in VM in windows 7 x32 host, the vm crash | ||
| #15074 | fixed | AAAA lookups to natdnshostresolver break NAT networking | ||
| Description |
In my OSX 10.11.1 host I create a Linux guest with --natdnshostresolver1 on. Then, on the Linux guest, AAAA DNS lookups to ".local" domains which don't exist make NAT networking inoperable. Doring each lookup, all other connections to/from NAT interface are unresponsive between 5 to 10 seconds. No traffic goes through, not even ICMP (see https://github.com/weaveworks/scope/issues/769#issuecomment-174545662 ) I can easily reproducible with vagrant ... vagrant up vagrant ssh host -t AAAA scope.weave.local # Causes the nat interface to be unresponsive ... with the following Vagrantfile Vagrant.configure("2") do |config|
config.vm.box = "ubuntu/ubuntu-15.04-amd64"
config.vm.box_url = "https://cloud-images.ubuntu.com/vagrant/vivid/current/vivid-server-cloudimg-amd64-vagrant-disk1.box"
config.vm.provider :virtualbox do |vb|
vb.customize ["modifyvm", :id, "--natdnshostresolver1", "on"]
end
end
The bug in the NAT resolver may have to do with the OSX's DNS resolver timing out when looking up AAAA records in the .local domain. For instance: $ host www.google.com # fine www.google.com has address 216.58.213.164 www.google.com has IPv6 address 2a00:1450:4009:811::2004 $ host -t AAAA www.google.com # fine www.google.com has IPv6 address 2a00:1450:4009:811::2004 $ host something.local # not found, but fails as expected Host something.local not found: 3(NXDOMAIN) $ host -t AAAA something.local # causes a timeout! ;; connection timed out; no servers could be reached This would justify 10 second hangs in the lookups themselves but it shouldn't impact other connections to/from the NAT interface. More information: https://github.com/weaveworks/scope/issues/769#issuecomment-174521191 |
|||
| #15626 | fixed | AC97 and .vbox XML versions 1.13, 1.14 => fixed in SVN | ||
| Description |
If you have:
the <Audio> section gets deleted. Manually changing the XML version to 1.15 before you start VirtualBox is the current workaround. Not sure what it does to the rest of the configuration, but I've seen no ill side-effects so far. Host: OSX 10.9.5 Guest: Any |
|||

