I want to test some use-cases which need to run on 'ppc64le' architecture but I don't have a host machine with ppc64le architecture.
My host system is of x86_64 architecture. Is it possible to run VM with 'ppc64le' architecture on my host machine with x86_64 architecture?
Absolutely! The only caveat is that since you're not running natively, the virtual machine needs to emulate the target (ppc64le) instruction set. This can be much slower than running native instructions.
The way to do this will depend on which tools you're using to manage your virtual machine instances. For example, virt-manager allows you to select the architecture type when you're creating a new virtual machine. If you set this to ppc64el, you'll get a ppc64el machine. Other options (like disk and network devices) can be set just like native VMs.
If you're not using any specific VM management tools, the following invocation of qemu will get a ppc64el machine going easily:
qemu-system-ppc64le \
-M pseries # use the pseries machine model \
-m 4G # with 4G of RAM \
-hda ubuntu-18.04-server-ppc64el.iso # Ubuntu installer as a virtual disk
Depending on your usage, you may want to use the following options too:
-nographic -serial pty to use a text console instead of an emulated graphics device. qemu will print the console pty on startup - something like /dev/pts/X. Run screen /dev/pts/X to access it.
-M powernv -bios skiboot.lid to use the non-virtualised ppc64el machine model, which is closer to current OpenPOWER hardware. The skiboot.lid firmware may be included in your distro's install of qemu.
-drive, -device and -netdev to configure virtual disks and networking. These work in the same manner at x86 VMs on qemu.
I hosted centos7-ppc64le on my x86_64 machine(OS RHEL-7). I used qemu + virt-install for that. First install qemu as
wget https://download.qemu.org/qemu-3.1.0-rc1.tar.xz
tar xvJf qemu-3.1.0-rc1.tar.xz
cd qemu-3.1.0-rc1
./configure
make
make install
After installation check qemu-system-ppc64le is available from the command line. Then install virt-manager,virt-install,virt-viewer and libvirt for managing the VM's. Then I started the VM as
virt-install --name centos7-ppc64le \
--disk centos7-ppc64le.qcow2 \
--machine pseries \
--arch ppc64 \
--vcpus 2 \
--cdrom CentOS-7-ppc64le-Minimal-1804.iso \
--memory 2048 \
--network=bridge:virbr0 \
--graphics vnc
Related
i'm trying to use QEMU 5.x for research.
I got QEMU 5.2 source code from qemu.org and installed following instructions.
However, when i tried to run VM by this command:
qemu-system-x86_64 \
-monitor stdio \
--enable-kvm \
-m 4096 \
-cdrom ubuntu-20.04.iso \
-drive file=img.qcow,if=virtio \
-boot c
-rtc base=localtime \
-device virtio-keyboard-pci \
-vga virtio \
then the following texts are printed:
QEMU 5.2.0 monitor - type 'help' for more information
(qemu) VNC server running on 127.0.0.1:5900
then nothing shows up, while QEMU 4.x (used before) pops up a window showing guest ubuntu's GUI.
I'm using ubuntu 20.04. Hope anyone has breakthrough for this..
The message says that this QEMU is using the VNC protocol for graphics output. You can connect a VNC client to the 127.0.0.1:5900 port that it tells you about to see the graphics output.
If what you wanted was a native X11 window (GTK), then the problem is probably that you didn't have the necessary libraries installed to build the GTK support. QEMU's configure script's default behaviour is "build all the optional features that this host has the libraries installed for, and omit the features where the libraries aren't present". So if you don't have any of the GTK/SDL etc libraries when you build QEMU, the only thing you will get in the resulting QEMU binary is the lowest-common-denominator VNC support. If you want configure to report an error for a missing feature then you need to pass it the appropriate --enable-whatever option to force the feature to be enabled (in this case, --enable-gtk).
If you're running on Ubuntu and your apt sources.list file has deb-src lines in it, the easiest way to install all the dependencies that would get you the same feature list as the real Ubuntu QEMU package is to run "apt build-dep qemu". I recommend that you do that and then re-build QEMU, passing --enable-gtk to configure so you can confirm that the necessary dependencies were installed.
Good day,
So I am following this coreboot v3 + OpenBIOS tutorial Here .
In the instructions I have the following...
mkdir foo
cd foo
wget http://www.coreboot.org/images/9/9d/Qemu_coreboot_openbios.zip
wget http://www.coreboot.org/images/0/0d/Vgabios-cirrus.zip
unzip Qemu_coreboot_openbios.zip
unzip Vgabios-cirrus.zip
mv qemu_coreboot_openbios.bin bios.bin
cd ..
qemu -L foo -hda /dev/zero -serial stdio
I noticed that qemu has been replace or is implemented with qemu-system.
command I am running
qemu-x86_64 -L foo -hda /dev/zero -serial stdio
When I run the command, I see just qemu run it's typical and not find a disk.(which I expect since the disk switch points to /dev/zero) but none of the payloads run as I would expect from the tutorial.
What am I doing incorrectly?
Should I use a different version of qemu?
Should I create a dummy disk for this?
Qemu seems to be ignoring the files in the foo directory.
The examples are not up to date, as you have noticed by the renaming of qemu to qemu-system-x86_64.
I managed to get the examples to work using only the cirrus video card, and by renaming the outputs of the zips (bin - bios files to bios-256k.bin). I did this because by adding the -L option I specify the bios location and qemu will look for a file called bios-256k.bin as the bios. The command to run the bios with cirrus (all done while in the foo directory) was
qemu-system-x86_64 -L . -vga cirrus -serial stdio
Both machine types pc and q35 worked.
I've used buildroot to build a qemu compatible Linux kernel and root filesystem. I am emulating for the MPC8544DS machine and used the qemu_ppc_mpc8544ds_defconfig to generate these components. I was able to successfully build the kernel and the root filesystem. And was able to run it under qemu.
However when I tried to run uboot instead of the Linux Kernel (and the associated rootfs) it fails. Here is the way I invoke qemu to boot u-boot:
qemu-system-ppc -nographic -M mpc8544ds -m 512 -kernel ~/CrossCompilation/u-boot.bin and it fails like so:
Wrong image type 52, expected 2
qemu: could not load kernel '~/CrossCompilation/u-boot.bin'
I do not understand what else could be wrong. I've checked various blog posts over the internet and almost all of them use uboot.bin as the kernel (as opposed to srec and other formats)
could someone shed some light on the various image type numbers and which ones fit where?
UPDATE: This is how I compiled my u-boot
cd to u-boot dir
make distclean
make mrproper
make ARCH=powerpc CROSS_COMPILE=~/CrossCompilation/buildroot-2014.08/output/host/usr/bin/powerpc-buildroot-linux-gnuspe- MPC8544DS_defconfig
make ARCH=powerpc CROSS_COMPILE=~/CrossCompilation/buildroot-2014.08/output/host/usr/bin/powerpc-buildroot-linux-gnuspe-
Try removing the -kernel option. Make sure everything stay as is:
qemu-system-ppc -nographic -M mpc8544ds -m 512 ~/CrossCompilation/u-boot.bin
I compiled the Linux kernel (version 2.6.32) using the Emdebian ARM toolchain. Downloaded the initrd from Aurel's personal FTP server hosted on Debian here.
The ran qemu like so:
qemu-system-arm -M versatilepb -kernel zImage -hda hda.img -initrd initrd_versatile.gz -append "root=/dev/ram" -m 1024
Yet it fails with qemu reporting:
mount: mouting none of /run failed invalid argument.
Keen to hear if someone has something to say about this. As I search for it, could someone also let me know if it is possible to use an off the shelf initrd or is it related to the kernel version being run?
I was able to run the machine by cross compiling busybox, creating a cpio archive image and then using it like so:
qemu-system-arm -M versatilepb -m 128M -kernel zImage -initrd rootfs.img -append "root=/dev/ram rdinit=/bin/sh console=tty1"
Now that Ive got it working Ill investigate what those arguments actually mean.
I'm trying to get started on libvirt with VirtualBox as a virtualization solution. I installed everything and VirtualBox itself is running when using their VBoxHeadless command.
However, libvirt fails to connect to VirtualBox:
# virsh -c vbox:///session
libvir: error : could not connect to vbox:///session
error: failed to connect to the hypervisor
I could not find any hints in the libvirt documentation that point to whether I have to make any domain specific configuration before using virsh.
Does anyone have a hint? Or even better, maybe a tutorial that works through the way of using libvirt, virsh or it's APIs (my later goal) from the ground up.
If you are doing this on Ubuntu, then the problem is their libvirt package is built without VirtualBox support.
You can rebuild the package with support very easily. Something like:
apt-get source -d libvirt
sudo apt-get build-dep libvirt
dpkg-source -x libvirt*dsc
Go into the libvirt directory and edit debian/rules so that instead of --without-vbox it says --with-vbox. You can add an entry to the top of debian/changelog so the package is compiled as a different version (e.g., append ~local1 to the version).
dpkg-buildpackage -us -uc -b -rfakeroot
You'll get new .debs built in the directory above. Use dpkg -i to install the relevant ones (libvirt0, libvirt0-bin, and whatever else you want).
Double-check whether or not you have write access to /var/run/libvirt/libvirt-sock.
The socket file should have permissions similar to:
$ sudo ls -la /var/run/libvirt/libvirt-sock
srwxrwx--- 1 root libvirtd 0 2010-08-24 14:54 /var/run/libvirt/libvirt-sock
I think it could be helpful also to increase the libvirt logging capabilities by running this in your shell:
export LIBVIRT_DEBUG=1
There is Ubuntu PPA for libvirt with VirtualBox support: https://launchpad.net/~cxl/+archive/ubuntu/libvirt