I am trying to get a virtual machine running QNX on ARM64 virtual machine using QEMU.
I am not sure how to get installation iso. I don't know if am looking into the wrong direction.
QNX provides a virtual machine for VMware but not a generic way to create one for different architecture.
Please point me to a complete guide for the process if available.
Related
I have an IBM POWER7 Big-Endian with Debian-10-PPC64 host and Qemu-system-x86_64 (for running Linux x86 guests) installed. KVM module is present and loaded but I can't get it enabled.
Whatever attempts made result in "qemu-system-x86_64: invalid accelerator kvm". And "qemu-system-x86_64 -accel help" says that "Accelerators supported in QEMU binary: tcg"
Does Qemu in Debian PPC64 support KVM integration?
Is it possible compile Qemu from scratch and enable this feature? It would be necessary to compile kernel code too?
Thank you in advance.
KVM requires that the host and guest architecture are the same (because it is using the virtualization hardware of the host CPU). That means that you can't use it to run an x86-64 guest on a PPC host, and that's why qemu-system-x86_64 (when built for PPC hosts) says it does not have KVM support. You need to use qemu-system-ppc64 and a PPC64 guest OS.
I have a QorIQ (P2041) processor based IoT device firmware. I have uBoot, Kernel and initrd ramdisk. Whatever I do with qemu-system-ppc I can't get it to work. I suspect that qemu-system-ppc doesn't support QorIQ processors. Is there anyway for me to load and boot this firmware in Qemu or any other emulator?
U-Boot has configuration file qemu-ppce500_defconfig. You should be able to run the U-Boot built with this configuration using command
qemu-system-ppc -nographic -bios u-boot -M ppce500
The CPU can be specified via the -cpu parameter as e500mc.
To run your kernel it will need drivers for the hardware provided by the emulated machine like the E1000 network card and the NS16550 console.
Use the fdt command of U-Boot to get an overview of the available devices in the emulated machine.
Firmware binaries are generally very closely tied to the hardware they're built to run on -- they make assumptions about what hardware is available, what addresses in memory it can be found at, and so on. You need to use a firmware blob that corresponds to the hardware you're asking QEMU to emulate. Since QEMU doesn't emulate whatever your random IoT device is, you need to use a u-boot which matches the hardware QEMU actually has (as for example suggested in Xypron's answer).
Once you have booting firmware, you will likely still find you have exactly the same problem with the kernel -- it is built to run on one bit of hardware, and you're trying to run it on something different, and this simply won't work.
I have a desktop without a GPU, on which I would like to develop code; and a machine on some cluster which has a GPU, and CUDA installed, but where I really can't "touch" anything and on which I won't run an IDE etc. I don't have root on any of the machines, woe is me.
So, essentially, I want to be able to compile and build my CUDA code on my own GPU-less desktop machine, then just copy it and test it on the other machine.
Can this be done despite the two hindering factors: I seem to recall the CUDA installer requiring the presence of a GPU; playing with the kernel; and doing other root-y stuff.
Notes:
I'll be using the standalone installer, not a package.
I'm on Fedora 22 with an x86_64 CPU.
Assuming you want to develop codes that use the CUDA runtime API, you can install the cuda toolkit on a system that does not have a GPU. Using the runfile installer method, simply answer no when prompted to install the driver.
If you want to compile codes (successfully) that use the CUDA driver API, that process will require a libcuda.so on your machine. This file is installed by the driver installer. There are various methods to "force" the driver installer to run on a machine without a GPU. You can get started by extracting the driver runfile installer (or downloading it separately) and passing the --help command line switch to the installer to learn about some of the options.
These methods will not allow you to run those codes on a machine with no GPU of course. Furthermore, the process of moving a compiled binary from one machine to another, and expecting it to run correctly, is troublesome in my opinion. Therefore my suggestion would be to re-compile the code on a target machine. Otherwise getting a compiled binary to run from one machine to the next is a question that is not unique to CUDA, and is outside the scope of my answer.
If you have no intention of running the codes on the non-GPU machine, and are willing to recompile on the target machine, then you can probably develop driver API codes even without libcuda.so (or there is a libcuda.so stub that you could try linking against just for compilation-test purposes, which is installed by the CUDA installer, if you search for it: /usr/local/cuda/lib64/stubs). If you don't link your driver API code against -lcuda, then you'll get a link error of course, but it should not matter, given the previously stated caveats.
Fedora 22 is not officially supported by CUDA 7.5 or prior. YMMV.
If you don't run the driver installer, you don't need to be a root user for any of this. Of course the install locations you pass to the installer must be those that your user privilege allows access to.
I am a fresh man in kvm,qemu-kvm and kvm are both very complicated now.
Anyone can introduce some primers about qemu-kvm and kvm?
thanks very much!
KVM stands for kernel based virtual machine. it enables you to create as many number of virtual machine as you like. These machine can be of two types LVM based or Non-LVM based.
Those machine which are LVM based you can take live backup for them. for non-lvm based VM you cannot take live backup i.e. they will be paused when you take backup for them. please refer KVM home page KVM Home Page.
QEMU is a generic and open source machine emulator and virtualizer.When used as a machine emulator, QEMU can run OSes and programs made for one machine (e.g. an ARM board) on a different machine (e.g. your own PC). By using dynamic translation, it achieves very good performance. When used as a virtualizer, QEMU achieves near native performances by executing the guest code directly on the host CPU. QEMU supports virtualization when executing under the Xen hypervisor or using the KVM kernel module in Linux. When using KVM, QEMU can virtualize x86, server and embedded PowerPC, and S390 guests.
For managing the KVM VM's you need to install Libvirt which is the virtualization library. It provides you the tools for starting, suspending, resuming, cloning, restarting, listing of virtual machine. Please refer Libvirt home page for more reference.
If you are working on some backup or recovery process then I suggest you to go through this excellent perl script as well it will give a fair idea of how the backup and snapshot is being taken for KVM VM's.
KVM based virtual machines are not complicated once you go through the theory of them and start implementing them. I believe once you start working on them you will find fun in managing them.
Putting in a nutshell
QEMU : An emulator which translates the instruction of guest operating system to host operating system. As you can guess that translation has a certain cost, you will not see Guest machine working as fast as host machine.
For more info see the QEMU wiki
KVM (Kernal Virtual Machine): A module in Kernel which support Virtual Machine (host operating system) in hardware. By support I mean that if your guest architecture is same as host architecture, then certainly there is no need to translate the instructions as they can directly be executed by host. For this modern hardware are equipped with special registers and storage location which is leveraged by KVM. Also KVM is a module, some driver is needed to use the KVM, which is qemu also.
For more info see the KVM section in the same wiki.
QEMU-KVM : As I above mentioned, KVM is a module only, qemu is needed (or other) to use KVM. When KVM is used with QEMU, control transfers from QEMU to KVM and vice-versa over the execution.
Talking about KVM is talking about virtualization technology or about kernel modules (kvm.ko, kvm-intel.ko or kvm-amd-ko). Sometimes KVM is mentioned as a virtual machine, this is not correct, because KVM does not provide virtualized hardware.
Source
Has anyone had any experience debugging CUDA code on a server while coding on a workstation?
My laptop (Thinkpad T400) doesn't support CUDA, but I have access to a server with pair of NVIDIA GTX 295 cards that runs Linux.
Can I use NVidia's Visual Studio tools to debug remotely on the server?
Failing that, I also have an Ubuntu VM running on my laptop. Is there a debugger that I can use under Linux to debug on the server?
I really don't want to have to buy another laptop with dual NVidia cards.
Developing in c on a remote linux machine (like your server) is quite common. You can ssh onto the server from any client (like your laptop) to compile and run the code just as you would if you were sitting at the machine, and you can use gdb to debug your code in a terminal. You can also use ddd as a graphical front end to gdb or a linux IDE such as eclipse by forwarding X11 over ssh.
You can use cuda-gdb to debug your CUDA code in a terminal in exactly the same way. Unfortunately, there is not a visual cuda debugger for linux yet. However, it appears you can use ddd with cuda-gdb [source], as you have two gpus. I'm not sure about using cuda-gdb in eclipse.
Yes you can but you need to buy the Parallel Nsight Studio from Nvidia
After installing on the remote machine the NsightDebugServer you can upload and debug programs from
your cuda-less laptop.
Update
Turns out This solution requires a WINDOWS server in order to run the NsightDebugServer.
To connect to the linux machine from your laptop, use a remote connection.
install putty and a Xserver for windows and just login with
ssh -X username#cudaserver.
The environment would not be fancy as Visual Studio but you can do the basic steps of debugging.
Eclipse "might" have some support for remote gdb servers. Never experimented that (Emacs + gdb is sufficient for me)