Connecting to rpi in qemu via ssh

[pepedog]

Step 5 went out with the ark, now (I think this is what you want)
https://wiki.archlinux.org/index.php/Netcfg#Configuring_a_bridge_for_use_with_virtual_machines_.28VMs.29
but with a change where you put the NETWORKS= entry
Probably, once you know what package files you need, you can download them and pacman -U to install

[Philoo]

Rpi in qemu is an epic saga on its own right.
I'm so happy I finally received my after 3 months...

anyway on qemu in general I would avoid bridging at the OS level and all that kind of things. I would use a port redirection at the user networking level. that part basically boils down to adding:
$this->bbcode_second_pass_code('', ' -redir tcp:2222::22 ')
at the end of the qemu invocation where 2222 is the port on your host machine where you'll be accepting connections and 22 is the ssh port on emulated rpi.

That's the simple part. The not so simple part is that usually Rpi on qemu is emulated with a boot environment provided on the host not on the target
[code -kernel zImage -append "root=/dev/sda2"][/code]

you need to extract that zImage from the first (FAT) partition of the sdcard image file (since the image file contains 2 partitions that's a fancy mount -o loop -offset <something I forgot> rpi.img /media/mountpoint ). You need to keep that external kernel zImage in sync with whatever was updated inside your virtual rpi because otherwise the modules won't load and among them the network driver that will receive the ssh connection.

then depending on your actual objective maybe a virtual rpi as a demon in your PC is not the best answer. I personnally have great mileage with the foreign chroot system:
http://tinkering-is-fun.blogspot.com/2009/12/running-arm-linux-on-your-desktop-pc_12.html
http://tinkering-is-fun.blogspot.com/2009/12/running-arm-linux-on-your-desktop-pc.html

Caveat Emptor: both qemu full virtualization and the foreign chroot take place in a different hardware environement and possibly in a totally different kernel space (especially the foreign chroot). this is perfectly fine for most (user land) applications but is likely to create differences (read trouble) when dealing with anything related to hardware.