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.
Related
According to the QEMU user manual, I should be able to use the ,help to check the further info about an option.
From the sample command below, it seems pauth-impdef can be used to configure the -cpu max.
-cpu max,pauth-impdef=on
So I try to check what other configurations are available for -cpu max like below:
qemu-system-aarch64 -M virt -cpu max,help
But what I got is:
qemu-system-aarch64: Expected key=value format, found help.
This basically says nothing useful. So what should I do?
For Arm, the CPU feature options are documented on this page. The page also describes how to probe for supported feature names if you need to automate that.
I agree that it would be nice if 'help' worked on the -cpu option, so I've filed a wishlist bug about that.
We can use QMP (QEmu Monitor Protocol) commands to check a lot of things, including some available configuration entries.
For how to run QMP interactively, check:
https://wiki.qemu.org/Documentation/QMP
I'm working on an i386 bootloader and I'm running it with QEMU on my Apple Silicon machine, and everything works just fine, except I can't debug it: GDB does not (yet?) work on AS and LLDB sternly refuses to load a raw binary. This starts up fine:
$ qemu-system-i386 -s -S -drive format=raw,file=boot.bin,media=disk,if=floppy -no-fd-bootchk
but this errors out:
$ lldb boot.bin
(lldb) target create "boot.bin"
error: '/Users/morpheu5/src/boots/cube/boot.bin' doesn't contain the architecture x86_64
and I also tried this, because well, it's supposed to be i386, not x86_64:
$ lldb --arch i386 boot.bin
(lldb) target create --arch=i386 "boot.bin"
error: '/Users/morpheu5/src/boots/cube/boot.bin' doesn't contain the architecture i386
but it didn't make much of a difference. The inline help is not greatly helpful and I am having zero success searching online.
Now, I have alternatives: bochs has an internal debugger but the text-based interface is a bit clunky and I can't even figure out how to pre-set certain breakpoints -- I like to break on 0x7c00 or otherwise I have to step through the entire BIOS code -- and I can't even run the gui debugger despite having configured it with display_library: sdl2, options=gui_debug. The other alternative is a Raspberry Pi in which I could probably use gdb but I haven't tried this out yet and it's a Zero so it's not even that powerful anyway -- not that I need it, but I'd rather keep my workflow smooth...
It seems clear that lldb isn't recognizing the binary's format so I'm wondering if there's a way of just asking it to disassemble it as a 32 bit binary and just roll with it the best it can. In the end, all I really need is a way of seeing what is in memory, in the registers, and in the stack.
Any ideas?
After a few weeks of experimentation, it doesn't look like lldb is a viable option, but Bochs' command-line debugger was somewhat useful. Shame I couldn't get the GUI to run on macOS.
brew install x86_64-elf-gdb
qemu-system-i386 -s -S result.bin
x86_64-elf-gdb -ex "target remote localhost:1234" -ex "set architecture i8086" -ex "set disassembly-flavor intel" ยทยทยทยท
this works for me, but this don't use lldb.
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 want to know how to build grub 2 bootloader from it's source in ubuntu and test it with qemu emulator.
I would also like to change the default background image of grub2 bootloader in the new build?
Is this possible? If yes, how ?
Of course you can.
As shown on the GRUB website, the grub source code is available via git from git.savannah.gnu.org.
Then it is theoretically just a question of
$ ./autogen.sh
$ ./configure
$ make
$ sudo make install
However, depending on your platform, grub's default target platform may or may not be what you want. So you will need to decide which firmware platform you want to use in QEMU, which depending on your architecture can be something like
(pc) BIOS
coreboot
(U)EFI
ieee1275 (open firmware)
u-boot
Your mentioning of Ubuntu matches at least 3 possible options from the above, but I'm going to be boring and assume you mean x86_64/amd64. Since you will be running GRUB under QEMU, it does not really matter which of the two likely platforms ("pc" or "efi") your physical computer is running. So let's live a little and go for the (U)EFI variant.
You will need some prerequisites installed before configuring and building, so
$ sudo apt-get install build-essential autoconf automake
$ sudo apt-get build-dep grub-efi-amd64
So a practical build may look a bit like this:
$ # Next command is optionnal (languages):
$ ./linguas.sh
$ ./autogen.sh
$ # Next parameters are optionnal:
$ ./configure --prefix=$HOME/local --platform=efi
$ make
$ # Next command is optionnal:
$ make check
$ make install
The easiest way to get a functioning GRUB image is probably with the grub-mkstandalone command:
$ $HOME/local/bin/grub-mkstandalone -O x86_64-efi -o mygrub.efi
Note: To install grub on /dev/sda disk (instead of QEMU), use:
$ sudo grub-install /dev/sda
Note: If you don't see GRUB menu when booting, check this question. It involves pressing Shift when booting or editing /etc/default/grub to comment GRUB_HIDDEN_TIMEOUT.
Then you need some kind of UEFI image to run under your QEMU. The default choice for x86 is called OVMF and is part of Tianocore EDK2 - the de facto open source implementation of UEFI. Due to legal technicalities with regards to redistribution of the FAT filesystem driver, many Linux distributions (including Ubuntu) do not include a pre-built one. But have no fear, it is pretty straightforward to build one yourself.
However, I am not going to take this answer further off-topic than I already have, so all I am going to say is have a read through the OVMF README and look through one or two only slightly outdated blog posts about it.
I'mt trying to run beaglebone image on qemu following this tutorial. im using ubuntu 14.04 and installed qemu as shown in the tutorial
when ruining the command
qemu-system-arm -M beaglexm -drive if=sd,cache=writeback,file=Angstrom-TI-GNOME-image-eglibc-ipk-v2012.01-core-beagleboard-2012.01.11.img -clock unix -serial stdio -device usb-kbd -device usb-mouse -usb -device usb-net,netdev=mynet -netdev user,id=mynet
I got this error :
qemu-system-arm: symbol lookup error: qemu-system-arm: undefined symbol: libusb_get_port_numbers
I dont know if it's libusb version issue or what.
There is a similar bug report on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711589
I had the same message on my system. To solve it you have, as root, to link in the correct libusb.
sudo ln -sf /lib/x86_64-linux-gnu/libusb-1.0.so.0 /usr/local/lib/libusb-1.0.so.0
Start by running (YMMV on where the 'qemu' binaries are located):
ldd /usr/bin/qemu-system-arm
You should get a lot of output indicating what runtime libs Qemu needs and where the system is finding them. The fact that you are getting a 'missing symbol' error means that a shared library is on the system, it just isn't exporting the 'libusb_get_port_numbers' function signature.
If the above is true, then either A) your distro's 'libusb' packages don't export that function (it might have been deprecated) or B) you have some other 3rd party application that installed it's own 'libusb' (MPLABX does this, puts it in /usr/local/lib and symlinks back to /opt/microchip).
Without any more OS info etc, it's hard to help.