Et voilà there is the file test as i aspected.
Now do not forget to umont the partition

Code:

sudo umount root

I hope that this post will be useful for someone in future. If you have other solution to the initial problem, write it below. _________________Cerchi tutorial sull'informatica ed in particolar modo su GNU/Linux?https://www.youtube.com/user/FreeGNULinux

Well, the rest is pretty straight-forward (and a bit off topic), but perhaps describing it step by step will give me a kick to finaly script it... some day

The purpose of the following procedure is getting: "small image", "hosting a single application", "quickly". You can of course install whateer you want, but nothing you take for granted in case of regular installation is there by default. If you want dev or maintenance tools, you install them.

3) change portage default opts (e.g. parallelism), masks, and USE flags to match your needs for this particular image
4) build things you want to include in the VM image - and the more important part: build time dependencies
emerge -abk <application>

6) Deal with missing config files!
chroot ./target
ln -s /proc/mounts /etc/mtab
6a) create new user/reset root password etc.
6b) create /etc/inittab allowing you access without login. Carefull: if you followed exacly, you're using busybox as init at this point, it has slightly different format thatn sysvinit
Create bootloader's config file, tell it you want to boot /boot/kernel root=/dev/sda1 with initrd /boot/initrd
Ceate your init script under /etc/init.d/rcS. Almost always it will contain at least those 3 lines, however you might want to add your application, eth0, sshd, hostname etc as well:
#! /bin/sh
ifconfig lo up
mount -o remount,rw /
Bad news is busybox offers vi instead of nano. Good news is we can exit second chroot and use nano from stage3.

7) copy kernel and initramfs
Exit chroot completly, it won't be needed anymore.
Copy kernel to boot directory. I'm lazy so I copy kernel and initramfs from my host. THat initramfs will take a lot of time during boot, but screw that, I'm too lazy to build kernel tuned for qemu
Oh, and create ./target/dev/null and ./target/dev/console. Or simply cp -a /dev/null /dev/console ./target/dev/

funny part now, system is ready, we should launch it, but it's still not bootable yet. We have to fix it! I'm pretty sure there is a better way to do that, but I don't feel like hunting it right now. Qemu however has other neat feature we can use: direct linux boot.
Before we proceed, we want to make sure we don't break filesystem before we even start. It would be best to umount /target at this point, but since it's still a draft and something might be missing, I decided to flush buffers with sync instead. Make sure you don't change anything while qemu is running:
qemu-system-x86_64 -kernel <path to your kernel file on host machine> -append root=/dev/sda1 -initrd <path to initramfs on host machine> -hda raw_disk.img
And.... once it boots, install bootloader from within your VM.
I'm used to grub1, so all it takes is:
grub-install /dev/sda (or something like that.... or interactively: grub -> root (hd0,0) -> setup (hd0) -> quit )
shutdown vm and try boot it from image this time:
qemu-system-x86_64 -hda raw_disk.img

Yeah... That's it. When you see it boot from image and greet you with command line, shut it down again and umount everything. If it doesn't... that's when you're relieved you haven't cleaned up your mountpoints yet.
Gotta stuff it into some script, make that init smarter and install bootloader without reboot (And without looping it over iSCSI it feels such an overkill) and some day it might even get usable

Short explanation about that 2 step process: it is possible to build target system directly from host, and it is possible to simply convert stage 3 into target system. Using it as a build environment and only as a build environment provides the advantage of isolating build host from VM system.
We can have different profiles on build host and on VM, different masks, different everything as long as build host can run VM's binaries. At the same time, we don't emerge things we don't need inside the VM signifficantly reducing final size of our image.

Notice that I'm using binary packages whenever possible. Building packages for the first time might take hours, but then they will install to target in a few minutes. And since they are stored in shared /usr/portage on host, you can reuse some of them in other VMs. A notable example is glibc, which takes ages to build and will be used every single time you need anything not included in busybox.