I am using my gentoo as host os for kvm with vga passthrough for playing on windows, but I have problem with sound, it is not good quality, I hear something like crackles in sound. I am using pulseaudio (with --system mode) on host os, and tried different sample rates but didnt helped. My command for vm:
qemu-system-x86_64 \
-vga none \
-enable-kvm -m 10000 -cpu host -smp 8,cores=4,threads=2,sockets=1 \
-device ioh3420,bus=pci.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1 \
-device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on \
-net nic,macaddr=50:E5:49:57:74:E3 -net bridge,vlan=0 \
-soundhw hda \
-boot d \
-hda /dev/sdb \
-usb -usbdevice host:09da:000a
I tried setting PULSE_LATENCY_MSEC, QEMU_PA_SAMPLES, but didnt helped. I also checked with live cd on guest vm, to make sure if its not windows problem, but the result is the same.
I also tried setting -soundhw ac97, but there is no official support for ac97 on windows 10 and I have some delays with sounds, but less interference.
my audio is:
00:1f.3 Audio device [0403]: Intel Corporation Sunrise Point-H HD Audio [8086:a170] (rev 31) (snd_hda_intel on msi z170a m7),
and versions of qemu and pulseaudio:
QEMU emulator version 2.3.0, Copyright (c) 2003-2008 Fabrice Bellard
pulseaudio 5.0
Could anyone help with this?
I just saw your question after searching for pretty much this same problem myself and then found the solution on a you tube video about 5 mins later. Here is what I did and a link to the YouTube video is at the end. This little guide assumes Windows 10, you didn't specify so I have had to guess here:
First you need to switch Qemu to use AC97, for the soundhw option use ac97 i.e. -soundhw ac97 and also set QEMU_AUDIO_DRV to alsa (I also am setting the QEMU_PA_SAMPLES to 128 and not sure if that will affect things or not) QEMU_PA_SAMPLES=128 QEMU_AUDIO_DRV=alsa
Then start Windows and go to the Realtek website and download the AC97 Driver for Vista / Win7 Realtek AC97 download link, once downloaded extract this somewhere you will find it again.
Then for the next section you need to disable driver signature enforcement, I recommend watching the video for this part as it makes it a bit easier to see which option to click but it basically is:
Open Settings, go to Update & Security, Choose Recovery in the left pane, Choose Advanced Start-up, Choose Troubleshoot, Advanced Options, Choose Start Up Settings and then press the restart button.
Once restarted you need to choose option 7 which disables driver signature enforcement.
Once Windows comes back go into Device Manager, Right click the multimedia device and choose 'Update Driver Software' click browse on the next page and navigate to the realtek driver you downloaded earlier.
Let windows do its thing and hey presto crystal clear audio :)
The Youtube video I followed
Related
I have been developing the OS for a prototype device using hardware. Unfortunately, it's a very manual and buggy process to flash the OS each time and then debug the issues.
I'd like to switch to developing the OS in QEMU, so that I can be sure that the OS is loading correctly before going through the faff of programming the device for real. This will come in handy later for Continuous Integration work.
I have a full copy of the NVM device that is generated from my build process. This is a known working image I'd like to run in QEMU as a start point. This is ready to then be JTAG'd onto the device. The partition layout is:
P0 - loader - Flash of IDBLoader from rockchip loader binaries
P1 - Uboot - Flash of Uboot
P2 - trust - Flash of Trust image for rockchip specific loader
P3 - / - Root partition with Debian based image and packages required for application
P4 - data partition - Application Data
I have not changed anything with the Rockchip partitions (P0 - P2) apart from the serial console settings. When trying to boot the image though, nothing happens. There is no output at all, but the VM shows as still running. I use the following command to run it:
qemu-system-aarch64 -machine virt -cpu cortex-a53 \
-kernel u-boot-nodtb.bin \
-drive format=raw,file=image.img \
-boot c -serial stdio
I have no error information to go on to understand what is going on with it, where can I get more information or debug?
QEMU cannot not emulate arbitrary hardware. You will have to compile U-Boot to match the hardware that QEMU emulates, e.g. using make qemu_arm64_defconfig. The OS must also provide drivers for QEMU's emulated hardware.
If you want to emulate the complete hardware to debug drivers, Renode (https://renode.io/) is a good choice.
For anyone else trying to figure this out, I found good resources here:
https://translatedcode.wordpress.com/2017/07/24/installing-debian-on-qemus-64-bit-arm-virt-board/
and
https://azeria-labs.com/emulate-raspberry-pi-with-qemu/
Looking at the information though, you need to extract the kernel from your image and provide that to the qemu command line as an argument. You'll also need to append an argument telling the system which partition to use as a root drive.
My final command line for starting the machine looks like this:
qemu-system-aarch64 -machine virt -cpu cortex-a53 \
-drive format=raw,file=image.img,id=hd \
-boot c -serial stdio
-kernel <kernelextracted> -append "root=fe04"
Different Arm boards can be significantly different from one another in where they put their hardware, including where they put basic hardware required for bootup (UART, RAM, interrupt controller, etc). It is therefore pretty much expected that if you take a piece of low-level software like u-boot or a Linux kernel that was compiled to run on one board and try to run it on a different one that it will fail to boot. Generally it won't be able to output anything because it won't even have been able to find the UART. (Linux kernels can be compiled to be generic and include drivers for a wider variety of hardware, so if you have that sort of kernel it can be booted on a different board type: it will use a device tree blob, provided either by you or autogenerated by QEMU for the 'virt' board, to figure out what hardware it's running on and adapt to it. But kernels compiled for a specific embedded target are often built with only the device drivers they need, and that kind of kernel can't boot on a different system.)
There are broadly speaking two paths you can take:
(1) build the guest for the board you're emulating (here the 'virt' one). u-boot and Linux both have support for QEMU's 'virt' board. This may or may not be useful for what you're trying to do -- you would be able to test any userspace level code that doesn't care what hardware it runs on, but obviously not anything that's specific to the real hardware you're targeting.
(2) In theory you could add emulation support to QEMU for the hardware you're trying to run on. However this is generally a fair amount of work and isn't trivial if you're not already familiar with QEMU internals. I usually ballpark estimate it as "about as much work as it would take to port the kernel to the hardware"; though it depends a bit on how much functionality you/your guest need to have working, and whether QEMU already has a model of the SoC your hardware is using.
To answer the general "what's the best way to debug a guest image that doesn't boot", the best thing is usually to connect an arm-aware gdb to QEMU's gdbstub. This gives you debug access broadly similar to a JTAG debug connection to real hardware and is probably sufficient to let you find out where the guest is crashing. QEMU also has some debug logging options under the '-d' option, although the logging is partially intended to assist in debugging problems within QEMU itself and can be a bit tricky to interpret.
First, some background:
I suppose I've found a bug with KVM, at least on my system.
When I try to install Windows XP via virt-manager, the installer aborts/reboots.
But if I run a raw qemu-system-i386 command (see below), it succeeds.
From looking at the logs in /var/log/libvirt/qemu/..., the key difference is the "accel=kvm" argument (equivalent to -enable-kvm).
So, narrowing it down, this command succeeds:
qemu-system-i386 \
-m 512 \
-usb \
-cdrom path/to/WinXP_CD.iso \
-boot d \
"$image"
But this next command results in an infinite series of reboots. The XP installer starts, but after scanning the system, just reboots rather than proceeding:
qemu-system-i386 \
-enable-kvm \
-m 512 \
-usb \
-cdrom path/to/WinXP_CD.iso \
-boot d \
"$image"
Perhaps you don't believe I have KVM working properly on my system.
But, I can install other OSes (eg: FreeBSD) using KVM just fine. This seems to be XP-specific.
So now, my questions:
How do I force libvirt to NOT use KVM for a chosen VM? Ideally via virt-manager, but I'm fine with virsh too.
I imagine somewhere in the mess of XML is some setting, but I'm not terribly familiar.
aside: any idea where I should log this bug? Against KVM? Libvirt? QEMU?
Well, I managed to hack around this, but I'm sure there's a more pretty way.
Basically, that -enable-kvm option corresponds to the type="kvm" value in your domain XML file. See libvirt documentation.
But there seems to be no way to change this from virt-manager. I'm not familiar enough with virsh yet to do it that way either. So, I just manually edited my XML file like so:
$ sudoedit /etc/libvirt/qemu/myxp.xml
I did this while virt-manager was closed.
When I opened it, the setting did not seem to stick. For some reason, I seemed to need to run:
$ sudo virsh define /etc/libvirt/qemu/myxp.xml
to get it to stick.
Anyway, after that little dance, then in virt-manager, in the `Overview' tab for my VM, it says "Hypervisor: QEMU TCG", where it had "KVM" before.
And now, the XP installer works!
Again, probably a better way, but good enough for now.
Presumably, performance will be poorer with KVM disabled. I still don't know who to send a bug, or whether this is a QEMU or KVM issue, at its core.
You can change
<domain type="kvm">
to
<domain type="qemu">
as as stated in the documentation.
To edit xml of VM in virt-manager you should activate xml editing in parameters and press "xml" tab.
I am trying to use the qemu-system-arm.exe on Windows 10 to simulate an ARM environment.
I use below command to disable serial and graphic:
qemu-system-arm -machine versatilepb -kernel t.bin -nographic -serial
none
I set the -serial none because my t.bin doesn't touch the serial port of the QEMU virtual machine. So there should be no data on the serial line.
But when I type commands in the (qemu) prompt, it contains many unexpected control characters. Though the command seems still working.
QEMU 4.0.95 monitor - type 'help' for more information
(qemu) h[K[Dhe[K[D[Dhel[K[D[D[Dhelp[K
I also tried to use com0com to create a pair of virtual serial ports. And connect them as below.
But both ends show nothing as I type commands. I guess it was due to incorrect baud rate. So I tried a few but still no luck. As said above, I think the serial line is quite because there's serial communication happening.
I launched qemu the same way on Linux, the (qemu) prompt works perfect. Only Windows has such mess characters.
So how to redirect (qemu) output to Windows cmd console properly? I just want to check some machine states.
(Well, this is just a work around...)
I launch exactly the same command within a Cygwin shell, the mess characters disappear now...
ANSI support is missing in the Windows command console (before Windows 10 Terminal app).
Your com0com solution works just fine, at least for me (QEMU on Windows 8.1 emulating Debian MIPS).
All I had to do was to add the following, and then connect with PuTTY to COM9:
-chardev tty,path=COM8,id=hostcom8 -device pci-serial,chardev=hostcom8 -append "console=ttyS2" (I had ttyS0 and ttyS1 virtual serial ports)
I am trying to use qemu on a Windows machine to host Android x86. I am using the following command to start qemu:
qemu-system-x86_64.exe -vga std -m 2048 -smp 2 -soundhw ac97 -net nic,model=e1000 -net user -cdrom android-x86_64-8.1-r1.iso -hda android.img -accel haxm
I am having a problem enabling either whpx or haxm and no matter what I do the result is the same: qemu complains that
-machine accel=haxm: No accelerator found. The same for whpx.
I made sure that intel virtualisation and vtx are enabled in the BIOS, I made sure that both Windows Hypervisor Platform and Hyper-V are installed from Turn Windows Features On or Off, I installed HAXM using the Visual Studio 2017 installer, using the Android Studio installer, using the standalone installer downloaded straight from Intel's webpage and nothing.
What I find amusing is that Android Studio and VS both were able to run their emulators just fine with either haxm or whpx enabled. It's just qemu that is stubborn.
What else should I do to be able to use either one of those? If I ommit the -accel command, qemu starts just fine but the performance is horrible.
Note that I did not have multiple versions of HAXM installed at the same time nor did I have Hypervisor enabled when trying to use haxm and vice versa.
The option to enable HAXM is -accel hax not -accel haxm
-machine accel=haxm: No accelerator found means QEMU doesn't know about the requested accelerator.
If your HAXM would indeed not work the error would something like this:
Failed to open the HAX device!
Open HAX device failed
I'll need someone to walk me through setting up Wayland Desktop Environment with linux within a systemd-nspawn container.
How to set up your nested Wayland Desktop Environment with systemd-nspawn container, like VirtualBox
This tutorial walks you through setting up Wayland Desktop Environment with linux systemd-nspawn container on your computer. This is similar to VMware Workstation or VirtualBox, but linux only with minimal overhead performance.
A Quick Look at the final result
Features and benefits
✓ Hardware independent containerOS by the hardware abstraction with extremely efficient, minimal performance overhead method by systemd-nspawn container technology
✓ 100% portable among systemd enabled linux hosts, easy backup and recovery
✓ Direct rendering works such as 3D Desktop effects
✓ Video and Sound works
✓ Network works out of the box
✓ Less likely to mess up the hostOS and infrequent reboot operations for the hostOS and the hardware, instead, enjoy the instant virtual boot, poweroff and reboot of the containerOS.
Summary of How to
Launch kwin_wayland window,
that is nested on your current desktop environment.
Boot your container OS with systemd-nspawn
From the containerOS console:
(a) Launch a Desktop Environment such as XFCE or LXQt to the targeted kwin_wayland window.
(b) Simply prepare your favorite launcher app like synapse or xfce4-panel alone for a minimal setup.
Walk through
HostOS with minimal applications
The hostOS can be any linuxOS with systemd and the desktop environment can be either Wayland or legacy X11.
Alghough, Wayland hostOS is obviously preferable, the situation is still immature. As of March 2017, only Fedora 25 sports Wayland-based GNOME session as the default over the X11-based one, but the other distros does not. The latest version of KDE-Plasma is stable with X11/Xorg, but unstable with Wayland.
Probably, if you use GNOME for the host environment, go for Wayland, but if Plasma or other DE, be conservative to use X11/Xorg for stability.
This method works very well on both conditions, and personally, I use Arch Linux with KDE-Plasma(X11/Xorg).
Install systemd-nspawn and kwin_wayland
Some distro such as Arch already has systemd-nspawn, but others such as Ubuntu does not.
systemd-nspawn
Binary package “systemd-container” in ubuntu xenial
kwin-wayland
Binary package “kwin-wayland” in ubuntu xenial
Arch probably has kwin_wayland in xorg-server-xwayland package.
Launch kwin_wayland window
KWin is known as one of the most feature complete and most stable window managers.
This is a direct rendering enabled wayland window space managed by KWin, and nested on your current desktop environment.
Starting a nested KWin #KWin/Wayland - KDE Community Wiki
Since 5.3 it is possible to start a nested KWin instance under either X11 or Wayland:
export $(dbus-launch); \
kwin_wayland --xwayland &;
for fish shell
export (dbus-launch);
Boot your containerOS
sudo systemd-nspawn \
-bD /YOUR_MACHINE_ROOT_DIRECTORY \
--volatile=no \
--bind-ro=/home/YOUR_USERNAME/.Xauthority \
--bind=/run/user/1000 \
--bind=/tmp/.X11-unix \
--bind=/dev/shm \
--bind=/dev/dri \
--bind=/run/dbus/system_bus_socket \
--bind=/YOUR_DATA_DIRECTORY
Bind /YOUR_DATA_DIRECTORY of the hostOS to the containerOS, so that you can share the data directory between both, at the same time, your containerOS can stay as small and clean as possible and good for portability and backup/restore.
Login the containerOS console.
Typically, you build your container distro OS from minimal/server OS images.
Remember, you do not need to instal X11/Xorg display server, or wayland for containerOS since kwin_wayland window plays the role.
Launch a DesktopEnvironment (XFCE) to the targeted kwin_wayland window.
Remember, KWin is already running, and it's a feature complete and powerful WindowManager. You can launch and switch tasks with KWin via shortcut-keys, or prepare your favorite launcher app like synapse or xfce4-panel for a minimal setup.
However, if we need more user friendly Desktop Environments, just install and launch XFCE or LXQt that can run along with KWin.
From the containerOS console:
export XAUTHORITY=/home/YOUR_USERNAME/.Xauthority; \
export XDG_RUNTIME_DIR=/run/user/1000; \
export CLUTTER_BACKEND=x11; \
export QT_X11_NO_MITSHM=1; \
xfce4-session --display :1;
Maximize and remove the frame of the kwin_wayland window as default
Probably, you want to remove the frame of the containerOS, this is how to on Plasma (DE of the HostOS).
Final result
Confirm XFCE environment recognizes that running on XWAYLAND display.
XWayland implements a compatibility layer to seamlessly run legacy X11 applications on Wayland.
So far, more like exceptionally, if you install GUI libraries of wayland, with a certain flag, you can see the GUI applications run natively on wayland.
The left is kate window with Xorg/X11 compatiblity mode.
The right is the window with wayland native mode.
As you can see the native wayland app does not reflect the current window theme and the XFCE panel does not show the app task, and you cannot tell the difference of the performance as long as you use the normal applications of PC.
So, probably there's not much reason to pursuit wayland native mode app.
but the situation can be different for 3D games, and significantly different on small devices such as Raspberry Pi.
(Optional) legacy X11/Xorg
Althogh this tutorial focuses on wayland nested window, Xephyr (a nested X server that runs as an X application) has been around for a long time.
Unlike kwin_wayland, Xepher is not optimized for direct rendering and KWin Window manager is not bundled, so if you run KWin or other direct rendering composer on top of Xepher, things are going slow and inefficient, therefore, not recommended, but here's how:
Xephyr -ac -screen 1200x700 -resizeable -reset :1 &;
HostOS and ContainerOS interaction
You cannot Copy&Paste between HostOS and ContainerOS.
You may consider to use GoogleKeep to share contents between HostOS and ContainerOS, and of course, you shold have shared directories via systemd-nspawn bind.
Portability
You may "backup/recover" or "copy" or "move" the continerOS to anywhere regardless of
Kernel updates
Hardware drivers
Disk partitions (/etc/fstab etc.)
GRUB/UEFI configurations
or any other typical integration glitches!
Just be aware of the host kernel versions.
Backup
your machines directory ./machines
your machines backup directory ./machines-bak
your machine image directory arch1
cd ~/machines/
sudo tar -cpf ~/machines-bak/arch1.tar arch1 --totals
Recovery
cd ~/machines/
sudo tar -xpf ~/machines-bak/arch1.tar --totals
Backup Tools
The tar commands above may be not the smartest method, however, it's a proven robust method without any extra tool installations. Often, simple is best.
However, you may select various backup tools for more efficiency.
Synchronization and backup programs #ArchWIKI
Git base bup looks good and new.
What you may consider to remove from the container OS
Any hardeware dependent factors such as:
linux kernels with various drivers
/etc/fstab
NetworkManager.service of systemd
MIT License