Re: [Qemu-discuss] sharing files between host and guest

[Narcis Garcia]

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 address@hidden
> Sent: Thursday, November 03, 2016 4:25 AM
> To: Brooke Wallace
> Cc: address@hidden
> Subject: Re: [Qemu-discuss] sharing files between host and guest
> 
> On 2 November 2016 at 20:03, Brooke Wallace <address@hidden> 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
>