Re: Any way to trigger system_powerdown from a signal?

[Jakob Bohm via]

On 2024-07-24 19:35, Brett Neumeier wrote:

I'm trying to set up supervision for a QEMU virtual machine on a machine that 
uses s6 and s6-rc for service management.

I currently have my QEMU configured so that it shuts down gracefully when the 
"system_powerdown" monitor command is executed. With s6, though, the only 
idiomatic way that I can get the supervision frameowork to shut down a long-running 
process is to send it a signal. I've verified that I can get QEMU to terminate by sending 
it a SIGINT, SIGTERM, or SIGPWR; but all of those just cause it to terminate, they don't 
send an ACPI shutdown request to the guest operating system.

Is there any way to trigger the same "system_powerdown" mechanism by sending 
QEMU a signal? If not, can anyone suggest a way to add a signal handler that does that?


The method I usually use is to have the "monitor" listen for interactive
human commands on a per machine AF_UNIX socket like
/var/lib/qemu-wrapper/vmfoo/vmfoo.mon, then have my shutdown script does
this (within appropriate robustness conditions and checks):

# echo system_powerdown | socat - unix-connect:$socknam

I suspect Red Hat libvirt does something similar.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

Re: recover snapshot

[Jakob Bohm via]

On 2024-07-18 19:23, Pierrick Bouvier wrote:

Hi Jakob,

On 7/18/24 07:50, Jakob Bohm via wrote:

On 2024-07-16 22:22, Leonel Garcia Rosas wrote:

I accidentally delete the backing file. It was a very old 200GB file
from 2018. The snapshot is 1 TB and I can't use it.
My server is down.
I tried to recover the file with all the tools I found (testdisk,
photorec, rr-studios) with no luck.
I just issue a qemu-img info on the snapshot and the error shows up,
and I unmount the partition. Remount in ro and use the tools I
mentioned.

Is there something I can do to recover the files in the snapshot?
It is the /home directory from my server and I have customers waiting
for email and stuff.

I'll pay for the advice or the service
Thanks in advance!

Leonel



Well, you deleted all the virtual disk sectors that were unchanged since
the backing file.

To get back all disk sectors changed since the backing file, just
repoint the qcow2 image to an all zero backing file .



Interesting, it's an idea I suggested on IRC (where Leonel came first), 
but someone mentioned it would not work.
Will snapshot apply the diff "blindly", without checking src block (in 
backing file) was the one expected?


I believe qcow2 itself has no information about the expected sector
contents, but the file system and applications in the virtual machine
might.



I don't know the snapshot/qcow2 implementation details, and I wonder if 
there is some kind of checksum regarding the original disk, or simply a 
list of changes (write this block with new content X at addr Y).



DO NOT CREATE A NEW ALL ZERO 200MB FILE, it might overwrite any locally
recoverable part of the old backing file.  Instead perform the recovery
on a different real disk .   Also look at file recovery tools for the
file system that stored the lost 200MB file.  Ignore any AI Slop
articles that just tells you, you should have made a backup or installed
some delete protection software before the mistake.




Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

Re: recover snapshot

[Jakob Bohm via]

On 2024-07-16 22:22, Leonel Garcia Rosas wrote:

I accidentally delete the backing file. It was a very old 200GB file
from 2018. The snapshot is 1 TB and I can't use it.
My server is down.
I tried to recover the file with all the tools I found (testdisk,
photorec, rr-studios) with no luck.
I just issue a qemu-img info on the snapshot and the error shows up,
and I unmount the partition. Remount in ro and use the tools I
mentioned.

Is there something I can do to recover the files in the snapshot?
It is the /home directory from my server and I have customers waiting
for email and stuff.

I'll pay for the advice or the service
Thanks in advance!

Leonel



Well, you deleted all the virtual disk sectors that were unchanged since 
the backing file.


To get back all disk sectors changed since the backing file, just 
repoint the qcow2 image to an all zero backing file .


