qemu-discuss
[Top][All Lists]
Advanced

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

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


From: Peter Maydell
Subject: Re: [Qemu-discuss] sharing files between host and guest
Date: Thu, 3 Nov 2016 11:25:09 +0000

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



reply via email to

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