For network conectivity testing, you can try with "nc" to another TCP/UDP port.
El 03/11/16 a les 19:56, Brooke Wallace ha escrit: > Thanks for the sympathy Peter. Unfortunately the lack of documentation and > reasonable introductory guide is making this a non-starter for us. > > 1. The integratorcp test image does not have scp > the only command I can find for file transfer is tftp, but it looks like > no one uses this anymore > I also don't see another way to confirm network connectivity given that > ping is expected to not work. > > 2. I still don't understand why I can't map the disk image "arm_root.img" to > my host. > I assume it has something to do with the fact that its passed to qemu as an > -initrd image and not a -hda image? > fdisk does not show any partitions or offset for this image to use in the > mount command, but mount complains: > > $ sudo mount -t auto -o loop arm_root.img /mnt/qemu > mount: wrong fs type, bad option, bad superblock on /dev/loop1, > missing codepage or helper program, or other error > > In some cases useful info is found in syslog - try > dmesg | tail or so. > > There is nothing in dmesg or journalctl > > I'll can give "vrit" a try, but I'm looking for a working example that can be > mapped to real hardware, eg. RaspberryPI, Beagle Bone Black or something > similar. Working in a emulation for a virtual machine does me no good. Our > goal is to emulate actual hardware and ultimately understand how to modify > QEMU to add hooks and add emulations for new hardware. > > Lack of good initial user documentation and a set of working examples will be > a setback. One must be comfortable with and understand how the software is > supposed to work before considering modification and reverse engineering is > way too time consuming. > > I can see that lack of any API for adding emulations, or documentation of an > API is also going to be an issue for us here as well when considering whether > or not to invest our time in this effort. > > I know that QEMU is part of the Android emulation, and I wonder if going that > route may be more productive - although were really not interested in android. > > ________________________________________ > From: Peter Maydell [peter.mayd...@linaro.org] > Sent: Thursday, November 03, 2016 4:25 AM > To: Brooke Wallace > Cc: qemu-discuss@nongnu.org > Subject: Re: [Qemu-discuss] sharing files between host and guest > > On 2 November 2016 at 20:03, Brooke Wallace <bwall...@ramlabs.com> wrote: >> I'm new to QEMU and was able to pull the latest stable version and build it. >> I downloaded a simple test arm image that I found in one of the docs - >> arm-test-0.2.tar.gz and was able to run that w/o any problems. > > Firstly, sorry that this has been a bit of a painful first > experience. You're right that the documentation online is > generally not very good and I'd like us to do better there. > > One problem for ARM in particular is that QEMU has models of > a lot of different machines, which are generally very different. > So picking the right one can be confusing, especially if you're > used to x86 where every machine looks like a PC. ARM guest kernels > often won't work except on the machine they were built for. > For instance, the "integratorcp" machine you've been trying to > use is a very old development board (about 15 years old) and > it doesn't have PCI, IDE or very much memory. I wouldn't > recommend it unless you have a specific guest image which > you absolutely need to run on that particular board. > > About the only machine model I can really solidly recommend is > "virt" -- this is the board used for running KVM virtual machines; > it doesn't correspond to any particular bit of real hardware > but it has the best support for PCI, lots of memory, etc. > The only slightly awkward part is that it doesn't have > graphics out of the box (you might be able to plug in an > emulated PCI graphics card but really it expects to be used > via serial console). If you want 64-bit ARM then "virt" is > pretty much the only sensible choice. I'd also recommend it > for 32-bit. > > All the other boards I would suggest using only if you have > a specific positive reason to want to use that board rather > than "virt". > > (I'll have a look to see if there's a good tutorial for > using the 'virt' board; we don't have any documentation for > it officially on the QEMU wiki, because mostly we just > provide the models of the hardware and leave it to other > people to provide the guest software.) > > Some other suggestions: > > For networking for simple development purposes, > the default "user mode" networking is fine, and > there's no need to try to set up bridge networking. > Bridge mode networking is really intended for serious > x86-based virtual machines where networking performance > is important, and I think most users there don't try to > configure it by hand but use a management layer like libvirt > to do the job. I've never bothered with setting up bridge > mode in the 6 years I've been working on QEMU. > If you don't give QEMU any networking arguments you should > get the 'user mode' networking. The only important points to > note are: > (1) 'ping' doesn't work, so don't try to use it as a test > (2) you can't directly connect from outside the VM to > inside it unless you set up a specific port redirection > on the QEMU command line. Connecting from inside the VM > to outside works fine, though. > > For copying things into the VM I have two approaches: > (1) easiest is just to use 'scp' or similar inside the > VM to copy the file over the virtual network from the > host machine > (2) if there's a really huge amount of data, you can > shutdown the VM, and then loopback mount its filesystem > on the host PC to copy stuff in. Then unmount it from > the host before restarting the VM. > Other methods are also possible, but I've never needed to > investigate them. > > The good news is that although this is an awkward "speed > bump" in learning to work with QEMU, you only have to get > over it once -- if you have a working setup it tends to > stay working. This is part of why the documentation isn't > great, I think most developers have some test images that they > got working years ago so they don't need to re-establish > them from scratch. > > thanks > -- PMM >