DO NOT CREATE A NEW ALL ZERO 200MB FILE, it might overwrite any locally 
recoverable part of the old backing file.  Instead perform the recovery 
on a different real disk .   Also look at file recovery tools for the 
file system that stored the lost 200MB file.  Ignore any AI Slop 
articles that just tells you, you should have made a backup or installed 
some delete protection software before the mistake.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

Re: Syncing the guest display resolution with the host in fullscreen

[Jakob Bohm via]

On 2024-07-08 08:00, Thomas Huth wrote:

On 06/07/2024 00.46, Anton Shepelev wrote:

Thomas Huth:


I had a quick look, but if I got this right, 1366x768 is
not a mode that fits into the standard EDID information,
since 1366 is not dividable by 8.


Thank you very much Thomas.  That also explains why get-
edid(1) does not work on this laptop.


See also
https://en.wikipedia.org/wiki/Extended_Display_Identification_Data#Limitations 


for some more information.


It says:

    For 1366x768 pixel Wide XGA panels the nearest resolution
    expressible in the EDID standard timing descriptor syntax
    is 1360x765 pixels, typically leading to 3 pixel thin
    black bars.

I can live with 3-pixel black bars, if QEMU will only enter
a corresponding full-screen mode.  What I cannot live with,
is a scaled image with intepolative blur or other artefacts.


QEMU already enables 1360x768 in the EDID information, see:


https://gitlab.com/qemu-project/qemu/-/blob/master/hw/display/edid-generate.c#L18 



... but I've got no clue why guests don't offer that screen resolution 
... I still assume this resolution is something special that the 
driver in the guest has to support explicitly.



1366x768 is a very common display size in real hardware, as it is the
closestapproximation to 16:9 at 768p, see the discussion at

 https://en.wikipedia.org/wiki/Display_resolution_standards#1366x768

Commercial display drivers are likely to have it as a tested use case,
possiblywith some non-EDID detection method.Maybe the DisplayID data
format allows returning 1366 pixels as width even when delivered over
an EDID connection.

Duckducking for 1366x768 EDID returns some troubleshooting conversations
about making various drivers (including the X11 nVidia driver) use it,
but no explanation of what such monitors typically return in their EDID
messages to drivers.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

Re: I doubt here

[Jakob Bohm via]

Only if the BIOS matches the virtual motherboard provided by Qemu .

For example, if the BIOS tries to configure a register controlling the 
USB controller on the real motherboard, it will only work if the virtual 
motherboard has the same USB controller at the same bus address.


The Qemu virtual motherboards are based on specific old Intel chipsets 
combined with custom virtual chips such as the paravirtual disk controller.


It's the same problem as installing a BIOS from a completely different 
motherboard on a different real motherboard, except you don't need a 
soldering iron to repair the damage to virtual hardware.


On 2024-06-21 15:39, Lucas Machado Zainote wrote:
Can I boot a nomral cumputer bios in qemu ? I mean a .bin file. let's 
say I have a motherborad bios file in this format can I use qemu to 
test it?


thank you for the great software.

Lucas Machado Zainote
lucasmzain...@aol.com


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

Re: qemu-img convert: Compression can not be disabled when converting from .qcow2 to .raw

[Jakob Bohm via]

Dear Sven,

Note that qcow2 files contain data saying how large the virtual disk is 
and what blocks in the virtual disk correspond to what blocks in the 
qcow2 file.


Thus adding extra all-0 blocks at the end of a qcow2 file using generic 
file manipulation tools like truncate or dd will not change the size or 
content of the virtual disk image that can be extracted as a raw file.  
Instead you need to resize the virtual disk inside the qcow2 file with 
"qemu-img resize" subcommand before converting to a raw image.  
Alternatively, you can use the generic file tools to change the size of 
the raw file directly.



On 2024-06-21 16:46, Sven Ott wrote:
Hi, I want to mount a VM image to a loop device and give it some 
excess space.


