summaryrefslogtreecommitdiff
path: root/hurd/running/qemu.mdwn
diff options
context:
space:
mode:
Diffstat (limited to 'hurd/running/qemu.mdwn')
-rw-r--r--hurd/running/qemu.mdwn19
1 files changed, 18 insertions, 1 deletions
diff --git a/hurd/running/qemu.mdwn b/hurd/running/qemu.mdwn
index a0b9e6da..df65eb7b 100644
--- a/hurd/running/qemu.mdwn
+++ b/hurd/running/qemu.mdwn
@@ -1,5 +1,5 @@
[[!meta copyright="Copyright © 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012,
-2013 Free Software Foundation, Inc."]]
+2013, 2014 Free Software Foundation, Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -275,6 +275,23 @@ but note that `ping` doesn't work with QEMU's user-networking stack.
If you want to connect from the host system to the Hurd system running in QEMU, you can use port forwarding in QEMU or to setup something more advanced, like bridged networking.
+
+### IRC, freenode, #hurd, 2014-02-12
+
+ <braunr> youpi: also, the problems i had with regard to accessing the
+ debian repository were caused by a qemu bug where, in nat mode, qemu is
+ unable to handle dns requests if the host dns servers are ipv6 ones
+ <youpi> yes, we've noticed that with a student of mine
+ <youpi> you may be interested by a patch we submitted to qemu-devel, that
+ adds ipv6 support to -net user :)
+ <braunr> :)
+ <braunr> for now i directly change resolv.conf
+ <youpi> braunr: the issue is that you have only ipv6 nameservers, right?
+ <braunr> yes
+ <youpi> there's not much better to do than that
+ <youpi> (patching resolv.conf inside the guest, or apply the ipv6 patch)
+
+
## Port Forwarding in QEMU
(In the following we assume we use kvm!)