guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Offloading to a VM


From: Ludovic Courtès
Subject: Offloading to a VM
Date: Sun, 28 Aug 2016 16:30:52 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Hello!

David Craven <address@hidden> skribis:

> On Sun, Aug 21, 2016 at 7:38 PM, David Craven <address@hidden> wrote:
>> So guix doesn't work inside a vm - because /gnu/store is mounted
>> readonly. To be able to offload arm builds once guix system vm
>> --system=armhf-linux works, /gnu/store needs to be writeable.
>>
>> Can multiple daemons concurrently use the same store?
>>
>> or alternatively, can we move the
>>
>> (unless (zero? (system* unionfs "-o"
>>
>> "cow,allow_other,use_ino,suid,dev,max_files=65536"
>>                                 "/rw-root=RW:/real-root=RO"
>>                                 "/root"))
>>           (error "unionfs failed"))
>>
>> to after the 9p filesystems have been mounted, so that the unionfs
>> allows writing to /gnu/store too?
>
> I'd appreciate some ideas on how to best tackle this problem
> (offloading builds to a guix system vm instance) =)

Ooh, since I’m reading messages in the wrong order, I missed the
original intent.

If you want to offload to VMs of a different system type, you could of
course have a full blown VM with an SSH daemon running, and have the
main machine offload to that one (the VM would need to have its own
store and its own disk, though.)

However, a more efficient way to do that would be to use the “build
hook” mechanism of the daemon (this is how ‘guix offload’ gets invoked
by guix-daemon.)  That way, a full VM would not be needed; in fact, we
could probably use QEMU’s ability to run ELF programs directly:

--8<---------------cut here---------------start------------->8---
$ qemu-arm $(guix build coreutils -s armhf-linux |grep -v debug)/bin/uname -a
Linux pluto 4.7.0-gnu #1 SMP 1 armv7l GNU/Linux
$ uname -a
Linux pluto 4.7.0-gnu #1 SMP 1 x86_64 GNU/Linux
--8<---------------cut here---------------end--------------->8---

The idea was briefly discussed at
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20239>.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]