To do so, I download a .qcow2 file, add some 0 bytes with truncate, 
and then convert the image from QCOW2 to RAW format with qemu-img 
convert, like so:


```

GUEST_IMG=focal-server-cloudimg-amd64

wget https://cloud-images.ubuntu.com/focal/current/$GUEST_IMG

truncate -s 5G $GUEST_IMG.img

qemu-img convert -f qcow2 -O raw $GUEST_IMG.img $GUEST_IMG.raw

```

The problem is that the convert command throws away the 0-bytes which 
have been appended earlier, leaving me with a .raw image of the 
original size. As per the man page, the resulting image can be 
optionally compressed with the -c flag, indicating that not providing 
said flag would lead to an uncompressed resulting image.


I'm on Debian on x86_64; I've tried the qemu-img version 6.2 and 8.2 
unsuccessfully so far.


Any help would be appreciated!

Sven




Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

Re: target/i386: fix pushed value of EFLAGS.RF

[Jakob Bohm via]

On 2024-06-11 00:44, Paolo Bonzini wrote:

On Tue, Jun 11, 2024 at 12:39 AM Robert Henry  wrote:


Paolo:

Regarding your commit to QEMU 
https://github.com/qemu/qemu/commit/69cb498c56263a5ae484fd4fef920d3d3eea04c8

Four years ago I reported a bug 
https://gitlab.com/qemu-project/qemu/-/issues/249 and as part of cleaning up 
prior to retirement, I want to get my patch published.

Oh, thanks for pointing that issue out. I'm happy to help.

I see that your patch has the issue that it doesn't affect PUSHL_RA/POPL_RA.

Also, can you confirm that this is needed:

+  if (/*old_semantics ||*/ cpl == 0) {
+val = cpu_ldq_kernel_ra(env, *sp, ra);
+  } else {
+val = cpu_ldq_data_ra(env, *sp, ra);
+  }

and you cannot just use "val = cpu_ldq_data_ra(env, *sp, ra)"?

Looking at that code, does this imply that Qemu fails to emulate Ring 1 
and 2

of the x86 architecture?

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

Re: Query related with Emulation on QEMU

[Jakob Bohm via]

[Resending my reply from the right address...]

No, No, Yes

Sadly, there seems to still be no IA64 CPU emulation in Qemu (even the 
ability to run QEMU on actual IA64 hardware has been removed) or 
anywhere else, forcing all but the richest companies to not develop IA64 
software while the architecture existed.


For SunOS, look at the x86/x64 version of SunOS for emulation on x64 in 
KVM/HAXM mode.


Or use qemu-system-sparc under Sparc Linux for hardware speed or under 
any other hardware architecture with only the quick TCG emulation speed.


On 2024-05-30 08:10, Prabhu C wrote:

Hi QEMU team,

I have a query on QEMU emulation capabilities. I have a system with 
RHEL 8/CENTOS 8 installed with QEMU.
Can I emulate any of below hardware platform on top of RHEL 8  or 
CENTOS 8 using QEMU?


1) HP-UX 11.23 ia64
2) HP-UX 11.31 ia 64
3) SunOS 5.10

If yes, Can you give me some reference materials to perform the 
emulation of the above hardware using QEMU?



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

Re: Query related with Emulation on QEMU

[Jakob Bohm via]

No, No, Yes

Sadly, there seems to still be no IA64 CPU emulation in Qemu (even the 
ability to run QEMU on actual IA64 hardware has been removed) or 
anywhere else, forcing all but the richest companies to not develop IA64 
software while the architecture existed.


For SunOS, look at the x86/x64 version of SunOS for emulation on x64 in 
KVM/HAXM mode.


Or use qemu-system-sparc under Sparc Linux for hardware speed or under 
any other hardware architecture with only the quick TCG emulation speed.


On 2024-05-30 08:10, Prabhu C wrote:

