After the latest upgrades of VirtualBox it looks like that the black console screens nightmare was returned, i thought that the great piece of emulation software VirtualBox is (it recently introduced a CPU cap limit that is fantastic), was the cause. vesafb framebuffer does not work , leading me to console black screens again, so i had to "fallforward" to uvesafb that i think is the most reliable, despite vesafb seems to work better with plymouth based configurations.
Lets figure out. Thanks to the fantastic guys at the ArchWiki i discovered that the set gfxpayload=keep that i always used to keep the GRUB 2 splash resolution at the same as the console was the reason, because initiate the vesafb or efifb on some distros. It is not a real problem if you are on a real machine it is only a little annoyance, to see your virtual machine resizing and enlarging madly. So i had to decide, without a console we can't work.
The solution is simple, every distributions has its specific settings, on Arch Linux we need to comment out the GRUB_GFXPAYLOAD_LINUX=keep line in /etc/default/grub or the set gfxpayload=keep entry in your /boot/grub/grub.cfg and remove any vga= or video= kernel parameter reference as stated in the document https://wiki.archlinux.org/index.php/Uvesafb to keep uvesafb working. The HOWTO is really well explained as usual, you need also the v86d package to be installed and the line "options uvesafb mode_option=YOUR_RESOLUTION scroll=ywrap" in /etc/modprobe.d/uvesafb.conf on Arch Linux or /etc/modules, cutting off "options", on Debian (IMPORTANT).
#inserting uvesafb module into the kernel
sudo modprobe uvesafb
#regenerating GRUB 2 configuration after making changes to /etc/default/grub
sudo grub-mkconfig -o PATH_TO_YOUR grub.cfg file (usually /boot/grub/grub.cfg)
#rebuiding initrd kernel image to load kernel modules at startup (DISTRIBUTION SPECIFIC)
mkinitcpio -p kernel26 (or your kernel name) on Arch Linux
update-initramfs -u on Debian