GNU bug report logs - #41785
[PATCH] DRAFT services: Add 'hurd-in-vm service-type'.

Previous Next

Full log

Message #26 received at 41785 <at> debbugs.gnu.org (full text, mbox):

From: Jan Nieuwenhuizen <janneke <at> gnu.org>
To: Marius Bakke <marius <at> gnu.org>
Cc: Mathieu Othacehe <othacehe <at> gnu.org>, 41785 <at> debbugs.gnu.org
Subject: Re: [bug#41785] [PATCH] DRAFT services: Add 'hurd-in-vm service-type'.
Date: Fri, 12 Jun 2020 08:39:41 +0200

Marius Bakke writes:

Hello,

> Mathieu Othacehe <othacehe <at> gnu.org> writes:
>
>> So, I don't get why would we need to run a Hurd VM inside a VM. I've
>> been struggling a lot with running nested layers of virtualization (for
>> system generation before the recent patches), and the result is often
>> too slow to be really usable.
>
> Note that recent processors support nested layers of virtualization
> natively with little overhead, but it's disabled by default.

Ah!

> For an Intel processor, it can be enabled by adding this to your system
> configuration:
>
>   (kernel-arguments (cons "kvm_intel.nested=1" %default-kernel-arguments))

Is there an obvious downside to enabling this?

Great...So on the host I did

--8<---------------cut here---------------start------------->8---
root <at> dundal ~# rmmod kvm_intel
root <at> dundal ~# modprobe kvm_intel kvm_intel.nested=1
root <at> dundal ~# cat /sys/module/kvm_intel/parameters/nested
Y
--8<---------------cut here---------------end--------------->8---

and the interwebs told me that to start the VM, you have to add "-cpu
host"; so I started it using

--8<---------------cut here---------------start------------->8---
/gnu/store/k2b7nx34cwyi6yk49wgy4hg9mrwcmll5-run-vm.sh -cpu host -m 2G -device rtl8139,netdev=net0 -netdev user,id=net0,hostfwd=tcp:127.0.0.1:10022-:2222,hostfwd=tcp:127.0.0.1:25900-:25900
--8<---------------cut here---------------end--------------->8---

and trying to "ssh -p 20022 localhost" from inside the bare-bones VM now
prints

--8<---------------cut here---------------start------------->8---
qemu-system-i386: Slirp: Failed to send package, ret: -1
qemu-system-i386: Slirp: Failed to send package, ret: -1
qemu-system-i386: Slirp: Failed to send package, ret: -1
qemu-system-i386: Slirp: Failed to send package, ret: -1
qemu-system-i386: Slirp: Failed to send package, ret: -1
qemu-system-i386: Slirp: Failed to send package, ret: -1
key_exchange_identification: read: Connection reset by peer
Connection reset by 127.0.0.1 port 20022
--8<---------------cut here---------------end--------------->8---

...something networky with QEMU.  Ideas?

Janneke

-- 
Jan Nieuwenhuizen <janneke <at> gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.