Hi QEMU team,

I have a query on QEMU emulation capabilities. I have a system with 
RHEL 8/CENTOS 8 installed with QEMU.
Can I emulate any of below hardware platform on top of RHEL 8  or 
CENTOS 8 using QEMU?


1) HP-UX 11.23 ia64
2) HP-UX 11.31 ia 64
3) SunOS 5.10

If yes, Can you give me some reference materials to perform the 
emulation of the above hardware using QEMU?




--
Jakob Bohm, CIO, partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Soborg, Denmark. direct: +45 31 13 16 10 


This message is only for its intended recipient, delete if misaddressed.
WiseMo - Remote Service Management for PCs, Phones and Embedded

Re: base format

[Jakob Bohm via]

On 2024-04-25 14:51, lacsaP Patatetom wrote:
Le jeu. 25 avr. 2024 à 11:30, Peter Maydell > a écrit :


On Thu, 25 Apr 2024 at 09:55, lacsaP Patatetom
mailto:patate...@gmail.com>> wrote:
>
> hi,
>
> when using `qemu-img create`, why do I have to specify the
format of the base image ?
> can't `qemu-img` detect it itself ?

Image format detection isn't 100% reliable. Notably, a 'raw'
format image could in theory look like any of the other
image types if it happens to start with the right kind of data.

thanks
-- PMM


OK for the raw format, which can be anything, but not for the qcow2 
format, which is standardized (header).
in the absence of details, `qemu-img` could use the qcow2 format by 
default ?


qemu-img create [-b base [-F (qcow2*|raw)]] [-f (qcow2*|raw)] image [size]
But it cannot safely tell if the base file (usually a raw image or raw 
physical
disk partition) is qcow2 or araw file that just happens to begin with 
the magic

bytes that represent qcow2.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

Re: [Qemu-discuss] QEMU-i386-static question

[Jakob Bohm via Qemu-discuss]

The qemu-static chroot still uses the native (ARM) kernel and the
native (ARM) device driver for your serial port.

You just need to add the /dev/ttyUSB0 device file in the chroot.

Either as a bind mount accessing the same file in the native root,
or as a another device file inode created with the mknod
command to match the other one.

Then when x86 code opens "/dev/ttyUSB0" it will get the one in its
chroot, which points to the same kernel mode device object as the
one in the real (ARM) root.  Each I/O call (open, close, read, write,
ioctl etc.) will be passed from x86 code, through the qemulated x86
syscall to the identical ARM syscall, and then the ARM kernel will
access the real USB device on the real USB bus.

On 13/09/2019 14:22, Dr. Pedro E. Colla wrote:

Hi Peter,

Thank you very much for your kind and detailed response.

As it's a cross architecture setup chroot operates on a different platform
(ARM host vs. X86 guest) so using binfmt qemu-i386-static is invoked by the
chroot command, therefore when executed qemu has been already executed.
Under that configuration /dev/ttyUSB0 doesn't exists. I might install the
USB Prolific serial port drivers once in X86 but I don't believe that would
make the chrooted environment (under qemu) to share the port with the host,
does it?

Thanks in advance for your thoughts and tips on the subject. 73 de Pedro
LU7DID

On Fri, Sep 13, 2019 at 6:27 AM Peter Maydell 
wrote:


On Thu, 12 Sep 2019 at 21:28, Dr. Pedro E. Colla  wrote:

I'm trying to implement a chroot environment on a Raspberry Pi with the
ultimate intention to run Windows applications using wine.

To do that first an x86 chroot environment using the subject emulator is
used, then once inside a shell of it wine is invoked.

The whole thing works surprisingly well despite my initial expectations
given the small CPU resources available.

However, I do need for the Windows program to access the serial port
(/dev/ttyUSB0 at the host environment); the Windows problem is unable to
use that port despite different ways to configure it for wine to

recognize

it; but ultimately I found the problem is the x86 debian running under

