Re: [DNG] Qemu with Beowulf host / Ascii guest dies without much of an error message
On Fri, 16 Aug 2019, Lars Noodén via Dng wrote: > On 8/12/19 4:00 PM, Ralph Ronnquist via Dng wrote: > [snip] > > Well, a slightly irrelevant, and perhaps well known observation: I have > > come to think that the most flexible networking for my local VM's is the > > "vde mode". It does need a small amount of initial plumbing, with a > > (single) supporting tap, and then either a bridge or routing plus local > > dhcp. This ends up with a networking "portal" through a (shared) socket > > that the qemu processes happily connect to. > [snip] > > Thanks. That has been useful. The guest now is visible on the same > network as the host. I'm glad it worked out, I'm also using Qemu a lot (of course, on Devuan) but with less complex needs, in many cases to emulate Cortex chips running unikernel programs: no problems arise. and thanks Ralph for the "vde mode" tip, good foor for thought! it may serve well to replace the use of Docker in prototyping workflow. ciao ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Qemu with Beowulf host / Ascii guest dies without much of an error message
On 8/12/19 4:00 PM, Ralph Ronnquist via Dng wrote: [snip] > Well, a slightly irrelevant, and perhaps well known observation: I have > come to think that the most flexible networking for my local VM's is the > "vde mode". It does need a small amount of initial plumbing, with a > (single) supporting tap, and then either a bridge or routing plus local > dhcp. This ends up with a networking "portal" through a (shared) socket > that the qemu processes happily connect to. [snip] Thanks. That has been useful. The guest now is visible on the same network as the host. There are only a few guides out there, but this one is up to date and worked for me: https://wiki.qemu.org/Documentation/Networking I'll have to add the networking to rc.local or something. Then the VM gets started with this -net tap instead of the more complicated arrangement in the first message. /Lars ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Qemu with Beowulf host / Ascii guest dies without much of an error message
Lars Noodén via Dng wrote on 12/8/19 9:14 pm: > On 8/12/19 1:42 PM, Ralph Ronnquist via Dng wrote: >> Lars Noodén via Dng wrote on 12/8/19 8:07 pm: >>> [snip] >>> -net user,hostfwd=tcp::-:22 \ >>> -net user,hostfwd=tcp::8880-:80 \ >>> -net user,hostfwd=tcp::4443-:443 \ >>> -net nic,model=virtio \ >>> [snip] >> >> Won't those declaration set up multiple concurrent backends for the >> single guest NIC ? Shouldn't you rather join up all redirections into a >> single backend parameter? I can imagine that multple backends could well >> compete rather than collaborate (though to end up crashing is a bit >> insensitive). This is of course pure guess work... >> >> Ralph. > > Thanks. That was it. I am rather sure that invoking it the way shown > above /used/ to work even if it now causes qemu to crash: Multiple old > shell scripts I have from 2017 have that style of options, and worked, > but I'm not sure for which version of qemu they last ran on. > > Definitely, putting forwarding all under one option keeps it from > crashing. The qemu manual page does not warn against using multiple > "-net user," options though it explicitly says that hostfwd can be used > multiple times. I guess the right way is now like this: > > -net user,hostfwd=tcp::-:22,hostfwd=tcp::8880-:80,... > > The behavior has changed. I wonder if this is a bug in qemu? Well, a slightly irrelevant, and perhaps well known observation: I have come to think that the most flexible networking for my local VM's is the "vde mode". It does need a small amount of initial plumbing, with a (single) supporting tap, and then either a bridge or routing plus local dhcp. This ends up with a networking "portal" through a (shared) socket that the qemu processes happily connect to. With that, I can bring up my VM's willy-nilly, together or in isolation, all running as non-root user, and presented to the host (and on the network) as full featured machines without additional sysadmin; just like "user mode", but without its limitations. And faster, I believe. Ralph. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Qemu with Beowulf host / Ascii guest dies without much of an error message
On 8/12/19 1:42 PM, Ralph Ronnquist via Dng wrote: > Lars Noodén via Dng wrote on 12/8/19 8:07 pm: >> [snip] >> -net user,hostfwd=tcp::-:22 \ >> -net user,hostfwd=tcp::8880-:80 \ >> -net user,hostfwd=tcp::4443-:443 \ >> -net nic,model=virtio \ >> [snip] > > Won't those declaration set up multiple concurrent backends for the > single guest NIC ? Shouldn't you rather join up all redirections into a > single backend parameter? I can imagine that multple backends could well > compete rather than collaborate (though to end up crashing is a bit > insensitive). This is of course pure guess work... > > Ralph. Thanks. That was it. I am rather sure that invoking it the way shown above /used/ to work even if it now causes qemu to crash: Multiple old shell scripts I have from 2017 have that style of options, and worked, but I'm not sure for which version of qemu they last ran on. Definitely, putting forwarding all under one option keeps it from crashing. The qemu manual page does not warn against using multiple "-net user," options though it explicitly says that hostfwd can be used multiple times. I guess the right way is now like this: -net user,hostfwd=tcp::-:22,hostfwd=tcp::8880-:80,... The behavior has changed. I wonder if this is a bug in qemu? /Lars ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Qemu with Beowulf host / Ascii guest dies without much of an error message
Lars Noodén via Dng wrote on 12/8/19 8:07 pm: > [snip] > -net user,hostfwd=tcp::-:22 \ > -net user,hostfwd=tcp::8880-:80 \ > -net user,hostfwd=tcp::4443-:443 \ > -net nic,model=virtio \ > [snip] Won't those declaration set up multiple concurrent backends for the single guest NIC ? Shouldn't you rather join up all redirections into a single backend parameter? I can imagine that multple backends could well compete rather than collaborate (though to end up crashing is a bit insensitive). This is of course pure guess work... Ralph. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