qemu

isn't seeing it at all.

It seems this version of qemu doesn't handle the usual arguments to

define

character devices or usb devices.

QEMU has two modes of operation:
  (1) system emulation, where we emulate an entire hardware
  system for the guest, including various devices. In this mode
  we allow the user to configure how our emulated devices hook
  up to the host system via the command line arguments you mention

  (2) user-mode emulation, where we emulate just a single guest
  Linux process, and pass through all the system calls it makes
  to the host. In this mode there is no need for any kind of
  command line options to configure devices, because there are
  no devices to configure.

qemu-i386-static is the user-mode emulator, case (2). If you
would like binaries you run under it to be able to see
the host's /dev/ttyUSB0 you need to ensure that that (special)
file exists in the chroot before you run QEMU. Then the guest
binary will be able to open it, exactly as a host binary could.

After that, getting it to be visible to Windows programs running
under Wine is a Wine configuration question.





Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

Re: [Qemu-discuss] Using qemu to run a physical machine in parallel

[Jakob Bohm via Qemu-discuss]

On 04/08/2019 17:26, Yassine Chaouche wrote:

Dear qemu,

I have installed Linux Mint on my machine on /dev/sda5. Later, I 
installed MX Linux on /dev/sda9, but the installation of MX eventually 
didn't work well as I tried to do things. I need to fix MX linux, but 
each I change something I need to reboot the machine to see if it 
fixed it, and this is cumbersome/tiresome/awkward. What I would like 
to do is boot on /dev/sda5 (Linux Mint) and run MX Linux (/dev/sda9) 
in parallel. Can I achieve this with qemu ? I don't want to reinstall 
MX as a virtual machine, I would like to run and fix the already 
installed one.


Thanks for your tips !


In general, qemu can use your physical hard disk partition (/dev/sda9) as a
the storage for a virtual machine disk (such as /dev/sda), thus almost
allowing you to run your MX system under qemu, however there are some 
important

differences between the virtual and real machine that you will need to work
aroundyourself.

1. The virtual machine will have different "hardware", for example it will
  have a different network card (at least a different mac address) and a
  different graphics card.  It will also have less memory because it 
has to

  fit inside the free memory not used by your Mint system.

2. If you mount /dev/sda9 as a virtual hard drive, the virtual machine will
  see it as a physical disk, not a partition of a physical disk. This may
  confuse the MX startup scripts and configuration.
   As an alternative, you can layer a qcow2 image on top of the full 
/dev/sda,
  thus showing the virtual machine the entire disk, but redirecting all 
disk

  writes by MX to the qcow2 file.  Beware however that because the actual
  /dev/sda is changing every time your Mint system writes to it, the 
content
  of the Mint and shared partitions as seen by the virtual machine will 
be a
  garbled mess that you should not access.  Once you find a working MX 
setup,
  you will have to copy out _only_ the MX-only partition content to the 
real
  /dev/sda partitions while not using or overwriting the partitions 
belonging
  to Mint or shared, probably by doing funny stuff with qemu-nbd and 
dd, very

  very carefully.
   Tip: To make a small shared partitions (such as boot or EFI) completely
  separate for the virtual machine, mount the qcow2 image with qemu-nbd 
(without
  the virtual machine running!) and very carefully dd the initial 
contents of
  the physical partition to the qcow2 partition.  I am not sure which 
additional
  options are needed to prevent qcow2 from mapping those sectors back 
to the

  physical sectors that will change later.

3. If MX installs Linux kernels or bootloaders into common "boot" and/or 
"EFI"

  partitions, you will have to manually copy those files out to the Mint
  machine, then pass the kernels and initramfs images on the qemu 
command line

  to boot them.

Some configuration tips may be gleaned from "PV" (Physical to Virtual) 
conversion
instructions and scripts, but with the key difference of not actually 
trying

to store a complete copy of your physical /dev/sda inside itself.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded