Re: Ubuntu Linux broken after installation of QEMU 9.0.0 (latest version)

[Narcis Garcia]

Newest supported Qemu packages by Ubuntu GNU/Linux is 8.2.2 version:
https://packages.ubuntu.com/noble/qemu-system

I recommend you to use Stable only versions of operating system 
distributions, and its packages platform exclusively.


I suggest for this case to uninstall the "push" you manually made, and 
AFTER this reinstall package: ubuntu-desktop




El 25/5/24 a les 3:41, novaTopFlex ha escrit:
I have installed QEMU 9.0.0 and have effectively attempted to remove my 
native QEMU 6.2.0 installation by pushing the 9.0.0 commands into the 
“/usr/bin/“ directory. I can no longer access various elements of my 
Ubuntu Linux (22.04.1 LTS system formerly with native QEMU 6.2) system, 
and some of these applications are absolutely essential to my caseload 
such as Chromium. I have also lost access to the NetworkManager service 
because of pushing the installation of QEMU 9.0.0 forward and do not 
want to lose various pieces of my data to this issue. What is proper 
procedure for navigating through this issue?


Sent from Proton Mail *proton* for iOS


--
Narcis Garcia

Re: Mounting floppy images

[Narcis Garcia]

Better you share a folder than a disk image, between OS instances.


El 15/2/24 a les 6:13, dal1...@yahoo.com ha escrit:

I want to exchange files between my windows 10 host and Solaris 2.6 guest.  Can 
I use a floppy disk fat image option to read/write the contents of a folder?



--
Narcis Garcia

Re: VM file cache swapped on the host?

[Narcis Garcia]

Are you asking on Qemu list about your conversations with a different 
software?


Maybe ChatGPT project has a support or users mailing list, and/or a 
bugtracker to file issues.



El 16/1/24 a les 16:57, Christopher Pereira ha escrit:

1) Can someone please confirm this response from ChatGPT?

# Me:
is the ram used by a qemu-kvm VM as file cache swapped on the host when 
the host is low on ram?


# ChatGPT:
No, the RAM used by a QEMU-KVM (Kernel-based Virtual Machine) VM as file 
cache is not directly swapped on the host when the host is low on RAM. 
In a virtualized environment, the host manages the physical memory, and 
each VM operates within its allocated virtual memory space.


When the host is low on RAM, it may resort to swapping out its own 
processes or data to disk to free up memory. However, the content of the 
VM's RAM, including file cache, is typically managed separately. The 
host's memory management doesn't directly affect the VM's memory content.


It's worth noting that the VM's memory may be swapped within the VM 
itself if it's configured to use swap space. This is independent of what 
is happening on the host. If the VM's own memory management decides to 
swap some of its content to disk, it will do so within the virtualized 
environment.


2) If ChatGPT is right, I wonder how the host can know which RAM is used 
as file cache by the VM in order to treat it separately.


3) Related. Can you also please confirm my comments posted here some 
years ago:

https://unix.stackexchange.com/a/702729/526077
https://forum.proxmox.com/threads/vm-swap-best-practice.126514/




--
Narcis Garcia

Re: Directory does not fit in FAT16 (capacity 516.06 MB)

[Narcis Garcia]

Assuming a limit of 65536 sectors or clusters, 8 KiB clusters give a 
capacity of 536.87 MB (512 MiB).


"8 KB" would mean 8.000 bytes per cluster, and this can't have this 
suffix. There can be some confusion between MB and MiB in the subject too.



El 13/12/23 a les 13:39, lacsaP Patatetom ha escrit:
Le mer. 13 déc. 2023 à 13:29, Narcis Garcia <mailto:narcisgar...@gilug.org>> a écrit :


A FAT16 partition (0x06) can be as large as 2 GiB


El 13/12/23 a les 12:23, Alberto Garcia ha escrit:
 > On Wed, Dec 13, 2023 at 11:46:51AM +0100, lacsaP Patatetom wrote:
 >> to quickly test my efi application `./esp/EFI/BOOT/BOOTX64.EFI`,
I use the
 >> following command `qemu-system-x86_64 -accel kvm -machine q35 -m
1024 -bios
 >> /usr/share/edk2/x64/OVMF.fd -hda fat:./esp/ -snapshot` but it
has recently
 >> failed with the error message given in subject.
 >
 > I'm not familiar with the QEMU vvfat driver, but FAT16 does allow
 > larger filesystems, I suspect there's a limitation there?
 >
 >> for various reasons, i can't purge/reinitailize/empty the folder :
 >> what other options do I have with qemu or do I have to start from a
 >> lighter folder ?
 >
 > You can create a FAT image, put your files there using e.g mtools and
 > boot from that image:
 >
 > $ fallocate -l 1G esp.img
 > $ mformat -i esp.img
 > $ mcopy -i esp.img -s /path/to/files ::
 >
 > Berto
 >

-- 
Narcis Garcia



4Gb also seems possible : maximum size depends on cluster size.
qemu probably uses 8Kb clusters, which limits the size to 512Mb.


--
Narcis Garcia

Re: Directory does not fit in FAT16 (capacity 516.06 MB)

[Narcis Garcia]

A FAT16 partition (0x06) can be as large as 2 GiB


El 13/12/23 a les 12:23, Alberto Garcia ha escrit:

On Wed, Dec 13, 2023 at 11:46:51AM +0100, lacsaP Patatetom wrote:

to quickly test my efi application `./esp/EFI/BOOT/BOOTX64.EFI`, I use the
following command `qemu-system-x86_64 -accel kvm -machine q35 -m 1024 -bios
/usr/share/edk2/x64/OVMF.fd -hda fat:./esp/ -snapshot` but it has recently
failed with the error message given in subject.


I'm not familiar with the QEMU vvfat driver, but FAT16 does allow
larger filesystems, I suspect there's a limitation there?


for various reasons, i can't purge/reinitailize/empty the folder :
what other options do I have with qemu or do I have to start from a
lighter folder ?


You can create a FAT image, put your files there using e.g mtools and
boot from that image:

$ fallocate -l 1G esp.img
$ mformat -i esp.img
$ mcopy -i esp.img -s /path/to/files ::

Berto



--
Narcis Garcia

Re: swap

[Narcis Garcia]

[es]

Hasta donde yo he podido comprobar, Qemu se comporta como una aplicación 
normal, que no gestiona memoria de intercambio (swap) sino memoria que 
le proporciona el sistema y punto.


Si por ejemplo a una máquina virtual se le asigna una cuota 10 GiB de 
memoria RAM virtual, y el servidor que corre Qemu (huésped)) tiene 16 
GiB, puede funcionar todo en RAM mientras el servidor tenga esos 10 GiB 
físicos disponibles para la MV.
En caso que ese hipotético servidor ya estuviera usando más de 6 GiB 
(por ejemplo 8), ocurre que:
Cuando la MV use más de la RAM que dispone el servidor (toda su cuota de 
10 GiB), entonces el servidor deberá recurrir a lo que disponga:
Si el servidor tiene 16 GiB de RAM + 20 GiB de swap, proveerá a la 
máquina virtual como si tuviera 26 GiB de memoria indistinta.


Y si el servidor no tiene los recursos, el proceso de virtualización 
quebrará (OOM) en cuanto la MV haga uso de la cuota asignada.



El 20/11/23 a les 9:48, Pablo Buzón Garrido ha escrit:

Hola,

Tengo una pregunta acerca del comportamiento de qemu y la memoria de 
intercambio. Me gustaría saber de donde coge el sistema huésped su 
propia memoria de intercambio; si es de la misma RAM del host (es lo que 
me gustaría) o si es del disco duro (en este caso de qcow2) como lo 
haría un equipo normal sin virtualizar.


En mi caso lo que tengo es una orangepi 5 con un sistema ubuntu 22.04 
arm64 compatible con este equipo como Host. Y luego virtualizado con 
qemu tengo varios armbian (debian 12) arm64. He revisado con gparted en 
los huéspedes y veo que no tengo partición swap de intercambio, por lo 
que imagino se hará con la gestión de un fichero que no sé si se guarda 
en el disco duro virtual (qcow2) o si se guarda en la misma RAM del Host.


El Host he revisado y tampoco tiene partición swap de intercambio.

Muchas gracias
Un saludo!


--

Narcis Garcia

__
I'm using this dedicated address because personal addresses aren't 
masked enough at this mail public archive. Public archive administrator 
should remove and omit any @, dot and mailto combinations against 
automated addresses collectors.


--
Narcis Garcia

Re: swap

[Narcis Garcia]

[es]

Hasta donde yo he podido comprobar, Qemu se comporta como una aplicación 
normal, que no gestiona memoria de intercambio (swap) sino memoria que 
le proporciona el sistema y punto.


Si por ejemplo a una máquina virtual se le asigna una cuota 10 GiB de 
memoria RAM virtual, y el servidor que corre Qemu (huésped)) tiene 16 
GiB, puede funcionar todo en RAM mientras el servidor tenga esos 10 GiB 
físicos disponibles para la MV.
En caso que ese hipotético servidor ya estuviera usando más de 6 GiB 
(por ejemplo 8), ocurre que:
Cuando la MV use más de la RAM que dispone el servidor (toda su cuota de 
10 GiB), entonces el servidor deberá recurrir a lo que disponga:
Si el servidor tiene 16 GiB de RAM + 20 GiB de swap, proveerá a la 
máquina virtual como si tuviera 26 GiB de memoria indistinta.


Y si el servidor no tiene los recursos, el proceso de virtualización 
quebrará (OOM) en cuanto la MV haga uso de la cuota asignada.



El 20/11/23 a les 9:48, Pablo Buzón Garrido ha escrit:

Hola,

Tengo una pregunta acerca del comportamiento de qemu y la memoria de 
intercambio. Me gustaría saber de donde coge el sistema huésped su 
propia memoria de intercambio; si es de la misma RAM del host (es lo que 
me gustaría) o si es del disco duro (en este caso de qcow2) como lo 
haría un equipo normal sin virtualizar.


En mi caso lo que tengo es una orangepi 5 con un sistema ubuntu 22.04 
arm64 compatible con este equipo como Host. Y luego virtualizado con 
qemu tengo varios armbian (debian 12) arm64. He revisado con gparted en 
los huéspedes y veo que no tengo partición swap de intercambio, por lo 
que imagino se hará con la gestión de un fichero que no sé si se guarda 
en el disco duro virtual (qcow2) o si se guarda en la misma RAM del Host.


El Host he revisado y tampoco tiene partición swap de intercambio.

Muchas gracias
Un saludo!


--

Narcis Garcia

__
I'm using this dedicated address because personal addresses aren't 
masked enough at this mail public archive. Public archive administrator 
should remove and omit any @, dot and mailto combinations against 
automated addresses collectors.

Re: Way to force sync disk with cache=unsafe

[Narcis Garcia]

I think that "cache=unsafe" option it only allows writing data to be 
included in host's disk cache behaviour.
Assuming this, if I'm not wrong, when you flush host's disk cache you 
are already syncing the pending writings from Qemu.


To flush at VM hosting level to disk:
$ sync

Remember that a VM can keep its own disk cache pending to write (pending 
to send to host as disk writings). You may want to flush first at VM 
level and, after this, flushing at host level.


El 12/11/23 a les 17:11, YunQiang Su ha escrit:

I have a VM for source code building and running unittest.
The data in it is not critical generally. So I use "cache=unsafe" for it.

But I find that sometimes, I wish that I can force the data sync, for example
when a big project is finished to build.

A method I am using is to shutdown the VM and restart it.

Do we have any other better way to do so?



--
Narcis Garcia

Re: Qemu Uninstall

[Narcis Garcia]

I do with this command:

sudo apt --autoremove remove qemu qemu-system qemu-utils

...but probably your operating system provides a graphical package 
manager that helps to do it with a single click.



El 10/9/23 a les 18:55, Kai ha escrit:

Hi- I'm just wondering how I uninstall Qemu?


--

Narcis Garcia

__
I'm using this dedicated address because personal addresses aren't 
masked enough at this mail public archive. Public archive administrator 
should fix this against automated addresses collectors.

Re: Increasing the processor speed

[Narcis Garcia]

Host OS?
Guest OS?
Command line arguments for qemu?


El 6/6/23 a les 21:53, FrankaGames TVTR ha escrit:
the processor on the guest machine is set to 1 GHz, no matter what I 
did, I couldn't get above this speed, how can I increase the speed? 
small note I am running on android termux.


--
Narcis Garcia

Re: Accessing external harddisk from windows guest

[Narcis Garcia]

I use Qemu 5.2.0 with following direct parameter to attach real block 
device to virtual environment:


-device virtio-scsi -drive file=/dev/sdX,media=disk,index=0

In your case, you could share unlocked filesystem as a network resource.

El 28/4/23 a les 19:38, fam...@rawtext.club ha escrit:

Hi.

I have windows 7 guest running on a linux (debian 11) host.

I was trying to unlock a harddisk (WD) which was locked/encrypted with a
windows-only tool.

How can I expose the harddisk device to the windows guest?

Ideally, I wanted to unlock the harddisk device from within the vm and somehow
access the files in it from the linux host.

Does anyone know how to do this?
I've been scouring the internet for a long time, but found nothing that worked.

Found posts like this[1] suggesting that sharing between windows guest and
linux host is troublesome.

I'm using virt-manager, if that can help.

[1]: 
https://unix.stackexchange.com/questions/86071/use-virt-manager-to-share-files-between-linux-host-and-windows-guest



--
Narcis Garcia

Re: Max memory on VM (debian bullseye)

[Narcis Garcia]

I don't see "pc.ram" in your XML.

I see two tags:  and  to specify 12 GiB (not 12GB)


El 19/4/23 a les 16:18, Wilm Boerhout ha escrit:
I installed and configured KVM on a HP Zbook 15 laptop with 2x4 CPUs and 
24GB of memory


OS is Debian bullseye

No matter what I try, any VM with > 1GB virtual memory gives an error 
message on start:


Cannot set up guest memory,’pc.ram’: invalid argument.

In the target XML file, the amount of memory (I need 12GB for my VM) is 
expressed in KiB and appears correct.


Any suggestions?

/Wilm





   VMSx86

adb2de34-d2b9-4c23-96dc-f2ee9ab2977a

12582912

   12582912

   2

   

     hvm

     type='pflash'>/usr/share/OVMF/OVMF_CODE.fd


     /var/lib/libvirt/qemu/nvram/VMSx86_VARS.fd

     

   

   

     

     

     

     

   

   

   

     

     

     

   

   destroy

   restart

   destroy

   

     

     

   

   

     /usr/bin/qemu-system-i386

     

   

   

   

   

   

     

     

   

   

   

   

     

     

   

   

   

   

     

     

   

   

   

   

     

     

   function='0x7'/>


     

     

   

   function='0x0' multifunction='on'/>


     

     

   

   function='0x1'/>


     

     

   

   function='0x2'/>


     

     

   function='0x2'/>


     

     

     

   

   

   function='0x0' multifunction='on'/>


     

     

   

   function='0x0'/>


     

     

   

   

   function='0x1'/>


     

     

   

   

   function='0x2'/>


     

     

   

   

   function='0x3'/>


     

     

   function='0x0'/>


     

     

   

   

   

   function='0x0'/>


     

     

   

     

   

     

     

   

     

     

   

   

     

     

   

     

     

     

     

   

   

     

     

   function='0x0'/>


     

     

   heads='1' primary='yes'/>


   function='0x0'/>


     

     

   

     

     

   

     

     

   function='0x0'/>


     

   





--
Narcis Garcia

Re: OpenGL 4

[Narcis Garcia]

I understand that Johannes needs to know if qxl virtual device 
implements some of the OpenGL API.


Or maybe existing qxl drivers for guest OS implement OpenGL API.
https://www.spice-space.org/download.html


El 17/4/23 a les 19:18, Johannes Scheyerle ha escrit:

yes I know that and I think of that. But I still want to know if QEMU supports 
OpenGL4 or higher


Am 17.04.2023 um 19:09 schrieb Peter Maydell :

On Mon, 17 Apr 2023 at 18:04, Johannes Scheyerle  wrote:

Am 17.04.2023 um 19:03 schrieb Peter Maydell :

On Mon, 17 Apr 2023 at 17:55, Johannes Scheyerle  wrote:


Hey PMM,

thanks for the replay. But actually it doesn’t replay my question if it even is 
possible with QEMU. Is it?


It doesn't answer your question, but it does suggest that
you might find that it's not worth doing a lot of effort
to get accelerated graphics working if you don't think
the overall VM speed will be good enough at the end of
all that.

-- PMM





--
Narcis Garcia

Re: OpenGL 4

[Narcis Garcia]

What System?

El 17/4/23 a les 16:50, Johannes Scheyerle ha escrit:

Hey guys,

I'm using an Macbook Air M1 and looking for a possibility to use Windows on 
this computer. The most important thing is, that OpenGL 4 or higher supported. 
Can your System do this?

Best
Jo


--
Narcis Garcia

Re: Regarding Qemu tool performance

[Narcis Garcia]

What is exactly what it runs slow?
Operating system?
Guest (virtualized) system?
Qemu installation?


El 29/1/23 a les 6:09, Mallikarjuna G M ha escrit:

Hi Sir/Madam,

Myself is Mallikarjuna, i am new to Qemu environment, i installed Qemu 
in my Ubuntu system. Once after the installation i am facing very slow, 
is ther any additional configuration to be doing to make it fast, please 
provide your inputs.


Thanks and regards
Mallikarjuna


--
Narcis Garcia

Re: How to enlarge qemu display ?

[Narcis Garcia]

I do this by VNC display, and specifying scale factor to VNC client.


El 7/11/22 a les 10:49, Pierre Couderc via ha escrit:

I use a XP guest  in qemu on  linux.

I use a 4K monitor and my 800x600 XP windows is very very small, lost in 
the 4K monitor.


I do not want  to change my 800x600 size nor my monitor.

But I would like to enlarge the XP window so that a XP pixel be mapped 
on 4 monitor pixels, or even if possible on 2 or 2.5 or 3 pixels.


Is it possible...?

Thanks for any help !

PC




--
Narcis Garcia

Re: display resolution for win98

[Narcis Garcia]

I see current versions use "-machine" same as "-M".
Manpage does not explain this alias.

$ qemu-system-x86_64 -M ?
$ qemu-system-x86_64 -machine help

El 4/11/22 a les 1:32, Charlie Schindler ha escrit:

switching to my normal mail... gmx is a pain with the spam filter

interesting startup. added some of it. what is -M?

the net device you use: is this the hw from host?

On 11/3/22 14:44, Narcis Garcia wrote:
When Win98 VM is down, you can mount disk image and copy files there 
from host.

An easy utility is gnome-disk-image-mounter

My VM launch syntax with Qemu 5.2:

$ qemu-system-x86_64 -M pc -cpu pentium3 -m 1024 -device 
i82557b,netdev=net0 -netdev "user,id=net0" -display gtk -enable-kvm 
-device virtio-scsi -boot c -drive 
"file=windows98.img,media=disk,index=0" -no-hpet -rtc 
base=localtime,clock=host -soundhw sb16 -vga cirrus -global 
VGA.vgamem_mb=64


I've still not tested "Universal VESA-VBE" driver.

i use the 64MB version. i guess that would make the -global 
VGA.vgamem_mb=64 obsolute?


El 3/11/22 a les 2:10, chuck ha escrit: 

-- snip



--
Narcis Garcia

Re: display resolution for win98

[Narcis Garcia]

When Win98 VM is down, you can mount disk image and copy files there 
from host.

An easy utility is gnome-disk-image-mounter

My VM launch syntax with Qemu 5.2:

$ qemu-system-x86_64 -M pc -cpu pentium3 -m 1024 -device 
i82557b,netdev=net0 -netdev "user,id=net0" -display gtk -enable-kvm 
-device virtio-scsi -boot c -drive 
"file=windows98.img,media=disk,index=0" -no-hpet -rtc 
base=localtime,clock=host -soundhw sb16 -vga cirrus -global VGA.vgamem_mb=64


I've still not tested "Universal VESA-VBE" driver.


El 3/11/22 a les 2:10, chuck ha escrit:

thx

yeah, i used this wiki.

eventually i got it up and running:

as suspected the reason was the vmware crap in the converted to a qemu vm:

in the device manager i uninstalled all the vmware drivers, rebooted
(sometimes a restart works when using the "start" button restart, but i
usually i do a shutdown and restart qemu). after that qemu found the iso
(it did not before), after another reboot it did install all qemu drivers.

regarding the display: i now use the VESA 64MB (from the the link on the
wiki you mentioned). to get it on the vm before the cdrom worked: i used
guestmount and copied the driver on it. otherwise i use to create an iso
file and add it to the startup. do you know another way to put stuff on
the windoze 98 vm?

here the command line i use:

qemu-system-x86_64 -cdrom win98.iso -drive file=windows98.qcow2 -device 
sb16


or the newer form:

qemu-system-x86_64 -cdrom win98.iso -hda windows98.qcow2 -device sb16

the iso is bootable, but qemu seems to have issues with isos. did not
find a solution as it seems the solution differs from case to case. any
hint from your side?

On 11/2/22 13:29, Narcis Garcia wrote:

This can be useful for all issues:
https://en.wikibooks.org/wiki/QEMU/Windows_98


El 2/11/22 a les 1:26, chuck ha escrit:

Hi thx.

i tried with vga cirrus, did not have any effect other than not giving
the menu bar (alt-ctr-M does not work)

had no effect so far. i get the suspicion, that the reason is the vmware
tools. did uninstall them yesterday and will try to check again. will
try the SVGA later. until now it always gave me an error when starting
up, saying that driver is wrong as soon as i go beyond 16 colors.

Regarding the freeze: same here. did not get it the restart to work (it
did under vmware, which does not run on my machine as it has no bios
entry for virtualization).

(btw. sorry your email gave permanent error, so reply here)

On 11/1/22 17:01, Narcis Garcia wrote:

Sorry: Windows 98's default Cirrus driver works.
And "Cirrus Logic 7548 PCI" uses better color depths but runs slower.

+ I've tried to set to Qemu:
 -global VGA.vgamem_mb=64
But it does not seem to have effect.

OFF TOPIC:
-> Do you know how to let Windows 98 reboot in a VM instead of
freezing?


El 1/11/22 a les 10:32, Narcis Garcia ha escrit:

Qemu's "-vga cirrus" works for me.
Windows 98's "Super VGA 1600x1200" works for me.


El 1/11/22 a les 10:18, chuck ha escrit:

Hi

i am using qemu-system-x86_64 (on ubuntu 22.04) with a win98 vm image
converted to qcow2.

it starts all ok, but i can't get it beyond 6 color 640x320
resolution.

using the svga driver installed from the win98se disk just gives an
error that it is not compatible after a reboot.

what driver do i need to get the 1024x768x16 resolution. -g does not
work here.

i did download a vesa driver, but don't know how to add it the vm.

here the command i use:

qemu-system-x86_64 -cdrom win98.iso -drive file=windows98.qcow2 -m
512
-vga cirrus  -device sb16 -display sdl.

thx

chuck














--
Narcis Garcia

Re: display resolution for win98

[Narcis Garcia]

This can be useful for all issues:
https://en.wikibooks.org/wiki/QEMU/Windows_98


El 2/11/22 a les 1:26, chuck ha escrit:

Hi thx.

i tried with vga cirrus, did not have any effect other than not giving
the menu bar (alt-ctr-M does not work)

had no effect so far. i get the suspicion, that the reason is the vmware
tools. did uninstall them yesterday and will try to check again. will
try the SVGA later. until now it always gave me an error when starting
up, saying that driver is wrong as soon as i go beyond 16 colors.

Regarding the freeze: same here. did not get it the restart to work (it
did under vmware, which does not run on my machine as it has no bios
entry for virtualization).

(btw. sorry your email gave permanent error, so reply here)

On 11/1/22 17:01, Narcis Garcia wrote:

Sorry: Windows 98's default Cirrus driver works.
And "Cirrus Logic 7548 PCI" uses better color depths but runs slower.

+ I've tried to set to Qemu:
 -global VGA.vgamem_mb=64
But it does not seem to have effect.

OFF TOPIC:
-> Do you know how to let Windows 98 reboot in a VM instead of freezing?


El 1/11/22 a les 10:32, Narcis Garcia ha escrit:

Qemu's "-vga cirrus" works for me.
Windows 98's "Super VGA 1600x1200" works for me.


El 1/11/22 a les 10:18, chuck ha escrit:

Hi

i am using qemu-system-x86_64 (on ubuntu 22.04) with a win98 vm image
converted to qcow2.

it starts all ok, but i can't get it beyond 6 color 640x320 resolution.

using the svga driver installed from the win98se disk just gives an
error that it is not compatible after a reboot.

what driver do i need to get the 1024x768x16 resolution. -g does not
work here.

i did download a vesa driver, but don't know how to add it the vm.

here the command i use:

qemu-system-x86_64 -cdrom win98.iso -drive file=windows98.qcow2 -m 512
-vga cirrus  -device sb16 -display sdl.

thx

chuck










--
Narcis Garcia

Re: display resolution for win98

[Narcis Garcia]

Sorry: Windows 98's default Cirrus driver works.
And "Cirrus Logic 7548 PCI" uses better color depths but runs slower.

+ I've tried to set to Qemu:
 -global VGA.vgamem_mb=64
But it does not seem to have effect.

OFF TOPIC:
-> Do you know how to let Windows 98 reboot in a VM instead of freezing?


El 1/11/22 a les 10:32, Narcis Garcia ha escrit:

Qemu's "-vga cirrus" works for me.
Windows 98's "Super VGA 1600x1200" works for me.


El 1/11/22 a les 10:18, chuck ha escrit:

Hi

i am using qemu-system-x86_64 (on ubuntu 22.04) with a win98 vm image
converted to qcow2.

it starts all ok, but i can't get it beyond 6 color 640x320 resolution.

using the svga driver installed from the win98se disk just gives an
error that it is not compatible after a reboot.

what driver do i need to get the 1024x768x16 resolution. -g does not
work here.

i did download a vesa driver, but don't know how to add it the vm.

here the command i use:

qemu-system-x86_64 -cdrom win98.iso -drive file=windows98.qcow2 -m 512
-vga cirrus  -device sb16 -display sdl.

thx

chuck






--
Narcis Garcia

Re: display resolution for win98

[Narcis Garcia]

Qemu's "-vga cirrus" works for me.
Windows 98's "Super VGA 1600x1200" works for me.


El 1/11/22 a les 10:18, chuck ha escrit:

Hi

i am using qemu-system-x86_64 (on ubuntu 22.04) with a win98 vm image
converted to qcow2.

it starts all ok, but i can't get it beyond 6 color 640x320 resolution.

using the svga driver installed from the win98se disk just gives an
error that it is not compatible after a reboot.

what driver do i need to get the 1024x768x16 resolution. -g does not
work here.

i did download a vesa driver, but don't know how to add it the vm.

here the command i use:

qemu-system-x86_64 -cdrom win98.iso -drive file=windows98.qcow2 -m 512
-vga cirrus  -device sb16 -display sdl.

thx

chuck




--
Narcis Garcia

Re: Running server from within qemu

[Narcis Garcia]

I suppose this is what you need to use Qemu from same kernel type (both 
in guest and host):


https://qemu.readthedocs.io/en/latest/user/

(Linux -> Linux)
(BSD -> BSD)

OS does not matter: Kernel does.


El 17/10/22 a les 0:02, தாசெ ௩ ha escrit:

Hi,

Is it possible to host a simple http/tcp server on a Linux running on 
qemu, without any accompanying vm (KVM), and hit that http server from 
the host OS (say Windows)? What options should I choose in army (command 
line args) to run any TCP based server from within qemu?


Thankyou


--
Narcis Garcia

Re: Why is Qemu slow?

[Narcis Garcia]

sks: % tm_act Kbps  tps    Kb_read   Kb_wrtn
cd0   0.0   0.0   0.0  0 0
hdisk0 *100.0*   0.0   0.0  0 0

my ubuntu 20.04 :
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
   12.53    0.00    0.50    8.65    0.00   78.32

Device tps    kB_read/s    kB_wrtn/s    kB_dscd/s
kB_read    kB_wrtn    kB_dscd
dm-0  0.00 0.00 0.00 0.00  
0  0  0
dm-1    181.00 0.00   712.00 0.00  
0    712  0
fd0   0.00 0.00 0.00 0.00  
0  0  0
loop0 0.00 0.00 0.00 0.00  
0  0  0
loop1 0.00 0.00 0.00 0.00  
0  0  0
loop2 0.00 0.00 0.00 0.00  
0  0  0
loop3 0.00 0.00 0.00 0.00  
0  0  0
loop4 0.00 0.00 0.00 0.00  
0  0  0
loop5 0.00 0.00 0.00 0.00  
0  0  0
loop6 0.00 0.00 0.00 0.00  
0  0  0
loop7 0.00 0.00 0.00 0.00  
0  0  0
loop8 0.00 0.00 0.00 0.00  
0  0  0
loop9 0.00 0.00 0.00 0.00  
0  0  0
sda 103.00 0.00   632.00 0.00  
0    632  0


why ?

thank you for your answers
Pascal







--
Narcis Garcia

Re: Problemas en la instalacion

[Narcis Garcia]

Te sugiero previamente:
$ sudo pacman -Syyu


https://forum.manjaro.org/t/cannot-install-qemu/53159
https://linuxhint.com/update-all-packages-manjaro-linux/


Narcis Garcia

El 12/8/22 a les 19:15, Paola Candy Mamani Gonzales ha escrit:
Mi sistema operativo es un Manjaro 64 bit, estoy intentando instalar 
QEMU y esto es lo que me aparece.

[manjaro@manjaro-pc ~]$ sudo pacman -S  qemu
:: Existen 3 proveedores disponibles para qemu:
:: Repositorio extra
   1) qemu-base  2) qemu-desktop  3) qemu-full
[manjaro@manjaro-pc ~]$ sudo pacman -S qemu-base qemu-desktop qemu-full
resolviendo dependencias...
advertencia: no se pudo resolver «edk2-ovmf», una dependencia de 
«qemu-system-x86»
advertencia: no se pudo resolver «seabios», una dependencia de 
«qemu-system-x86»
advertencia: no se pudo resolver «qemu-system-x86», una dependencia de 
«qemu-base»
advertencia: no se pudo resolver «edk2-ovmf», una dependencia de 
«qemu-system-x86»
advertencia: no se pudo resolver «seabios», una dependencia de 
«qemu-system-x86»
advertencia: no se pudo resolver «qemu-system-x86», una dependencia de 
«qemu-desktop»
advertencia: no se pudo resolver «edk2-armvirt», una dependencia de 
«qemu-system-aarch64»
advertencia: no se pudo resolver «qemu-system-aarch64», una dependencia 
de «qemu-full»
advertencia: no se pudo resolver «edk2-ovmf», una dependencia de 
«qemu-system-x86»
advertencia: no se pudo resolver «seabios», una dependencia de 
«qemu-system-x86»
advertencia: no se pudo resolver «qemu-system-x86», una dependencia de 
«qemu-full»
:: Los siguientes paquetes no pueden ser actualizados debido a 
dependencias que no se pudieron resolver:

  qemu-base  qemu-desktop  qemu-full
Como puedo resolver esas dependencias y poder instalar QEMU. Toda 
información es bienvenida.

Gracias.

Re: Custom DNS for a VM

[Narcis Garcia]

El 30/5/22 a les 15:42, Peter Maydell ha escrit:

On Mon, 30 May 2022 at 13:56, Thomas Huth  wrote:


On 26/05/2022 12.01, Narcis Garcia wrote:

Is it possible to specify an explicit DNS IP for a VM in user mode networking?

For example, host uses 1.2.3.4 as nameserver at /etc/resolv.conf
And I want a user mode VM makes queries to a different nameserver.

Context: Qemu 5.2.0 in Debian 11 host. All command-line.


I've never tried, but -netdev user has a "dns" option, so have you tried
something like already:

   qemu-system-... -nic user,dns=8.8.8.8


I believe that that will set the IP address that the guest
VM sees as its DNS server (ie what it is told by the DHCP
server and the IP address that slirp responds to DNS requests
on), but it doesn't affect how the slirp backend actually
resolves requests made to slirp's stunt DNS server.

Looking quickly through the source it looks like
(a) if the guest is using the slirp DNS server then there's
no way to configure how slirp resolves those requests
(on Linux it will look for a nameserver IP in resolv.conf,
and ask that one)
(b) if you configure your guest to ignore what the slirp
DHCP server tells it to use for DNS, then doing DNS to any
DNS server you like will probably work (at least, as well as
any other UDP or TCP outbound from the guest)
(c) it might be possible to get QEMU to simply not create
the slirp DNS server, but I'm not sure what the syntax
for that is; and in any case you would need to tell the
guest what DNS server to actually use somehow

thanks
-- PMM



Thank you Peter. Documentation is according all you've said.
I already knew that guest can configure it's own networking setup, but 
I'm asking for customizing slirp DNS for Qemu instance (to specify the 
DNS backend for Qemu), because I need complete DHCP service from Qemu to 
guest, and I need that host does not use same DNS as guests.

Custom DNS for a VM

[Narcis Garcia]

Is it possible to specify an explicit DNS IP for a VM in user mode 
networking?


For example, host uses 1.2.3.4 as nameserver at /etc/resolv.conf
And I want a user mode VM makes queries to a different nameserver.

Context: Qemu 5.2.0 in Debian 11 host. All command-line.

Thank you

--
Narcis Garcia

Re: hello

[Narcis Garcia]

Please, detail result of this:

ls -l /var/lib/libvirt/images/-win10.qcow2

And also command VM launch command line and which user account is launching.


Narcis Garcia

__
I'm using this dedicated address because personal addresses aren't 
masked enough at this mail public archive. Public archive administrator 
should fix this against automated addresses collectors.

El 19/4/22 a les 22:56, Canpe ha escrit:

Hello Sirs,
please help me,
I can't boot the virtual machine.
I get this error:

error running libguestfs device: /var/lib/libvirt/images/-win10.qcow2 
Permission Denied


Thanks for the help

--
*/Carlos Nogales Peñafiel/*

Physical USB port addressing

[Narcis Garcia]

Some versions ago I could specify a host plugged device with this:
-usbdevice host:2001:3c17
but now I don't find a syntax that works for me (I also wish to ignore 
which physical port is device connected to):


$ lsusb
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 034: ID 2001:3c17 D-Link Corp. DWA-123 Wireless N 150 
Adapter(rev.A1) [Ralink RT3370]

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

$ qemu-system-x86_64 --version
QEMU emulator version 5.2.0 (Debian 1:5.2+dfsg-11+deb11u1)
Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers
$ qemu-system-x86_64 (...) -device usb-host,vendorid=2001,productid=3c17
qemu-system-x86_64: -device usb-host,vendorid=2001,productid=3c17: No 
'usb-bus' bus found for device 'usb-host'


$ qemu-system-x86_64 (...) -device 
usb-host,bus=usb-bus.1,vendorid=2001,productid=3c17
qemu-system-x86_64: -device 
usb-host,bus=usb-bus.1,vendorid=2001,productid=3c17: Bus 'usb-bus.1' not 
found


--
Narcis Garcia

Re: list only particular type of device

[Narcis Garcia]

$ qemu-system-x86_64 -device help | sed -ne '/^Network devices:/,//p' | 
sed -e '/^$/q'


Narcis Garcia

El 14/1/22 a les 10:40, Ahmad Ismail ha escrit:


The following command give a list of all the devices.

|% qemu-system-x86_64 -device help |

I only want the list of Network devices.

How can I get that?

Re: Does anybody have anecdotal experience of running 3 OSes (Free/Net/OpenBSD) and share data between them?

[Narcis Garcia]

I use this parameter from host:
-netdev user,id=net0,smb=/path/to/shared

and I connect guests by using Samba too.
\\10.0.2.4\qemu

Documentation:
https://wiki.qemu.org/Documentation/Networking

HowTo:
https://how-to.fandom.com/wiki/Howto_share_data_between_host_and_guest_OS_on_Qemu_with_Samba


Narcis Garcia

El 7/12/21 a les 9:59, Ottavio Caruso via ha escrit:
I run three instances of qemu (FreeBSD, NetBSD OpenBSD). Host is Linux 
Mint. In real life, it would be very hard to share partitions among them 
(apart from probably using good old fashioned fat-32).


I wonder if there is a way to share a qemu drive between them while I am 
actually running them at the same time. I am resigned to the idea that 
it's not possible but if anybody has any experiences/ideas, please share.

Re: Windows 9x - which graphic?

[Narcis Garcia]

Thanks.
Thank you for detailed report.


Narcis Garcia

El 3/12/21 a les 16:44, Maxim Levitsky ha escrit:

On Mon, 2021-06-07 at 18:15 +, Philipp Ammann wrote:

Am 07.06.21 um 16:27 schrieb Simon Becherer:

I tried minport vbe driver
(https://web.archive.org/web/20191129030225/https://bearwindows.zcm.com.au/vbe9x.htm#2)
with cirrus/vga/vmga card
and cirrus driver with cirrus card - but without sucess.
Both 95 and 98 hangs during shutting down :(

Any hints?


Cirrus should work fine with the stock drivers included in Windows.
Personally I'm using vmware with the official VMware driver. You can
extract the driver for Win9x from preWin2k.iso shipped with VMware.

Bonus: set vmport=on (may be default) an install the vmmouse driver from
said ISO, and try vmxnet3 if you need networking.



I have a win98 VM with qemu/kvm and  I play with it once a while,
because win98 was my first and last windows I used as a primary OS before
I discovered and switched to Linux.

Many will disagree with me but I still think that win98 was the last windows 
version
that didn't suck at least from user perspective.
Even despite the crashes/etc.
  
Here are few tips I know of running win98 on KVM/Qemu:
  
* Cirrus works (and it was my GPU back when I used win98 on real hardware),

   and is the most accurate, but is *slow* and very resolution limited.

   (I can't understand how I could use 800x600 for so many years, and then I 
remember I finally updated to 1024x768,
   that was awesome and then when I switched to 1280x1024, it felt like I have 
infinite space.
   These days I use 41 inch 4K monitor for my work, and I'll say it is about 
the amount of space I would like to have.
   
   For the win98 VM I use a standard VGA and found a universal VGA driver for it.


   I think I use the one from https://bearwindows.zcm.com.au/vbe9x.htm.
  
   The downsides of VGA driver I think are that if you attempt to open DOS prompt,

the screen fills with garbage, I think that DOS gets direct access to VGA 
registers or something,
and messes something up. It does work on cirrus though.
  
* That hang on shutdown I have seen too. Seems if you open a full screen DOS window once,

then it works (full screen window doesn't garbage the screen).
I setup a dummy PIF file in the autostart folder that does that for me.
   It also smells like some bug in Qemu VGA implementaiton.
  
* KVM also used to make windows hang on boot when its logo is shown, but it got fixed some kernels ago,

   so logo=0 in msdos.sys is no longer needed to boot it.
  
  
* Mouse. If you use win98 SE, then you have support for USB, and qemu's tablet works and works very well.

   You do need to manually install driver for PnP BIOS though, but I guess you 
already did that.
  
  
* Storage: I enabled DMA on IDE controller, seemed to be disabled by default, and helped a lot with speed.
  
  
* Sound: the SB16 works, but causes the mouse to freeze while sound playing. It is also very inefficient,

   as it uses PIO.
  
   I use AC97 driver for which I found very old win95 drivers which seems to work (win98 drivers crash)

   It might be this driver: https://archive.org/details/ac97-win95
  
  
* Usage on any AMD processor (or at least Ryzen):
  
   Sadly win98 contains a TLB flush bug, such as it doesn't flush TLB after it modifies a page table entry,

   with invtlb.
   Ryzen's TLB is more speculative that Intel's and it just makes the guest 
show error messages, all the time,
   and be mostly unusable, while in Intel's cpus for which it was developed, it seems to 
"work"
  
   What partially helps is to disable swap file in the guest but doesn't fully eliminate it of course.
  
   What is even funnier is that when you use KVM's shadow MMU (use kvm_amd kernel module with npt=0), the bug

   is still present because well KVM's shadow MMU also speculates.
   I do  have a patch which I use locally sometimes to make it strict and then 
win98 works relatively fine.
   (I still see some crashes and hangs once in a while, but they might be even 
because the OS itself isn't that stable).
  
   To use the attached patch you need to add 'strict_mmu=1' option to the kvm module (note, not kvm_amd), and load kvm_amd module

   with npt=0.
   Of course the sad part is that in this configuration you can't really run 
any other VMs, as they are just too slow,
   so I have to reload kvm kernel modules when I like to play with win98 VM.

   Also on Ryzen 1, there was something related to VME extension, but I think 
that AMD fixed it.


No luck so far with VFIO. I have a very old nvidia card (7600GS I think) and 
once I was able to pass it through to winxp VM on KVM,
and recently I was able to make it at least show something on screen with a 
eGPU box, but alas I think that the card died.
I don't think that this card supports win98 though. Since I still have that 
eGPU box, I might as well one day buy an older card
and try to pass it through.

  
And last thing,

Re: qemu 6.1.0 - i386 <= 2GB?

[Narcis Garcia]

El 29/11/21 a les 13:59, Frans de Boer ha escrit:

On 29/11/2021 10:13, Frans de Boer wrote:

On 29/11/2021 09:36, Narcis Garcia wrote:

El 29/11/21 a les 9:33, Frans de Boer ha escrit:

On 29/11/2021 08:46, Narcis Garcia wrote:

El 28/11/21 a les 19:42, Frans de Boer ha escrit:

On 24/11/2021 09:42, Narcis Garcia wrote:

El 23/11/21 a les 14:33, Frans de Boer ha escrit:

On 23/11/2021 11:44, Narcis Garcia wrote:

El 23/11/21 a les 10:03, Frans de Boer ha escrit:

On 23/11/2021 09:27, Narcis Garcia wrote:
Some 32-bit system can't handle more than 512 MiB of RAM, and 
some 32-bit systems can handle up to 64 GiB.


This is not related to memory assigned by Qemu to VE.


Narcis Garcia

El 22/11/21 a les 18:38, Frans de Boer ha escrit:

LS,

OK, 32-bit systems can't handle more than 4GB memory. So, I 
specify '-m 4096' and still get only 2GB. Is this (very) old 
bug still not resolved or is it a feature now?


Regards, Frans.
In theory an 32-bit processor can handle up-to 4GB of physical 
memory. However, due to limitations of some chip sets, the 
maximum amount of memory was often 512 MB or 1 GB. At that 
time the chip sets where lagging behind the processor 
capabilities.
With newer chip sets it became practically possible to address 
4 GB and when using PAE, even beyond that. Although in case of 
the latter, the address space for a single process was always 
limited to 4 GB.


So, whatever way you see it, the 2 GB limit imposed by QEMU 
seems rather arbitrary.


--- Frans.



Before talking about 64 GiB limit, I just tried 
ubuntu-mate-18.04.1-desktop-i386 in a Qemu 5.2.0 VM

50 GiB assigned and guest OS detects and uses it.


Then, what type of CPU did you specify?



I've tried now with these four modes:
qemu-system-x86_64 -m 51200 -cpu host [intel core i5]
qemu-system-x86_64 -m 51200 -cpu pentium2
qemu-system-i386 -m 51200 -cpu host
qemu-system-i386 -m 51200 -cpu pentium2
qemu-system-i386 -m 51200 -cpu kvm32

each of them detect & use 50GiB of RAM.
Other parameters of interest:
-vga qxl -display gtk -enable-kvm -boot d -drive 
file=ubuntu-mate-18.04.1-desktop-i386.iso,media=cdrom,index=0


* If I try with booting 64-bit OS (ubuntu-18.04-desktop-amd64) 
then I get Linux message "This kernel requires an x86-64 CPU, but 
only detected an i686 CPU." and it does not boot.
* If I try with "-cpu pentium" then I get Linux message "This 
kernel requires the following features not present on the CPU: 
pae cmov" and it does not boot.


ARE YOU SURE you're using a modern operating system?



Okay, I needed some time before I could continue.

I am building my own version of a linux system, but use OpenSuse 
TW (64-bit) as base. Updated almost every second day.
Now, when I either use ´-cpu pentium´ or ´-cpu kvm32´, I never can 
allocate more than 2 GB, no matter the -m size.
I do see that virtual memory is being increased, but the available 
memory for allocation is never more than 2GB.


So, yes the requested memory is allocated - albeit virtual -, but 
the excess above 2GB is never used.


--- Frans.



Are you sure you're using Linux [64-bit] kernel?
If not (32-bit), sure you're using PAE enabled Linux kernel.


Yes, I am sure that my system is using a 64-bit version of Tumbleweed.
Of course, the client in the VM is 32-bit.
A 64-bit client (windows/linux) has no problem.

I will download another 32-bit iso and check if that makes a 
difference.


--- Frans.



Please, copy here the complete syntax of your VM launch, and try with 
a guest like the one I've tried with PAE support (ubuntu 18.04 i386)
I just changed the '-machine type=q35,accel=kvm' into '-machine 
type=pc' and now I have 3GB available. Probably any PAE setting in the 
kernel is not set yet.


Strange, since q35 systems should be able to address upto at least 8GB 
and support upto 36-bit address space using PAE.


It seems that the culprit is the machine setting in combination with 
not using PAE. I check this further today.


-- Frans

PAE was indeed not enabled because high memory was still on 4GB, hence 
the default kernel limit of 3GB.
Now, the specified amount of memory is allocated and even with -machine 
type=q35, I can allocate almost 3GB. I can not allocate more memory for 
a single process due to the 3GB/1GB limit as imposed by the kernel.


--- Frans.



A "solution" for your 32-bit guest is to use PAE.
In case of doubt, test other modern distros for guest.

Re: qemu 6.1.0 - i386 <= 2GB?

[Narcis Garcia]

El 29/11/21 a les 9:33, Frans de Boer ha escrit:

On 29/11/2021 08:46, Narcis Garcia wrote:

El 28/11/21 a les 19:42, Frans de Boer ha escrit:

On 24/11/2021 09:42, Narcis Garcia wrote:

El 23/11/21 a les 14:33, Frans de Boer ha escrit:

On 23/11/2021 11:44, Narcis Garcia wrote:

El 23/11/21 a les 10:03, Frans de Boer ha escrit:

On 23/11/2021 09:27, Narcis Garcia wrote:
Some 32-bit system can't handle more than 512 MiB of RAM, and 
some 32-bit systems can handle up to 64 GiB.


This is not related to memory assigned by Qemu to VE.


Narcis Garcia

El 22/11/21 a les 18:38, Frans de Boer ha escrit:

LS,

OK, 32-bit systems can't handle more than 4GB memory. So, I 
specify '-m 4096' and still get only 2GB. Is this (very) old 
bug still not resolved or is it a feature now?


Regards, Frans.
In theory an 32-bit processor can handle up-to 4GB of physical 
memory. However, due to limitations of some chip sets, the 
maximum amount of memory was often 512 MB or 1 GB. At that time 
the chip sets where lagging behind the processor capabilities.
With newer chip sets it became practically possible to address 4 
GB and when using PAE, even beyond that. Although in case of the 
latter, the address space for a single process was always limited 
to 4 GB.


So, whatever way you see it, the 2 GB limit imposed by QEMU seems 
rather arbitrary.


--- Frans.



Before talking about 64 GiB limit, I just tried 
ubuntu-mate-18.04.1-desktop-i386 in a Qemu 5.2.0 VM

50 GiB assigned and guest OS detects and uses it.


Then, what type of CPU did you specify?



I've tried now with these four modes:
qemu-system-x86_64 -m 51200 -cpu host [intel core i5]
qemu-system-x86_64 -m 51200 -cpu pentium2
qemu-system-i386 -m 51200 -cpu host
qemu-system-i386 -m 51200 -cpu pentium2
qemu-system-i386 -m 51200 -cpu kvm32

each of them detect & use 50GiB of RAM.
Other parameters of interest:
-vga qxl -display gtk -enable-kvm -boot d -drive 
file=ubuntu-mate-18.04.1-desktop-i386.iso,media=cdrom,index=0


* If I try with booting 64-bit OS (ubuntu-18.04-desktop-amd64) then 
I get Linux message "This kernel requires an x86-64 CPU, but only 
detected an i686 CPU." and it does not boot.
* If I try with "-cpu pentium" then I get Linux message "This kernel 
requires the following features not present on the CPU: pae cmov" 
and it does not boot.


ARE YOU SURE you're using a modern operating system?



Okay, I needed some time before I could continue.

I am building my own version of a linux system, but use OpenSuse TW 
(64-bit) as base. Updated almost every second day.
Now, when I either use ´-cpu pentium´ or ´-cpu kvm32´, I never can 
allocate more than 2 GB, no matter the -m size.
I do see that virtual memory is being increased, but the available 
memory for allocation is never more than 2GB.


So, yes the requested memory is allocated - albeit virtual -, but the 
excess above 2GB is never used.


--- Frans.



Are you sure you're using Linux [64-bit] kernel?
If not (32-bit), sure you're using PAE enabled Linux kernel.


Yes, I am sure that my system is using a 64-bit version of Tumbleweed.
Of course, the client in the VM is 32-bit.
A 64-bit client (windows/linux) has no problem.

I will download another 32-bit iso and check if that makes a difference.

--- Frans.



Please, copy here the complete syntax of your VM launch, and try with a 
guest like the one I've tried with PAE support (ubuntu 18.04 i386)

Re: qemu 6.1.0 - i386 <= 2GB?

[Narcis Garcia]

El 28/11/21 a les 19:42, Frans de Boer ha escrit:

On 24/11/2021 09:42, Narcis Garcia wrote:

El 23/11/21 a les 14:33, Frans de Boer ha escrit:

On 23/11/2021 11:44, Narcis Garcia wrote:

El 23/11/21 a les 10:03, Frans de Boer ha escrit:

On 23/11/2021 09:27, Narcis Garcia wrote:
Some 32-bit system can't handle more than 512 MiB of RAM, and some 
32-bit systems can handle up to 64 GiB.


This is not related to memory assigned by Qemu to VE.


Narcis Garcia

El 22/11/21 a les 18:38, Frans de Boer ha escrit:

LS,

OK, 32-bit systems can't handle more than 4GB memory. So, I 
specify '-m 4096' and still get only 2GB. Is this (very) old bug 
still not resolved or is it a feature now?


Regards, Frans.
In theory an 32-bit processor can handle up-to 4GB of physical 
memory. However, due to limitations of some chip sets, the maximum 
amount of memory was often 512 MB or 1 GB. At that time the chip 
sets where lagging behind the processor capabilities.
With newer chip sets it became practically possible to address 4 GB 
and when using PAE, even beyond that. Although in case of the 
latter, the address space for a single process was always limited 
to 4 GB.


So, whatever way you see it, the 2 GB limit imposed by QEMU seems 
rather arbitrary.


--- Frans.



Before talking about 64 GiB limit, I just tried 
ubuntu-mate-18.04.1-desktop-i386 in a Qemu 5.2.0 VM

50 GiB assigned and guest OS detects and uses it.


Then, what type of CPU did you specify?



I've tried now with these four modes:
qemu-system-x86_64 -m 51200 -cpu host [intel core i5]
qemu-system-x86_64 -m 51200 -cpu pentium2
qemu-system-i386 -m 51200 -cpu host
qemu-system-i386 -m 51200 -cpu pentium2
qemu-system-i386 -m 51200 -cpu kvm32

each of them detect & use 50GiB of RAM.
Other parameters of interest:
-vga qxl -display gtk -enable-kvm -boot d -drive 
file=ubuntu-mate-18.04.1-desktop-i386.iso,media=cdrom,index=0


* If I try with booting 64-bit OS (ubuntu-18.04-desktop-amd64) then I 
get Linux message "This kernel requires an x86-64 CPU, but only 
detected an i686 CPU." and it does not boot.
* If I try with "-cpu pentium" then I get Linux message "This kernel 
requires the following features not present on the CPU: pae cmov" and 
it does not boot.


ARE YOU SURE you're using a modern operating system?



Okay, I needed some time before I could continue.

I am building my own version of a linux system, but use OpenSuse TW 
(64-bit) as base. Updated almost every second day.
Now, when I either use ´-cpu pentium´ or ´-cpu kvm32´, I never can 
allocate more than 2 GB, no matter the -m size.
I do see that virtual memory is being increased, but the available 
memory for allocation is never more than 2GB.


So, yes the requested memory is allocated - albeit virtual -, but the 
excess above 2GB is never used.


--- Frans.



Are you sure you're using Linux [64-bit] kernel?
If not (32-bit), sure you're using PAE enabled Linux kernel.

Re: qemu emulator app version for smartphone android OS

[Narcis Garcia]

https://www.qemu.org/contribute/


El 25/11/21 a les 14:33, Виртуалины MER user MER ha escrit:
> port qemu for android OS 

-- 
Narcis Garcia

Re: qemu 6.1.0 - i386 <= 2GB?

[Narcis Garcia]

El 23/11/21 a les 14:33, Frans de Boer ha escrit:

On 23/11/2021 11:44, Narcis Garcia wrote:

El 23/11/21 a les 10:03, Frans de Boer ha escrit:

On 23/11/2021 09:27, Narcis Garcia wrote:
Some 32-bit system can't handle more than 512 MiB of RAM, and some 
32-bit systems can handle up to 64 GiB.


This is not related to memory assigned by Qemu to VE.


Narcis Garcia

El 22/11/21 a les 18:38, Frans de Boer ha escrit:

LS,

OK, 32-bit systems can't handle more than 4GB memory. So, I specify 
'-m 4096' and still get only 2GB. Is this (very) old bug still not 
resolved or is it a feature now?


Regards, Frans.
In theory an 32-bit processor can handle up-to 4GB of physical 
memory. However, due to limitations of some chip sets, the maximum 
amount of memory was often 512 MB or 1 GB. At that time the chip sets 
where lagging behind the processor capabilities.
With newer chip sets it became practically possible to address 4 GB 
and when using PAE, even beyond that. Although in case of the latter, 
the address space for a single process was always limited to 4 GB.


So, whatever way you see it, the 2 GB limit imposed by QEMU seems 
rather arbitrary.


--- Frans.



Before talking about 64 GiB limit, I just tried 
ubuntu-mate-18.04.1-desktop-i386 in a Qemu 5.2.0 VM

50 GiB assigned and guest OS detects and uses it.


Then, what type of CPU did you specify?



I've tried now with these four modes:
qemu-system-x86_64 -m 51200 -cpu host [intel core i5]
qemu-system-x86_64 -m 51200 -cpu pentium2
qemu-system-i386 -m 51200 -cpu host
qemu-system-i386 -m 51200 -cpu pentium2
qemu-system-i386 -m 51200 -cpu kvm32

each of them detect & use 50GiB of RAM.
Other parameters of interest:
-vga qxl -display gtk -enable-kvm -boot d -drive 
file=ubuntu-mate-18.04.1-desktop-i386.iso,media=cdrom,index=0


* If I try with booting 64-bit OS (ubuntu-18.04-desktop-amd64) then I 
get Linux message "This kernel requires an x86-64 CPU, but only detected 
an i686 CPU." and it does not boot.
* If I try with "-cpu pentium" then I get Linux message "This kernel 
requires the following features not present on the CPU: pae cmov" and it 
does not boot.


ARE YOU SURE you're using a modern operating system?

Re: qemu 6.1.0 - i386 <= 2GB?

[Narcis Garcia]

El 23/11/21 a les 10:03, Frans de Boer ha escrit:

On 23/11/2021 09:27, Narcis Garcia wrote:
Some 32-bit system can't handle more than 512 MiB of RAM, and some 
32-bit systems can handle up to 64 GiB.


This is not related to memory assigned by Qemu to VE.


Narcis Garcia

El 22/11/21 a les 18:38, Frans de Boer ha escrit:

LS,

OK, 32-bit systems can't handle more than 4GB memory. So, I specify 
'-m 4096' and still get only 2GB. Is this (very) old bug still not 
resolved or is it a feature now?


Regards, Frans.
In theory an 32-bit processor can handle up-to 4GB of physical memory. 
However, due to limitations of some chip sets, the maximum amount of 
memory was often 512 MB or 1 GB. At that time the chip sets where 
lagging behind the processor capabilities.
With newer chip sets it became practically possible to address 4 GB and 
when using PAE, even beyond that. Although in case of the latter, the 
address space for a single process was always limited to 4 GB.


So, whatever way you see it, the 2 GB limit imposed by QEMU seems rather 
arbitrary.


--- Frans.



Before talking about 64 GiB limit, I just tried 
ubuntu-mate-18.04.1-desktop-i386 in a Qemu 5.2.0 VM

50 GiB assigned and guest OS detects and uses it.

Re: qemu 6.1.0 - i386 <= 2GB?

[Narcis Garcia]

Some 32-bit system can't handle more than 512 MiB of RAM, and some 
32-bit systems can handle up to 64 GiB.


This is not related to memory assigned by Qemu to VE.


Narcis Garcia

El 22/11/21 a les 18:38, Frans de Boer ha escrit:

LS,

OK, 32-bit systems can't handle more than 4GB memory. So, I specify '-m 
4096' and still get only 2GB. Is this (very) old bug still not resolved 
or is it a feature now?


Regards, Frans.

--
A: Yes, just like thatA: Ja, net zo
Q: Oh, Just like reading a book backwards Q: Oh, net als een boek 
achterstevoren lezen
A: Because it upsets the natural flow of a story  A: Omdat het de natuurlijke 
gang uit het verhaal haalt
Q: Why is top-posting annoying?   Q: Waarom is Top-posting zo 
irritant?

Re: wiki.qemu.org down?

[Narcis Garcia]

Also offline:

git.qemu.org
www.git.qemu.org

El 22/9/21 a les 6:22, Eldon Stegall ha escrit:
> Hi all,
> It would seem from here that wiki.qemu.org is down. Apologies if this is
> the wrong venue to mention, has already been discussed, etc.  Is there
> something I can do to assist with this condition? Would a contribution
> of resources of any type here be helpful?
> 
> Thanks!
> Eldon
> 

-- 
Narcis Garcia

Re: Issue with qemu networking

[Narcis Garcia]

El 15/9/21 a les 22:13, Steve Litt ha escrit:
> Sukreet pal said on Tue, 14 Sep 2021 10:30:31 +0200
> 
>> Dear qemu developers,
>>
>> I am currently new to qemu. Currently , I have a windows host in which
>> I have a Linux VM and inside the Linux VM I have my qemu armv7
>> vexpress-a9 board virtualized.
>>
>> I want to connect to the internet from my vexpress-a9 board (use wget
>> and ping). Currently I am able to ping the VM host but not directly to
>> the internet. My VM works on a NAT network.
>>
>> I went through almost all the tutorials , created a tap and bridge
>> connection, but still it does not work.
>>
>> Any suggestions?
> 
> I documented how to make a VM guest a full part of your network,
> complete with ping. See the following:
> 
> http://www.troubleshooters.com/linux/qemu/nobs.htm
> 
> SteveT
> 
> Steve Litt 
> Spring 2021 featured book: Troubleshooting Techniques of the Successful
> Technologist http://www.troubleshooters.com/techniques
> 

Thank you!

-- 
Narcis Garcia

Re: Windows 11 clipboard issue

[Narcis Garcia]

Clipboard can be used, for example, from one application to another:
You can write a text in Notepad, select it, and press [Control]+[C]
After this, you can open Wordpad and press [Control]+[V]

This will make data be in clipboard and prove when pasting in another
Windows application.


Narcis Garcia

__
I'm using this dedicated address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
El 1/7/21 a les 22:08, ToddAndMargo ha escrit:
> Hi All,
> 
> Fedora 34
> qemu-kvm-5.2.0-8.fc34.x86_64
> 
> How do I get the clipboard to work with Windows 11?
> 
> Many thanks,
> -T
> 

Re: User mode networking with slirp on MacOs, setting host DNS server?

[Narcis Garcia]

Syntax at /etc/resolv.conf text file is:
nameserver {serverip}

If your dnsmasq is reachable at host's 127.0.0.1 then:
nameserver 127.0.0.1


Narcis Garcia

__
I'm using this dedicated address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
El 22/6/21 a les 9:51, Biff Eros ha escrit:
> I noticed this:
> https://github.com/qemu/libslirp/commit/5ac17660a76e321c37e6dca2e3c04d9d7d2b7ff4
> So maybe slirp doesn't do DNS in quite the way I expect on MacOs.
> 
> In any case I couldn't figure out how to make changes to slirp and compile 
> them
> into a new Qemu, I put a compile error into a file in the slirp
> directory and re-ran
> the top-level make and it didn't fail.  I was going to just change the
> /etc/resolv.conf
> string to /usr/local/etc/resolv.conf and put my alternate address in
> there but I haven't
> figured out how to do that even.
> 
> On Tue, Jun 22, 2021 at 6:27 AM Narcis Garcia  wrote:
>>
>> __
>> I'm using this dedicated address because personal addresses aren't
>> masked enough at this mail public archive. Public archive administrator
>> should fix this against automated addresses collectors.
>> El 22/6/21 a les 0:59, Biff Eros ha escrit:
>>> Looking at this bug report:
>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=625689
>>>
>>> There is this comment:
>>>
>>> m...@tls.msk.ru wrote:
>>>
>>>> No the limitation isn't documented (yet), and it will be difficult
>>>> to fix too, or maybe not worth a trouble really.  Two reasons.
>>>> First of all, user-mode networking is not suitable for anything
>>>> serious, you really want tap networking with bridges, which is
>>>> about 100 times faster and actually works (e.g. ICMP).  Second,
>>>> the implementation is rather simplistic - for DNS it merely
>>>> forwards (like a NAT box) packets from guest to a nameserver
>>>> from host /resolv.conf - only one nameserver, because you can't
>>>> NAT to TWO destinations at once.  So in order to fix that,
>>>> qemu has to become application-level proxy for DNS, instead
>>>> of a simple NAT "device".
>>>
>>> Unfortunately I'm on MacOs, and I don't want to be using resolv.conf.
>>> I want it to use a locally running dnsmasq instead.  Can anyone point
>>> me to which bit of source I need to change to hard-code this to
>>> 127.0.0.1, or is that out of the question?
>>>
>>
>> You should be able to point resolv.conf nameserver to your dnsmasq IP.
>>
>>
> 

Re: User mode networking with slirp on MacOs, setting host DNS server?

[Narcis Garcia]

__
I'm using this dedicated address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
El 22/6/21 a les 0:59, Biff Eros ha escrit:
> Looking at this bug report:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=625689
> 
> There is this comment:
> 
> m...@tls.msk.ru wrote:
> 
>> No the limitation isn't documented (yet), and it will be difficult
>> to fix too, or maybe not worth a trouble really.  Two reasons.
>> First of all, user-mode networking is not suitable for anything
>> serious, you really want tap networking with bridges, which is
>> about 100 times faster and actually works (e.g. ICMP).  Second,
>> the implementation is rather simplistic - for DNS it merely
>> forwards (like a NAT box) packets from guest to a nameserver
>> from host /resolv.conf - only one nameserver, because you can't
>> NAT to TWO destinations at once.  So in order to fix that,
>> qemu has to become application-level proxy for DNS, instead
>> of a simple NAT "device".
> 
> Unfortunately I'm on MacOs, and I don't want to be using resolv.conf.
> I want it to use a locally running dnsmasq instead.  Can anyone point
> me to which bit of source I need to change to hard-code this to
> 127.0.0.1, or is that out of the question?
> 

You should be able to point resolv.conf nameserver to your dnsmasq IP.

Re: Again, qemu changed virtual hardware

[Narcis Garcia]

Oh, I believed that -nodefaults option already prevented this!

How could i prevent qemu from virtual hardware changes on updates?


Narcis Garcia

__
I'm using this dedicated address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
El 20/6/21 a les 20:37, Simon Becherer ha escrit:
> Hi, i like to ask again here:
> 
> how did i fix the virtual hardware that quemu will after updates
> still send the guests the same hardware as before??
> 
> i updated today to 6.0.0-26.1 (opensusetumbleweed)
> 
> windows xp: lost the network controller, but has a identical new (e1000) 
> network controller
>found, so i have to set up it new.
> 
> windows 10: a propetary software lost the licence because of the update of 
> the linux qemu host.
> i have to order new key.
> 
> 
> how could i prevent qemu from doing that AND hold my system up to date
> -> not updating qemu is not a solution.
> 
> start line from win10 (libvirt)
> 
> /usr/bin/qemu-system-x86_64 -name guest=win_10_profirst,debug-threads=on -S 
> -object 
> {"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain-1-win_10_profirst/master-key.aes"}
> -machine 
> pc-q35-4.2,accel=kvm,usb=off,vmport=off,dump-guest-core=off,memory-backend=pc.ram
>  -cpu
> EPYC-IBPB,x2apic=on,tsc-deadline=on,hypervisor=on,tsc-adjust=on,arch-capabilities=on,xsaves=on,cmp-legacy=on,perfctr-core=on,clzero=on,xsaveerptr=on,virt-ssbd=on,npt=on,nrip-save=on,svme-addr-chk=on,rdctl-no=on,skip-l1dfl-vmentry=on,mds-no=on,pschange-mc-no=on,monitor=off,hv-time,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff
> -m 4096 -object 
> {"qom-type":"memory-backend-ram","id":"pc.ram","size":4294967296} -overcommit 
> mem-lock=off -smp 2,sockets=2,cores=1,threads=1 -uuid 
> 539ae174-da2a-4e80-8ee6-d2e86b843304 -no-user-config -nodefaults
> -chardev socket,id=charmonitor,fd=33,server=on,wait=off -mon 
> chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew 
> -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global
> ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1 -boot strict=on -device 
> pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2
>  -device
> pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 -device 
> pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 -device
> pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 -device 
> pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4 -device 
> qemu-xhci,p2=15,p3=15,id=usb,bus=pci.2,addr=0x0 -device
> virtio-serial-pci,id=virtio-serial0,bus=pci.3,addr=0x0 -blockdev 
> {"driver":"file","filename":"/home/simon/kvm/images/win_10_profirst.qcow2","node-name":"libvirt-2-storage","auto-read-only":true,"discard":"unmap"}
> -blockdev 
> {"node-name":"libvirt-2-format","read-only":false,"driver":"qcow2","file":"libvirt-2-storage","backing":null}
>  -device ide-hd,bus=ide.0,drive=libvirt-2-format,id=sata0-0-0,bootindex=1 
> -device
> ide-cd,bus=ide.1,id=sata0-0-1 -netdev tap,fd=35,id=hostnet0 -device 
> e1000e,netdev=hostnet0,id=net0,mac=52:54:00:8c:08:86,bus=pci.1,addr=0x0 
> -chardev pty,id=charserial0 -device
> isa-serial,chardev=charserial0,id=serial0 -chardev 
> spicevmc,id=charchannel0,name=vdagent -device 
> virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0
>  -device
> usb-tablet,id=input0,bus=usb.0,port=1 -audiodev id=audio1,driver=spice -spice 
> port=5900,addr=127.0.0.1,disable-ticketing=on,image-compression=off,seamless-migration=on
>  -device
> qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pcie.0,addr=0x1
>  -device ich9-intel-hda,id=sound0,bus=pcie.0,addr=0x1b -device
> hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0,audiodev=audio1 -chardev 
> spicevmc,id=charredir0,name=usbredir -device 
> usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2 -chardev
> spicevmc,id=charredir1,name=usbredir -device 
> usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 -device 
> virtio-balloon-pci,id=balloon0,bus=pci.4,addr=0x0 -sandbox
> on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg 
> timestamp=on
> 
> 
> simoN
> 

Re: Switching to the GitLab bug tracker

[Narcis Garcia]

Sorry; I didn't realize Launchpad is downloadable software to deploy it
as a self-managed platform. I talked without the necessary thinking time.


Narcis Garcia

El 4/5/21 a les 15:54, Peter Maydell ha escrit:
> On Tue, 4 May 2021 at 12:04, Narcis Garcia  wrote:
>>
>> One of the good news: Going to FOSS resources.
> 
> Well, going from one FOSS resource to another -- Launchpad
> is open source too...
> 
> -- PMM
> 

Re: Switching to the GitLab bug tracker

[Narcis Garcia]

One of the good news: Going to FOSS resources.


El 3/5/21 a les 13:16, Thomas Huth ha escrit:
> 
> Hi everybody!
> 
> As you might have already noticed by some other mails on the qemu-devel
> mailing list, we are in progress of switching our bug tracking tool from
> Launchpad to Gitlab. The new tracker can now be found here:
> 
> https://gitlab.com/qemu-project/qemu/-/issues
> 
> Please note that this has some implications:
> 
> 1) We likely won't have the possibility anymore to automatically send
> e-mail notifications for new bugs to the qemu-devel mailing list. If you
> want to get informed about new bugs, please use the notification
> mechanism from Gitlab instead. That means, log into your gitlab account,
> browse to
> 
> https://gitlab.com/qemu-project/qemu
> 
> and click on the bell icon at the top of the page to manage your
> notifications, e.g. enable notifications for "New issues" there.
> 
> 2) It should be possible for everybody who has a Gitlab account to open
> new bugs. If you are a maintainer of one of the QEMU subsystems, you
> might want to help with changing certain aspects of bug tickets, too,
> e.g. add labels or assign a ticket to you or somebody else. In that case
> you need to be listed as a "Reporter" in the QEMU project, so please
> then get in touch with one of the "Owners" of the project (see
> https://gitlab.com/qemu-project/qemu/-/project_members ) and ask them to
> add you as a "Reporter".
> 
> 3) Gitlab has a nice mechanism for closing bugs automatically once the
> fix gets merged to the master branch. To use this feature, please mark
> your commit messages with a "Resolves: " line. See:
> 
> https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically
> 
> 
> 4) I'm in progress of automatically migrating the open bug tickets from
> Launchpad to the Gitlab tracker. If you're interested, please keep an
> eye on those tickets and tell me if you spot any oddity there - the
> script that I'm using for the migration might not be perfect yet.
> 
> Thomas
> 
> 

-- 


__
I'm using this express-made address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.

Re: how can I attach a disk to a virtual machine?

[Narcis Garcia]

On most cases, it's better like a physical block device (/dev/sda)
instead of a single partition.



Narcis Garcia

__
I'm using this dedicated address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
El 13/4/21 a les 14:02, c...@etri.re.kr ha escrit:
> Hello, qemu experts,
> 
>  
> 
> What is the method of attaching disk image to a virtual machine? I want
> to attach disk image to the virtual machine,
> 
> and it would be best if I can make it seem like a disk partition
> /dev/sda1, or like a disk(/dev/sda) with a couple of
> partitions(/dev/sda1, /dev/sda2,..)
> 
>  
> 
> I made disk image like this.
> 
> qemu-img create myimage.img 10G
> 
> and I ran qemu with this command.
> 
> qemu-system-aarch64 -M virt -cpu cortex-a72 -kernel
> ${LINUX_DIR}/arch/arm64/boot/Image -initrd initramfs.cpio.gz --append
> "root=/dev/ram init=/init nokaslr" -m 2048M -nographic -drive
> if=none,file=myimage.img,id=disk1 -device virtio-blk-device,drive=disk1
> 
>  
> 
> In the initrd image(before cpio’ed and compresed to initramfs.cpio.gz
> above), I made device files like this.
> 
> mkdir -p dev
> 
> sudo mknod dev/console c 5 1
> 
> sudo mknod dev/ram b 1 0
> 
>  
> 
> and the init script contains below lines.
> 
> #!/bin/sh
> 
> echo "### INIT SCRIPT ###"
> 
> mkdir /proc /sys /tmp
> 
> mount -t proc none /proc
> 
> mount -t sysfs none /sys
> 
> mount -t tmpfs none /tmp
> 
> echo -e "\nThis boot took $(cut -d' ' -f1 /proc/uptime) seconds\n"
> 
> exec /bin/sh
> 
>  
> 
> but after linux boots and in the bash shell, I don’t know how to use the
> disk1. I checked the disk image document, but it describes all the
> various types but not how to use it inside linux.
> 
> How can I use disk1 above? A point to a kind document will also be
> appreciated.
> 
> Thank you!
> 
> Chan Kim
> 
>  
> 

Re: Mailing list removal

[Narcis Garcia]

List-Unsubscribe:
https://lists.nongnu.org/mailman/options/qemu-discuss



El 17/3/21 a les 17:18, jay...@protonmail.com ha escrit:
> To whom it may concern,
> 
> Please remove my e-mail address from the mailing list and let me know
> once that has been completed.
> 
> Many thanks in advance,
> 
> Warm Regards
> 
> James
> 
> 
> 
> 
> 
> 
> Sent from ProtonMail mobile
> 
> 

Re: Connection of a qemu guest to the 'net.

[Narcis Garcia]

Usermode does not require bridge.

Example:
-device rtl8139,netdev=net0 -netdev user,id=net0


Narcis Garcia

El 16/3/21 a les 5:34, pe...@easthope.ca ha escrit:
> Hi,
> 
> Every mention of a network connection I've seen involves a bridge.  Is 
> a bridge necessary?  If so, why?  Why not route to the guest, analogous 
> to routing to a machine on a subnet connected by an Ethernet cable?
> 
> Thx, ... Peter E.
> 

Re: qemu change virtual hardware after update

[Narcis Garcia]

+1



Narcis Garcia

__
I'm using this dedicated address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
El 20/2/21 a les 17:41, Simon Becherer ha escrit:
> Hi,
> 
> i am new here on this list, so if this problem was discussed/solved
> somewhere else, please point me to it.
> 
> i use qemu (at the moment 5.2) with virt-manager on opensuse tumbleweed.
> 
> is there a way to prevent qemu from updating virtualized hardware inside
> the virtualization?
> 
> as example: sometimes when qemu is updated, the virtual machines OS
> (windows 10 or windows xp) find new "hardware"
> and at least in windows xp i have now a huge amount of broken
> (most is invisible inside system-control) hardware. (this machine
> runs since 2011)
> and of course the "fingerprint" of the system will change.
> 
> there is the parameter -machine pc-q35-4.2
> inside my command line. i was thinking this will stay always at same
> hardware. but this parameter is since 15.juni2020 (generation of the
> libvirt xml file) inside.
> but after an update of my system and of course with the system also
> qemu, in jan. 2021, some components
> (not only but also the networkadapter), inside qemu has changed.
> the networkadapter is also inside the config line: e1000e.
> but windows10 has found a new one (a new e1000e) and i have
> had to set for the new adapter my fixed ipv4 adres.
> 
> this results in my main problem:
> 
> i see this virtual-hardware-updates at least two times in the last 2 years.
> 
> and it brakes for me my installation of a proprietary software in win10 who 
> has
> a copy protection. i have then always to make a phone call to the
> software company and ask for new key-number.
> that's annoying. (i own a permanent license for one computer but the computer
> should not change the hardware) - the host did not change, but qemu (or 
> libvirt)
> (but libvirt has always the same xml file, so i think its qemu itself) changed
> the virtual hardware.
> and maybe sometimes in future the company will tell me to buy support for the 
> software.
> because the license did not include support or phone calls for new
> license numbers.
> 
> stay on same hardware do not update software "or anything", that is one of 
> the reasons i like to use a
> virtualized environment. and of course to be portable with the emulation to 
> move on at host side
> the hard and software.
> 
> so what must i do to tell qemu "stay ALWAYS on hardware qemu version X.y 
> never change it."
> 
> simoN
> 

Re: Windows XP SP3

[Narcis Garcia via]

Here is working fine with Qemu 4.2.1
I don't know newer versions.


Narcis Garcia

__
I'm using this dedicated address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
El 30/12/20 a les 14:40, kacper6...@amorki.pl ha escrit:
> What is the latest quemu compatible with Windows XP SP3?
> 

Re: Clients cannot access the Internet after an OS upgrade.

[Narcis Garcia via]

It's important you provide command line of your Qemu calls.


Narcis Garcia
El 7/11/20 a les 5:38, Cliff Pratt ha escrit:
> I'm posting this because it may help someone who ends up in the same
> situation as I did.
> 
> I run Ubuntu and before a recent upgrade, I was running 20.04. I had
> already installed Qemu and created a number of guests. I also had docker
> installed as a snap.
> 
> I upgraded Ubuntu from 20.04 to 20.10 and my guests stopped working!
> 
> After a LOT of digging around, I discovered that Ubuntu has switched to
> nftables from the legacy iptables portions of Netfilter. There are now
> two iptables versions - iptables-nft (which is aliased to iptables) and
> iptables-legacy.
> 
> For reasons which I do not understand, the snap docker version uses (or
> seems to use) the legacy version. It sets the policy of the FORWARD
> chain to DROP, and this causes the Qemu packets to be dropped.
> 
> The solution, for me, was to disable the docker snap for now.
> 
> There are obvious holes in the explanation above. Maybe someone with
> more knowledge of how these things interact with one another could fill
> in the holes, but the above may help someone.   
> 
> -- 
> My Amazon author page : https://amazon.com/author/cliffpratt
> <http://amazon.com/author/cliffpratt>
> My Facebook author page : https://www.facebook.com/cliffprattauthor
> My Search on Kobo : https://www.kobo.com/search?query=Cliff+Pratt
> 

Re: UEFI error message

[Narcis Garcia via]

Perhaps you are using another application that makes calls to Qemu.
That "Create virtual machine" button is provided by that GUI software
instead of Qemu/KVM.



Narcis Garcia
El 7/11/20 a les 1:21, jay...@protonmail.com ha escrit:
> Hi!
> 
> Please can someone help me? I'm new to Qemu and Linux operating systems.
> 
> I have QEMU/KVM installed on my Pinebook Pro, However when I click into,
> "Create Virtual machine" I see the following error message, "Warning:
> Failed to set up UEFI: Did not find any UEFI binary path for 'aarch 64'
> install options are limited."
> 
> Is there a way that I can fix this? And if so please provide me with a
> step by step guide.
> 
> Many thanks in advance, And I hope that you all have a great day/night 
> 
> Cheers
> 
> 
> Sent from ProtonMail mobile
> 
> 

Guest fstrim does not unmap, sometimes

[Narcis Garcia via]

Hello,

I've a host with Debian 10 and Qemu 3.1 to run a guest with Debian 10:

$ qemu-system-x86_64 -cpu host -m 57344 -display curses -enable-kvm
-device virtio-scsi -boot c -drive
file=/var/lib/qemu/MyGuest_sda.img,media=disk,discard=unmap,detect-zeroes=unmap,index=0,cache=unsafe
-smp cores=10,threads=2 -vga virtio

After guest installation and diverse operations, my "raw" disk image
(MyGuest_sda.img) has an apparent size of 10TiB and 84 GiB really allocated.

Guest filesystems are using only 3GiB; then I run there:
$ fstrim -a -v
/boot: 866.7 MiB (908754944 bytes) trimmed on /dev/sda2
/: 9.9 TiB (10903472549888 bytes) trimmed on /dev/sda3
$ sync
$ sudo /etc/cron.daily/fstrim
/boot: 0 B (0 bytes) trimmed on /dev/sda2
/: 0 B (0 bytes) trimmed on /dev/sda3
$ sync

but nothing changes on host.
If I allocate 100GiB in guest with dd command (writing zeroes), guest
sees 103GiB used and host sees 184GiB allocated. After removing that
temporary file, automatically that space is unmapped:
Guest 3GiB used, host 84GiB allocated.

How can I unmap that 81GiB of excess?

Thank you.

-- 

Narcis Garcia

Re: uninstalling

[Narcis Garcia via]

How is "Host services 64.exe" related to Qemu?



Narcis Garcia
El 10/9/20 a les 20:51, Liz C ha escrit:
> Hi.
>  I’ve never installed your app but I have it in my computer (I don’t
> know why). My antivirus says that Host services 64.exe is a troyan
> virus. I uninstalled it many times and deleted everything but it keeps
> showing after a few days. How can I deleted forever? I don’t have
> nothing against you but I don’t want this app. 
> Hope you can help me!
> Liz

Re: Display in qemu issue

[Narcis Garcia via]

Replace:
-display sdl
By:
-display gtk


Narcis Garcia
El 19/8/20 a les 23:23, Steven Walker ha escrit:
> I am using qemu 4.2-3 on linux mint 20. I am trying to set up a vm for
> freedos. When I had this setup on 32 bit, I was using an sdl
> display...but now it seems to go to a vnc server on 127.0.0.1:5900
> <http://127.0.0.1:5900> and then it runs the installation iso. Once
> Installed through the vnc it give me no access to either sdl or gtk.
> Does anyone know how I can fix this issue and run my display on sdl -
> like it did (and still does) through 32 bit?
> 
> Steve

Re: Authentication failure in VncAuth

[Narcis Garcia via]

Forget my question.
I had a confusion between absolute port call and relative port
specification for -vnc
(then a different Qemu instance was responding on that port)


Narcis Garcia
El 29/7/20 a les 9:58, Narcis Garcia via ha escrit:
> Is stdin deprecated to Qemu instance receives commands?
> 
> What more ways are there to send commands to Qemu/monitor ?
> 
> 
> 
> Narcis Garcia
> El 27/7/20 a les 10:19, Narcis Garcia via ha escrit:
>> I've been launching VMs with this syntax:
>> $ echo "  change vnc password \"1234\"" | qemu-system-x86_64 (...) -vnc
>> 0.0.0.0:5959,password -k es
>>
>> When server was running Qemu 2.8 on Debian 9, I could connect with a
>> vncviewer with no problem, prividing matching password.
>> I'm serving this now with Qemu 3.1.0 on Debian 10 and, for same VMs, VNC
>> connection is rejected with this message:
>> Authentication failed
>>
>> Tested from clients:
>> TigerVNC Viewer 64-bit v1.9.0
>> TightVNC Viewer version 1.3.9
>>
>> What am I doing wrong?
>>
> 

Re: Authentication failure in VncAuth

[Narcis Garcia via]

Is stdin deprecated to Qemu instance receives commands?

What more ways are there to send commands to Qemu/monitor ?



Narcis Garcia
El 27/7/20 a les 10:19, Narcis Garcia via ha escrit:
> I've been launching VMs with this syntax:
> $ echo "  change vnc password \"1234\"" | qemu-system-x86_64 (...) -vnc
> 0.0.0.0:5959,password -k es
> 
> When server was running Qemu 2.8 on Debian 9, I could connect with a
> vncviewer with no problem, prividing matching password.
> I'm serving this now with Qemu 3.1.0 on Debian 10 and, for same VMs, VNC
> connection is rejected with this message:
> Authentication failed
> 
> Tested from clients:
> TigerVNC Viewer 64-bit v1.9.0
> TightVNC Viewer version 1.3.9
> 
> What am I doing wrong?
> 

Re: Windows 10 host SLOW

[Narcis Garcia via]

-enable-kvm



Narcis Garcia
El 28/7/20 a les 2:34, Jerry Geis ha escrit:
> I am running Windwos 10 host and latest qemu.
> I have tried to run with and without the -accel whpx flags. 
> operation is the same SLOW. even though it ways windows acceleration
> enabled.
> 
> Is there another way to speed up the windows 10 hosts ?
> I am attempting a CentOS 8 client.
> 
> My command is simple:
> "C:\Program Files\qemu\qemu-system-x86_64.exe"     -drive
> file="centos8.x86_64.img,format=raw"     -vga std -smp 8 -m 8196
> -no-acpi   -accel whpx
> 
> Thanks.
> 
> Jerry

Authentication failure in VncAuth

[Narcis Garcia via]

I've been launching VMs with this syntax:
$ echo "  change vnc password \"1234\"" | qemu-system-x86_64 (...) -vnc
0.0.0.0:5959,password -k es

When server was running Qemu 2.8 on Debian 9, I could connect with a
vncviewer with no problem, prividing matching password.
I'm serving this now with Qemu 3.1.0 on Debian 10 and, for same VMs, VNC
connection is rejected with this message:
Authentication failed

Tested from clients:
TigerVNC Viewer 64-bit v1.9.0
TightVNC Viewer version 1.3.9

What am I doing wrong?

-- 

Narcis Garcia

Re: New to QEMU

[Narcis Garcia via]

Did you succeed by installing some other operating system?



Narcis Garcia
El 26/7/20 a les 22:26, Weiss, Howard ha escrit:
> I would like to run Windows 10 in a QEMU virtual machine on a Windows 10
> computer
> 
>  
> 
> I can successful start QEMU on Windows 10 and start the Windows 10
> installation in the virtual machine.  Thank you Jay Jay.
> 
>  
> 
> The installation stops because it want to know where to install Windows 10
> 
>  
> 
> Can I use Qimg to create a virtual Machine and point
> qemu-system-x86-64.exe to install Windows 10 into that virtual machine? 
> Which command option do I use to qemu-system-x86_64?
> 
>  
> 
> Is this correct?
> 
>  
> 
> Do I need to install Linux in the QEMU virtual machine before I can
> install Windows 10
> 
>  
> 
> What is recommended procedure
> 
>  
> 
> Thanks
> 
>  
> 
> Howard Weiss
> 

Re: How to add files to an existing img partition.

[Narcis Garcia via]

There doesn't exist "Windows XP" or "Windows 98" partitions.
Them can be formatted as FAT16, FAT32 or NTFS.

If yout target is Bochs, you should make the work with Bochs con your
computer too.


Narcis Garcia
El 28/6/20 a les 5:04, Dan Campbell ha escrit:
> Hi,
> 
> I'm using a virtual disc created in Qemu Manager.  It contains a Windows
> XP partition.  
> 
> I'm not able to add files or change anything with PowerISO.  If I open
> the c.img file with PowerISO and try to add a few files, PowerISO
> returns an error that it has to truncate dozens of folder names
> including C:\Windows.
> 
> Is there another tool I should be using to make changes to the partition
> like add files or install programs?
> 

Re: QEMU running in background

[Narcis Garcia via]

What operating system and version are you running there?



Narcis Garcia
El 3/6/20 a les 23:57, Vincent Vandewalle ha escrit:
> Hi
> 
> QEMU seems to be running on my laptop sometimes but i never installed it
> hence i can not delete it. I'm worried that someone or something is
> taking advantage of my laptop. Could you help me with this?
> 
> Thanks in advance
> 
> Vincent Vandewalle

Virtual pendrive: image

[Narcis Garcia via]

I need to emulate an USB stick with only image file backend.
I've tried this:
$ qemu-system-x86_64 (...) -device virtio-scsi -drive
file=pendrive.img,media=disk,discard=unmap,detect-zeroes=unmap,index=1

But all Windows applications in VM detect it as a hard disk. I need to
use some of them dedicated to format USB pendrives.

How can I do it with qemu command line parameters?

Thank you.

-- 

Narcis Garcia

Re: Can't lauch QEMU with ISO

[Narcis Garcia via]

$ vncviewer 127.0.0.1:5900



Narcis Garcia
El 12/4/20 a les 14:08, BaBa ha escrit:
> Hi,
> 
> I'm trying to launch QEMU with an ISO but it gets stuck on "VNC server 
> running on 127.0.0.1:5900" and nothing else is happening.
> 
> This is the command I use:
> qemu-system-x86_64 -cdrom image.iso
> 
> QEMU version 4.2.0
> 

Re: cannot poweroff debian/mips64el on qemu

[Narcis Garcia via]

I've seen this on some VM with different ACPI/APM/etc boot options.


El 19/1/20 a les 23:39, Jun Sun ha escrit:
> When I do "poweroff" from debian/mips64el on qemu, qemu will hang in
> the end, rather than quitting the process.  See the kernel messages
> below. Last time when I tried 32bit debian/mipsel I was able to quit
> qemu completely.  Any thoughts?
> 
> (No, I don't have "-no-shutdown" option in my qemu commandline.)
> 
> Jun
> 
> 
> [  OK  ] Stopped Raise network interfaces.
> [  OK  ] Stopped Apply Kernel Variables.
> [  OK  ] Stopped target Local File Systems.
> [  OK  ] Stopped target Local File Systems (Pre).
> [  OK  ] Stopped Create Static Device Nodes in /dev.
> [  OK  ] Stopped Create System Users.
> [  OK  ] Stopped Remount Root and Kernel File Systems.
> [  OK  ] Stopped Load Kernel Modules.
> [  OK  ] Reached target Shutdown.
> [  OK  ] Reached target Final Step.
> [  OK  ] Started Power-Off.
> [  OK  ] Reached target Power-Off.
> [   79.830354] systemd-shutdow: 33 output lines suppressed due to ratelimiting
> [   80.113620] systemd-shutdown[1]: Syncing filesystems and block devices.
> [   80.252235] systemd-shutdown[1]: Sending SIGTERM to remaining processes...
> [   80.317935] systemd-journald[144]: Received SIGTERM from PID 1
> (systemd-shutdow).
> [   80.393924] systemd-shutdown[1]: Sending SIGKILL to remaining processes...
> [   80.427856] systemd-shutdown[1]: Unmounting file systems.
> [   80.467625] [383]: Remounting '/' read-only in with options
> 'errors=remount-ro'.
> [   80.490593] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro
> [   80.508067] systemd-shutdown[1]: All filesystems unmounted.
> [   80.508795] systemd-shutdown[1]: Deactivating swaps.
> [   80.511447] systemd-shutdown[1]: All swaps deactivated.
> [   80.512120] systemd-shutdown[1]: Detaching loop devices.
> [   80.517216] systemd-shutdown[1]: All loop devices detached.
> [   80.518078] systemd-shutdown[1]: Detaching DM devices.
> [   80.564236] sd 0:0:0:0: [sda] Synchronizing SCSI cache
> [   80.565791] sd 0:0:0:0: [sda] Stopping disk
> [   80.568175] reboot: System halted
> 

Re: Instalation in kubuntu

[Narcis Garcia via]

I perform these minimal steps:

$ sudo apt update
$ sudo apt install qemu qemu-kvm


El 10/1/20 a les 21:01, Paulo N. Carrillo Peña ha escrit:
> Good morning/afternoon:
> i would like to ask you what are the repositories of qemu? i was trying
> to install it in kubuntu 18 and it doesn't found any package to install it
> 
> Thanks so much
> 
> -- 
> Paulo Nicolás Carrillo Peña
> Phd in Technology - Universitat de Girona
> Msc in Smart cities - Universitat de Girona
> Owner of: Desarrolladores Java - Colombia
> https://www.facebook.com/groups/javadeveloperscolombia/

Re: Best Method To Share Folder Between Linux Host & Windows 10 Guest?

[Narcis Garcia via]

I install samba on host and then I use this syntax for the VM:

$ qemu -device e1000,netdev=net0 -netdev
"user,id=net0,smb=/home/user/Public"

Guest has this path available to access to that host folder:
\\10.0.2.4\qemu


El 14/12/19 a les 3:43, Jesse Palser ha escrit:
> Hi,
> 
> What would be the best method to share a folder between an Ubuntu Linux
> host and Windows 10 guest?
> Let me know, thanks!
> 
> -- 
> Jesse Palser
> jessepal...@gmail.com 
> *Fallen Angel Software*
> Video Game Design Studio
> www.FallenAngelSoftware.com 

Re: *ubuntu 18.04 Host/Windows 10 Guest - Bad Skipping Audio?

[Narcis Garcia via]

Try:
-soundhw hda

El 20/11/19 a les 5:25, Jesse Palser ha escrit:
> Hi,
> 
> I have Windows 10 Pro 64Bit guest on a Kubuntu 18.04.3 LTS 64Bit host.
> Everything is great except the audio coming out of the Windows 10 guest.
> Audio skips badly.
> 
> Any ideas on how to fix bad audio on Windows 10 guest?
> Let me know, thanks!
> 
> -- 
> Jesse Palser
> jessepal...@gmail.com 
> *Fallen Angel Software*
> Video Game Design Studio
> www.FallenAngelSoftware.com 

Re: Cannot ssh a raspbian guest from the host

[Narcis Garcia via]

"inet addr:169.254.62.131"
This indicates guest is not autoconfiguring net with DHCP.


El 17/11/19 a les 17:00, adar...@easysecsolutions.com ha escrit:
> Hi,
> 
>  
> 
> Using QEMU, I emulate a raspberry on an AWS EC2 ubuntu instance and I am
> unable to ssh the raspberry instance from the ubuntu using the command:
> 
> ssh pi@localhost -p 8022
> 
>  
> 
> This is the version of QEMU that I used:
> 
> QEMU emulator version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.20)
> 
> Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
> 
>  
> 
> This is the command I used to run the Raspbian instance:
> 
> sudo qemu-system-arm -no-reboot -curses -kernel
> /home/ubuntu/qemu_vms/kernel-qemu-4.4.34-jessie -cpu arm1176 -m 256 -M
> versatilepb -serial stdio -append root=/dev/sda2 panic=1 rootfstype=ext4
> rw console=ttyAMA0 -drive
> format=raw,file=/home/ubuntu/qemu_vms/2017-03-02-raspbian-jessie.img,index=0,media=disk
> -netdev user,id=shield,hostfwd=tcp:127.0.0.1:8022-:22 -net nic
> 
>  
> 
> This is the output of the ssh command: ssh pi@localhost -p 8022 -v
> 
> OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n  7 Dec 2017
> 
> debug1: Reading configuration data /etc/ssh/ssh_config
> 
> debug1: /etc/ssh/ssh_config line 19: Applying options for *
> 
> debug1: Connecting to localhost [127.0.0.1] port 8022.
> 
> debug1: Connection established.
> 
> debug1: key_load_public: No such file or directory
> 
> debug1: identity file /home/ubuntu/.ssh/id_rsa type -1
> 
> debug1: key_load_public: No such file or directory
> 
> debug1: identity file /home/ubuntu/.ssh/id_rsa-cert type -1
> 
> debug1: key_load_public: No such file or directory
> 
> debug1: identity file /home/ubuntu/.ssh/id_dsa type -1
> 
> debug1: key_load_public: No such file or directory
> 
> debug1: identity file /home/ubuntu/.ssh/id_dsa-cert type -1
> 
> debug1: key_load_public: No such file or directory
> 
> debug1: identity file /home/ubuntu/.ssh/id_ecdsa type -1
> 
> debug1: key_load_public: No such file or directory
> 
> debug1: identity file /home/ubuntu/.ssh/id_ecdsa-cert type -1
> 
> debug1: key_load_public: No such file or directory
> 
> debug1: identity file /home/ubuntu/.ssh/id_ed25519 type -1
> 
> debug1: key_load_public: No such file or directory
> 
> debug1: identity file /home/ubuntu/.ssh/id_ed25519-cert type -1
> 
> debug1: Local version string SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3
> 
> ssh_exchange_identification: read: Connection reset by peer
> 
>  
> 
> I already validated that:
> 
>   * The ssh service is running in the Raspbian instance.
>   * In /etc/sshd_config, PasswordAuthentication is set to *yes*
>   * From the Raspbian instance itself, ssh pi@locahost works fine
>   * Ifconfig returns:
> 
> eth0  Link encap:Ethernet  HWaddr 52:54:00:12:34:56
> 
>   inet addr:169.254.62.131  Bcast:169.254.255.255  Mask:255.255.0.0
> 
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
> 
>   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> 
>   TX packets:46 errors:0 dropped:0 overruns:0 carrier:0
> 
>   collisions:0 txqueuelen:1000
> 
>   RX bytes:0 (0.0 B)  TX bytes:12452 (12.1 KiB)
> 
>   Interrupt:57 Base address:0x8000 DMA chan:ff
> 
>  
> 
> lo    Link encap:Local Loopback
> 
>   inet addr:127.0.0.1  Mask:255.0.0.0
> 
>   UP LOOPBACK RUNNING  MTU:65536  Metric:1
> 
>   RX packets:279 errors:0 dropped:0 overruns:0 frame:0
> 
>   TX packets:279 errors:0 dropped:0 overruns:0 carrier:0
> 
>   collisions:0 txqueuelen:1
> 
>   RX bytes:25786 (25.1 KiB)  TX bytes:25786 (25.1 KiB)
> 
>  
> 
> Can you please help me in this issue?
> 
>  
> 
> Thanks,
> 
> Avraham
> 
>  
> 

Re: Does reboot clear RAM?

[Narcis Garcia via]

El 13/11/19 a les 7:27, Joachim Durchholz ha escrit:
> Am 12.11.19 um 02:20 schrieb Jakob Bohm:
>> On 11/11/2019 20:27, Joachim Durchholz wrote:
>>> Am 11.11.19 um 15:35 schrieb Jakob Bohm:
 On physical machines, the following mechanisms are common:

 1. DRAM chips physically loose their contents after a few seconds of
 power
    off,
>>>
>>> I am by no way an expert, but the forensic experts tell me that data
>>> can persist for *minutes*.
>>> Of course, the first bits flip after a few seconds. But you don't get
>>> a guarantee that everything is zeroed.
>>> I also hear that temperature plays a really big role here.
>>>
>> There's a difference between reading faded bits with special analogue
>> equipment
>> after artificially cooling chips way below what the datasheet allows, and
>> reading the digital bits at normal temperature, voltage etc.
> 
> The refresh circuitry of a DRAM chip is just for the purpose of reading
> faded bits.
> And of course it will read whatever it decides is in the cell. If enough
> electrons are left, it will be above the threshold, so you can expect to
> see the occasional 1 bit in RAM unless it's cleared.
> 
> I'm still interested in hearing whether typical RAM has a RST line and
> whether that wipes memory (or merely initializes internal circuitry).
> Speculation about potential low-level circuit trickery is nice but does
> not answer that question, I fear.

I think the best solution is to implement:
- A flag/parameter to reboots do clear RAM
- A flag/parameter to reboots don't clear RAM
- A default behaviour.

Default behaviour could depend on specified chipset or other virtualized
hardware if that originally have different behaviour.

Re: Does reboot clear RAM?

[Narcis Garcia via]

I'm now supposing that Qemu is currently assigning RAM to guest with
host's RAM garbage: A host leak to guest?


El 12/11/19 a les 2:20, Jakob Bohm ha escrit:
> On 11/11/2019 20:27, Joachim Durchholz wrote:
>> Am 11.11.19 um 15:35 schrieb Jakob Bohm:
>>> On physical machines, the following mechanisms are common:
>>>
>>> 1. DRAM chips physically loose their contents after a few seconds of
>>> power
>>>    off,
>>
>> I am by no way an expert, but the forensic experts tell me that data
>> can persist for *minutes*.
>> Of course, the first bits flip after a few seconds. But you don't get
>> a guarantee that everything is zeroed.
>> I also hear that temperature plays a really big role here.
>>
> There's a difference between reading faded bits with special analogue
> equipment
> after artificially cooling chips way below what the datasheet allows, and
> reading the digital bits at normal temperature, voltage etc.
> 
>>> 3. On x86 and x86_64 PCs, the IBM compatible BIOS typically does a
>>> memory
>>>    test and wipe during actual boot, but not upon a software
>>> initiated boot.
>>>     This PC BIOS rule exists for the following two purposes:
>>>
>>> 3.1 Older guest operating systems use a software reset to switch the CPU
>>>    from "protected mode" to "real mode" because the historical 80286 CPU
>>>    chip had no other way to return to real mode and returning to real
>>> mode
>>>    was needed to invoke BIOS APIs.
>>>
>>> 3.2 Signalling if such a non-wiping boot is desired (for speed or other
>>>    reasons) is officially done by writing a magic value in one of the
>>>    well-known BIOS global addresses, if this global address has not been
>>>    set to one of those magic values, and the global RTC register with
>>>    related semantics have not been so set either, the BIOS (in qemu's
>>>    case SEABIOS) should do the wipe as part of the POST
>>> (Power-On-Self-Test),
>>>    otherwise it should skip that and most other parts of the POST.
>>
>> How does the BIOS do the wipe? Because zeroing out all memory should
>> take some noteiceable time on today's large RAM, even with GHz
>> machines (RAM bus speed has increased far more slowly than typical RAM
>> size, so the time should have been increasing).
>> I can imagine some fast PCI burst transfers to quickly zero memory,
>> but does anybody have realistic data, or information about how it's
>> being done in practice?
>>
> The slowness of manually zeroing and probing all of RAM was the original
> reason for the rule back in 1981.  I suspect modern hardware uses some
> low level trickery in the DRAM interface controller to speed up zeroing
> all DRAM cells.
> 
> 
> 

Re: KVM and Networking access

[Narcis Garcia via]

Same IP as host: Not possible (host and guest are 2 machines).

Own IP at same LAN level as host:
A) Attaching VM tun/tap device to host's bridge (see bridge-utils too)
B) Another host physical NIC attached to VM; Others can tell better how
to passthrough this device to VM.

If the only to reach is guest's webserver (TCP 80,443) there is a really
simpler solution (example with rtl8139 as guest virtual NIC):
$ qemu -device rtl8139,netdev=net0 -netdev
user,id=net0,hostfwd=tcp:0.0.0.0:80-:80,hostfwd=tcp:0.0.0.0:443-:443

(this is the user mode networking, where guest is isolated in its own
LAN, but here we are forwarding 80,443 ports from host NIC/IP to guest,
same as a WAN/LAN firewall does)


El 10/11/19 a les 19:24, Ruben Safir ha escrit:
> Is anyone aware of a simple KVM and QEMU tutorial to create a virtual
> machine that can be assiged a static IP  so that one can run  a
> webserver from it.
> 
> I wanted to set up my webservers that are running in metal, into vms,
> and have them use the same IP addresses that the metal is now currently
> using.I'm not so sure why networking for the VM is so hard.
> 
> I've seen situations where servers even have multiple IP addresses
> assinged to systems with virtual network interfaces such as
> 
> eth0.1
> eth0.2
> 
> etc.  Sonic Walls do this.
> 
> Why do I need a whole networking wrapper for the VM.  Can't I just
> assign the virtual network device inside the VM to the ethernet device
> on the metal, as you can will all the other devices, mouse, keyboard,
> tty, sound.  The VM just maps this stuff as part of the VMs inherent
> ability.  Why does networking require an entire wrapper virtual network?
> 
> I've been told the key to doing this is to build a bridge device (so we
> now have a who bunch of new devices).  But I can't find any tutorials to
> do this, just a lot of confusing and, IMO, poorly written documentation.
> 
> I so miss the old days of Linux HowTOs
> 

Re: Does reboot clear RAM?

[Narcis Garcia via]

In my humble opinion, Qemu should wipe any released RAM area because of
guest shutdown or reboot, same as a physical machine, to guest finds
it's booting in same conditions.


El 8/11/19 a les 23:55, Nachammai Karuppiah ha escrit:
> Does qemu clear the physical address on guest reboot?
> Qemu is started with kernel parameters, ramoops.mem_address=0x7f0
> ramoops.mem_size=0x10 but I do see that the memory even outside
> this region is not wiped away and is retained after rebooting the
> guest
> 

Re: [RFC PATCH] configure: deprecate 32 bit build hosts

[Narcis Garcia via]

El 30/9/19 a les 11:25, Daniel P. Berrangé ha escrit:
> On Thu, Sep 26, 2019 at 10:11:05AM -0700, Richard Henderson wrote:
> 
>> For context, the discussion that Alex and I were having was about int128_t, 
>> and
>> how to support that directly in tcg (especially to/from helpers), and how 
>> that
>> might be vastly easier if we didn't have to consider 32-bit hosts.
> 
> I know nothing about TCG internals, but Is it viable to implement int128_t
> support only in 64-bit host, leaving 32-bit hosts without it ? Or is this
> really a blocking item that is holding back 64-bit host features.
> 

+1
to keep 32-bit host support if it is viable to implement int128_t only
for 64-bit+ builds.

Re: [RFC PATCH] configure: deprecate 32 bit build hosts

[Narcis Garcia via]

El 30/9/19 a les 12:36, Peter Maydell ha escrit:
> On Mon, 30 Sep 2019 at 11:26, Alex Bennée  wrote:
>> So if lots of people still want 32 bit host support for TCG guests we
>> can probably come up with something that keeps existing functionality
>> ticking over while leaving the newer architectural features to 64 bit
>> hosts only.
> 
> I don't think we should do that -- QEMU should offer the same
> (emulated) functionality regardless of host.
> 
> thanks
> -- PMM
> 

+1

Re: [Qemu-discuss] ANNOUNCE: emails from this mailing list will soon drop the [qemu-*] subject tag

[Narcis Garcia]

El 25/9/19 a les 10:44, Alyssa Ross ha escrit:
> Jakob Bohm  writes:
> 
>> Unfortunately, the rushed implementation of the SPF+DKIM+DMARC
>> combination meant that handling of mailing lists wasn't properly
>> integrated in the specifications.  Which in turn resulted in some
>> pretty horrible implementation ideas by both the DMARC group (having
>> each mail list server set up complex e-mail aliases for each
>> participant) and MailMan (suggesting that mailing lists kick out any
>> participants on a DMARC-compatible mail server).
> 
> Note that ARC[1] is coming, which will allow mailing lists to provide
> authentication while doing the conventional modifications.
> 
> Also, Mailman doesn't suggest kicking out participants on
> DMARC-compatible servers. It provides a range of options[2] for how to
> handle mail from posters who have DMARC set to "reject" or "quarantine"
> only.
> 
> [1]: http://arc-spec.org/
> [2]: 
> https://mailman.readthedocs.io/en/latest/src/mailman/handlers/docs/dmarc-mitigations.html
> 

https://en.wikipedia.org/wiki/Authenticated_Received_Chain

Re: [Qemu-discuss] ANNOUNCE: emails from this mailing list will soon drop the [qemu-*] subject tag

[Narcis Garcia]

Is far better mail servers use SPF and not DKIM.
DKIM is a signature between servers, but valid author's signatures are
far better done with PGP by author itself because is made by author and
verified by reader.

DKIM doesn't protect mail content autenticity at all, beginning with the
content sent from MUA to MTA.

PGP signatures are compatible with mailing lists footers and prefixes.
DKIM has only sense to mail servers control mail contents, and being
from same mail servers that contents can be hacked.


El 10/9/19 a les 10:38, Peter Maydell ha escrit:
> Hi; this is an announcement to let you know that in future
> emails to all QEMU project mailing lists (including this one)
> will no longer have the [qemu-*] tag in their Subject line.
> 
> We need to make this config change because having the mailing
> list server edit subject lines like this conflicts with the
> increasingly common DKIM/DMARC anti-email-forgery system. We
> used to work around this by having the list server rewrite
> email From addresses instead, but this has proven to have
> bad consequences (notably that patches applied from emails
> to QEMU can end up with incorrect authorship by accident).
> 
> If you were using the Subject line tag to filter QEMU emails,
> you'll need to change your mail client's config to instead
> look at the "List-Id:" message header to identify list traffic
> (you can do this now without waiting for us to change the
> list config to drop the subject tags).
> 
> Apologies for any inconvenience that this upcoming config
> change might cause you.
> 
> thanks
> -- PMM
> 

Re: [Qemu-discuss] ANNOUNCE: emails from this mailing list will soon drop the [qemu-*] subject tag

[Narcis Garcia]

El 10/9/19 a les 20:02, Frans de Boer ha escrit:
> On 10-09-19 16:02, Narcis Garcia wrote:
>> El 10/9/19 a les 15:44, Frans de Boer ha escrit:
>>> On 10-09-19 14:48, Narcis Garcia wrote:
>>>> El 10/9/19 a les 12:49, Frans de Boer ha escrit:
>>>>> On 10-09-19 10:49, Actiu informatica wrote:
>>>>>> Does anybody know how to make M.Thunderbird to use "List-Id"
>>>>>> header to
>>>>>> label any mailing list (without having to setup for each mailing
>>>>>> list).
>>>>>>
>>>>>>
>>>>>> El 10/9/19 a les 10:38, Peter Maydell ha escrit:
>>>>>>> Hi; this is an announcement to let you know that in future
>>>>>>> emails to all QEMU project mailing lists (including this one)
>>>>>>> will no longer have the [qemu-*] tag in their Subject line.
>>>>>>>
>>>>>>> We need to make this config change because having the mailing
>>>>>>> list server edit subject lines like this conflicts with the
>>>>>>> increasingly common DKIM/DMARC anti-email-forgery system. We
>>>>>>> used to work around this by having the list server rewrite
>>>>>>> email From addresses instead, but this has proven to have
>>>>>>> bad consequences (notably that patches applied from emails
>>>>>>> to QEMU can end up with incorrect authorship by accident).
>>>>>>>
>>>>>>> If you were using the Subject line tag to filter QEMU emails,
>>>>>>> you'll need to change your mail client's config to instead
>>>>>>> look at the "List-Id:" message header to identify list traffic
>>>>>>> (you can do this now without waiting for us to change the
>>>>>>> list config to drop the subject tags).
>>>>>>>
>>>>>>> Apologies for any inconvenience that this upcoming config
>>>>>>> change might cause you.
>>>>>>>
>>>>>>> thanks
>>>>>>> -- PMM
>>>>>>>
>>>>> AFAIK, there is no general solution, other then adding List-Id to the
>>>>> list of identifiers and adding the supplied list-id by the message as
>>>>> identifier. Just like currently, you have to change the filter from
>>>>> "from" into List-Id for every filter for messages using List-Id.
>>>>> Mine is now working for this list.
>>>> Thank you.
>>>> There seems to not be any way to put (neither by filters tool) a label
>>>> or tag that can be seen at Inbox list.
>>>> Currently I can distinguish by subject's "[Qemu-discuss]" same as many
>>>> other mailing lists.
>>>>
>>>> A Mozilla plugin like old "Mailing List Manager" by mixedpuppy is
>>>> desirable, but I don't find any similar.
>>>>
>>> You can add List-Id by selecting customize in the left column - select
>>> customize, Add en enter List-Id. Then add the value as given by the
>>> List-Id. To see the List-Id: display full header or select show source.
>>>
>> I don't see the /Customize/ option for selectable columns. I see it as
>> in image I attach here:
>>
>>
> Select Tools -> Message Filters -> Select the entry you want to change
> -> Edit -> Left Column (From, cc, to etc), click Customize -> Type in
> List-Id -> click Add and OK.
> 
> Your image is not included in the list mail. If this does not help you,
> try the help function or search for examples on the Internet.

Oh, I already knew how to setup this for a single (or each) mailing
list; thank you anyway. But I was looking for a general behaviour like
auto-labelling or auto-classifying with any List-Id header value.

As selectable columns I understood this:
https://support.mozilla.org/kb/message-list-columns
(It was useful if there was a List-Id column)

Re: [Qemu-discuss] ANNOUNCE: emails from this mailing list will soon drop the [qemu-*] subject tag

[Narcis Garcia]

El 10/9/19 a les 15:44, Frans de Boer ha escrit:
> On 10-09-19 14:48, Narcis Garcia wrote:
>> El 10/9/19 a les 12:49, Frans de Boer ha escrit:
>>> On 10-09-19 10:49, Actiu informatica wrote:
>>>> Does anybody know how to make M.Thunderbird to use "List-Id" header to
>>>> label any mailing list (without having to setup for each mailing
>>>> list).
>>>>
>>>>
>>>> El 10/9/19 a les 10:38, Peter Maydell ha escrit:
>>>>> Hi; this is an announcement to let you know that in future
>>>>> emails to all QEMU project mailing lists (including this one)
>>>>> will no longer have the [qemu-*] tag in their Subject line.
>>>>>
>>>>> We need to make this config change because having the mailing
>>>>> list server edit subject lines like this conflicts with the
>>>>> increasingly common DKIM/DMARC anti-email-forgery system. We
>>>>> used to work around this by having the list server rewrite
>>>>> email From addresses instead, but this has proven to have
>>>>> bad consequences (notably that patches applied from emails
>>>>> to QEMU can end up with incorrect authorship by accident).
>>>>>
>>>>> If you were using the Subject line tag to filter QEMU emails,
>>>>> you'll need to change your mail client's config to instead
>>>>> look at the "List-Id:" message header to identify list traffic
>>>>> (you can do this now without waiting for us to change the
>>>>> list config to drop the subject tags).
>>>>>
>>>>> Apologies for any inconvenience that this upcoming config
>>>>> change might cause you.
>>>>>
>>>>> thanks
>>>>> -- PMM
>>>>>
>>> AFAIK, there is no general solution, other then adding List-Id to the
>>> list of identifiers and adding the supplied list-id by the message as
>>> identifier. Just like currently, you have to change the filter from
>>> "from" into List-Id for every filter for messages using List-Id.
>>> Mine is now working for this list.
>> Thank you.
>> There seems to not be any way to put (neither by filters tool) a label
>> or tag that can be seen at Inbox list.
>> Currently I can distinguish by subject's "[Qemu-discuss]" same as many
>> other mailing lists.
>>
>> A Mozilla plugin like old "Mailing List Manager" by mixedpuppy is
>> desirable, but I don't find any similar.
>>
> You can add List-Id by selecting customize in the left column - select
> customize, Add en enter List-Id. Then add the value as given by the
> List-Id. To see the List-Id: display full header or select show source.
>
I don't see the /Customize/ option for selectable columns. I see it as
in image I attach here:

Re: [Qemu-discuss] ANNOUNCE: emails from this mailing list will soon drop the [qemu-*] subject tag

[Narcis Garcia]

El 10/9/19 a les 12:49, Frans de Boer ha escrit:
> On 10-09-19 10:49, Actiu informatica wrote:
>> Does anybody know how to make M.Thunderbird to use "List-Id" header to
>> label any mailing list (without having to setup for each mailing list).
>>
>>
>> El 10/9/19 a les 10:38, Peter Maydell ha escrit:
>>> Hi; this is an announcement to let you know that in future
>>> emails to all QEMU project mailing lists (including this one)
>>> will no longer have the [qemu-*] tag in their Subject line.
>>>
>>> We need to make this config change because having the mailing
>>> list server edit subject lines like this conflicts with the
>>> increasingly common DKIM/DMARC anti-email-forgery system. We
>>> used to work around this by having the list server rewrite
>>> email From addresses instead, but this has proven to have
>>> bad consequences (notably that patches applied from emails
>>> to QEMU can end up with incorrect authorship by accident).
>>>
>>> If you were using the Subject line tag to filter QEMU emails,
>>> you'll need to change your mail client's config to instead
>>> look at the "List-Id:" message header to identify list traffic
>>> (you can do this now without waiting for us to change the
>>> list config to drop the subject tags).
>>>
>>> Apologies for any inconvenience that this upcoming config
>>> change might cause you.
>>>
>>> thanks
>>> -- PMM
>>>
> AFAIK, there is no general solution, other then adding List-Id to the
> list of identifiers and adding the supplied list-id by the message as
> identifier. Just like currently, you have to change the filter from
> "from" into List-Id for every filter for messages using List-Id.
> Mine is now working for this list.

Thank you.
There seems to not be any way to put (neither by filters tool) a label
or tag that can be seen at Inbox list.
Currently I can distinguish by subject's "[Qemu-discuss]" same as many
other mailing lists.

A Mozilla plugin like old "Mailing List Manager" by mixedpuppy is
desirable, but I don't find any similar.

Re: [Qemu-discuss] ANNOUNCE: emails from this mailing list will soon drop the [qemu-*] subject tag

[Narcis Garcia]

Does anybody know how to make M.Thunderbird to use "List-Id" header to
label any mailing list (without having to setup for each mailing list).


El 10/9/19 a les 10:38, Peter Maydell ha escrit:
> Hi; this is an announcement to let you know that in future
> emails to all QEMU project mailing lists (including this one)
> will no longer have the [qemu-*] tag in their Subject line.
> 
> We need to make this config change because having the mailing
> list server edit subject lines like this conflicts with the
> increasingly common DKIM/DMARC anti-email-forgery system. We
> used to work around this by having the list server rewrite
> email From addresses instead, but this has proven to have
> bad consequences (notably that patches applied from emails
> to QEMU can end up with incorrect authorship by accident).
> 
> If you were using the Subject line tag to filter QEMU emails,
> you'll need to change your mail client's config to instead
> look at the "List-Id:" message header to identify list traffic
> (you can do this now without waiting for us to change the
> list config to drop the subject tags).
> 
> Apologies for any inconvenience that this upcoming config
> change might cause you.
> 
> thanks
> -- PMM
> 

[Qemu-discuss] no-frame and no-menubar in Gtk display type

[Narcis Garcia]

How can I specify in command line to not show menu bar and window
decorations when using -display gtk ?

Thank you.

Re: [Qemu-discuss] qemu networking guestfwd

[Narcis Garcia]

I think it's a guest OS matter and not guest machine matter.
I suppose you should redirect at guest a local port to host's IP.


El 28/5/19 a les 15:59, Pascal ha escrit:
> hi,
> 
> how to redirect a local port in guest to a local port on host (adb) ?
> 
> I've tried :
> 
> qemu ... -nic user,guestfwd=tcp:127.0.0.1:5037-tcp:127.0.0.1:5037
> 
> but I've got this error :
> 
> qemu-system-x86_64: Conflicting/invalid host:port in guest forwarding rule
> 'tcp:127.0.0.1:5037-tcp:127.0.0.1:5037'
> 
> thanks.
> 

Re: [Qemu-discuss] Ubuntu installation shows "No network interfaces detected"

[Narcis Garcia]

Host OS?
Host architecture?
Qemu version?

I use this for a Realtek 8139 emulation:

-device rtl8139,netdev=net0 -netdev "user,id=net0"

El 11/4/19 a les 23:46, Da Zhang ha escrit:
> Hi guys,
> 
> I am trying to create an Ubuntu ARM disk image for my gem5 ARM experiments.
> The installation always shows "No network interfaces detected".
> This is my command for running qemu:
> 
> qemu-system-aarch64 \
> -cpu host \
> -device virtio-scsi-device \
> -device scsi-cd,drive=cdrom \
> -device virtio-blk-device,drive=hd0 \
> -drive
> "file=ubuntu-16.04.5-server-arm64.iso,id=cdrom,if=none,media=cdrom" \
> -drive
> "if=none,format=qcow2,file=ubuntu-16.04.5-server-arm64.img,id=hd0" \
> -pflash "ubuntu-16.04.5-server-arm64-flash0.img" \
> -pflash "ubuntu-16.04.5-server-arm64-flash1.img" \
> -m 1G \
> -machine virt \
> -enable-kvm \
> -nographic \
> -net nic,netdev=n1 \
> -netdev user,id=n1 \
> ;
> 
> I ran it on a "ROCKPro64 64-bit Hexa-Core Computer" ARM borad with KVM
> enabled. Any suggestions to fix "No network interfaces detected"?
> 
> best,
> Da Zhang
> 

Re: [Qemu-discuss] Discard disk image holes for sparse shrink

[Narcis Garcia]

Okay, more clear report:
$ lsblk -do NAME,ROTA,DISC-GRAN


El 10/4/19 a les 14:12, Pascal ha escrit:
> I would tend to say that "discard" is not related to "ssd" while "rotational"
> is...
> 
> Le mer. 10 avr. 2019 à 14:06, Pascal  a écrit :
> 
>> lsblk -ndo ROTA /dev/sda
>>
>> sorry for the bad copy.
>>
>> Le mer. 10 avr. 2019 à 12:52, Narcis Garcia  a
>> écrit :
>>
>>> Can be this rotational detection be affecting in this case?
>>>
>>> https://lists.openvz.org/pipermail/users/2019-April/007564.html
>>> (Devuan 1.0 VM with distro kernel succeeds with lsblk and fstrim)
>>>
>>> How can I make guest OS to detect device as no rotational or true SSD?
>>>
>>>
>>> El 10/4/19 a les 12:47, Narcis Garcia ha escrit:
>>>> Pascal, I don't understand syntax you use for lsblk.
>>>> I see this with:
>>>> $ cat /sys/block/sda/queue/rotational
>>>>
>>>>
>>>> El 10/4/19 a les 12:38, Pascal ha escrit:
>>>>> it's ok with  discard=unmap  option (even if the disc is
>>> thick-provisioned)
>>>>> : the block used by the  test  file appears (VM side) or is reset (host
>>>>> side) at zero.
>>>>>
>>>>> notice that  lsblk  "thinks" that the disc is a rotational disk (eg.
>>> not
>>>>> really SSD) :
>>>>>
>>>>> lsblk -ndo /dev/sda
>>>>> 1
>>>>>
>>>>> thanks for explanations !
>>>>>
>>>>> Le mar. 9 avr. 2019 à 20:38, Narcis Garcia  a
>>> écrit :
>>>>>
>>>>>> I see now the simple:
>>>>>> -device virtio-scsi-pci
>>>>>> makes all -disk (media=disk) to be detected by guest as SSD
>>>>>>
>>>>>> Additionally, adding "discard=unmap,detect-zeroes=unmap" to disk image
>>>>>> specification makes host Qemu to discard sparse image holes and
>>> recover
>>>>>> host disk space when guest sends discard signal!
>>>>>>
>>>>>> This is my successful test with Debian 9 (stable):
>>>>>>
>>>>>> $ dd if=/dev/zero of=ssd.img obs=1M seek=128 count=0
>>>>>> $ qemu-system-... -device virtio-scsi-pci -drive
>>>>>> file=ssd.img,media=disk,index=0,discard=unmap,detect-zeroes=unmap
>>>>>>
>>>>>> Thank you everyone.
>>>>>>
>>>>>>
>>>>>> El 9/4/19 a les 19:19, Friedrich Oslage ha escrit:
>>>>>>> 1. You need to set the discard option for the -drive parameter, eg
>>>>>>> -drive if=none,...,format=raw,discard=unmap since the default is
>>> still
>>>>>>> to simply ignore discards.
>>>>>>>
>>>>>>> You may also want to set the detect-zeroes option to unmap, to
>>> discard
>>>>>>> all-zero blocks instead of actually writing them.
>>>>>>>
>>>>>>>
>>>>>>> 2. The disk image you created is thick-provisioned. How is qemu
>>> supposed
>>>>>>> to discard anything in that file? It could turn it into a sparse
>>> file or
>>>>>>> overwrite it with zeroes I suppose, but both options are undesirable.
>>>>>>>
>>>>>>> To make use of the discard operation your backing storage has to
>>> support
>>>>>>> it. Either by beeing thin-provisioned, like qcow2 or raw sparse
>>> files,
>>>>>>> or by actually beeing a ssd/nvme disk.
>>>>>>>
>>>>>>>
>>>>>>> 3. Your testing method is flawed. You are using a journaling
>>> filesystem
>>>>>>> to write the data but to read it you access the block device
>>> directly .
>>>>>>> Even if the discard operation was working strings(1) would still show
>>>>>>> the hello-world string in the journal.
>>>>>>>
>>>>>>> You could try something like this:
>>>>>>>
>>>>>>> $ echo hello, world > /dev/sda
>>>>>>> $ strings /dev/sda
>>>>>>> $ blkdiscard /dev/sda
>>>>>>> $ strings /dev/sda
>>>>>>>
>>>>>>>
>>>>>>> Regards
>>>>>>>

Re: [Qemu-discuss] Discard disk image holes for sparse shrink

[Narcis Garcia]

Can be this rotational detection be affecting in this case?

https://lists.openvz.org/pipermail/users/2019-April/007564.html
(Devuan 1.0 VM with distro kernel succeeds with lsblk and fstrim)

How can I make guest OS to detect device as no rotational or true SSD?


El 10/4/19 a les 12:47, Narcis Garcia ha escrit:
> Pascal, I don't understand syntax you use for lsblk.
> I see this with:
> $ cat /sys/block/sda/queue/rotational
> 
> 
> El 10/4/19 a les 12:38, Pascal ha escrit:
>> it's ok with  discard=unmap  option (even if the disc is thick-provisioned)
>> : the block used by the  test  file appears (VM side) or is reset (host
>> side) at zero.
>>
>> notice that  lsblk  "thinks" that the disc is a rotational disk (eg. not
>> really SSD) :
>>
>> lsblk -ndo /dev/sda
>> 1
>>
>> thanks for explanations !
>>
>> Le mar. 9 avr. 2019 à 20:38, Narcis Garcia  a écrit :
>>
>>> I see now the simple:
>>> -device virtio-scsi-pci
>>> makes all -disk (media=disk) to be detected by guest as SSD
>>>
>>> Additionally, adding "discard=unmap,detect-zeroes=unmap" to disk image
>>> specification makes host Qemu to discard sparse image holes and recover
>>> host disk space when guest sends discard signal!
>>>
>>> This is my successful test with Debian 9 (stable):
>>>
>>> $ dd if=/dev/zero of=ssd.img obs=1M seek=128 count=0
>>> $ qemu-system-... -device virtio-scsi-pci -drive
>>> file=ssd.img,media=disk,index=0,discard=unmap,detect-zeroes=unmap
>>>
>>> Thank you everyone.
>>>
>>>
>>> El 9/4/19 a les 19:19, Friedrich Oslage ha escrit:
>>>> 1. You need to set the discard option for the -drive parameter, eg
>>>> -drive if=none,...,format=raw,discard=unmap since the default is still
>>>> to simply ignore discards.
>>>>
>>>> You may also want to set the detect-zeroes option to unmap, to discard
>>>> all-zero blocks instead of actually writing them.
>>>>
>>>>
>>>> 2. The disk image you created is thick-provisioned. How is qemu supposed
>>>> to discard anything in that file? It could turn it into a sparse file or
>>>> overwrite it with zeroes I suppose, but both options are undesirable.
>>>>
>>>> To make use of the discard operation your backing storage has to support
>>>> it. Either by beeing thin-provisioned, like qcow2 or raw sparse files,
>>>> or by actually beeing a ssd/nvme disk.
>>>>
>>>>
>>>> 3. Your testing method is flawed. You are using a journaling filesystem
>>>> to write the data but to read it you access the block device directly .
>>>> Even if the discard operation was working strings(1) would still show
>>>> the hello-world string in the journal.
>>>>
>>>> You could try something like this:
>>>>
>>>> $ echo hello, world > /dev/sda
>>>> $ strings /dev/sda
>>>> $ blkdiscard /dev/sda
>>>> $ strings /dev/sda
>>>>
>>>>
>>>> Regards
>>>> Friedrich
>>>>
>>>> On 4/9/19 4:38 PM, Pascal wrote:
>>>>> the blocks do not seem to be discarded on a raw format disk: the data
>>>>> remains on the disk...
>>>>>
>>>>> on host :
>>>>>
>>>>> dd if=/dev/zero of=/tmp/ssd.disk bs=1M count=128
>>>>> qemu -drive media=disk,file=linux.disk -device virtio-scsi-pci,id=scsi
>>>>> -device scsi-hd,drive=hd -drive
>>>>> if=none,id=hd,file=/tmp/ssd.disk,format=raw
>>>>>
>>>>> on Linux VM :
>>>>>
>>>>> fdisk /dev/sda
>>>>>  # create one partition on gpt type...
>>>>> fdisk -l /dev/sda
>>>>>  Disk /dev/sda: 128 MiB, 134217728 bytes, 262144 sectors
>>>>>  Units: sectors of 1 * 512 = 512 bytes
>>>>>  Sector size (logical/physical): 512 bytes / 512 bytes
>>>>>  I/O size (minimum/optimal): 512 bytes / 512 bytes
>>>>>  Disklabel type: gpt
>>>>>  Disk identifier: B8D98B8E-7790-4043-8F37-D4D8CA218884
>>>>>  Device StartEnd Sectors  Size Type
>>>>>  /dev/sda1  2048 262110  260063  127M Linux filesystem
>>>>> mkfs.ext4 -L ssd /dev/sda1
>>>>> mount /dev/sda1 /ssd
>>>>> mount
>>>>>  /dev/sda1 on /ssd type ext4 (rw,relatime,data=orde

Re: [Qemu-discuss] Discard disk image holes for sparse shrink

[Narcis Garcia]

Pascal, I don't understand syntax you use for lsblk.
I see this with:
$ cat /sys/block/sda/queue/rotational


El 10/4/19 a les 12:38, Pascal ha escrit:
> it's ok with  discard=unmap  option (even if the disc is thick-provisioned)
> : the block used by the  test  file appears (VM side) or is reset (host
> side) at zero.
> 
> notice that  lsblk  "thinks" that the disc is a rotational disk (eg. not
> really SSD) :
> 
> lsblk -ndo /dev/sda
> 1
> 
> thanks for explanations !
> 
> Le mar. 9 avr. 2019 à 20:38, Narcis Garcia  a écrit :
> 
>> I see now the simple:
>> -device virtio-scsi-pci
>> makes all -disk (media=disk) to be detected by guest as SSD
>>
>> Additionally, adding "discard=unmap,detect-zeroes=unmap" to disk image
>> specification makes host Qemu to discard sparse image holes and recover
>> host disk space when guest sends discard signal!
>>
>> This is my successful test with Debian 9 (stable):
>>
>> $ dd if=/dev/zero of=ssd.img obs=1M seek=128 count=0
>> $ qemu-system-... -device virtio-scsi-pci -drive
>> file=ssd.img,media=disk,index=0,discard=unmap,detect-zeroes=unmap
>>
>> Thank you everyone.
>>
>>
>> El 9/4/19 a les 19:19, Friedrich Oslage ha escrit:
>>> 1. You need to set the discard option for the -drive parameter, eg
>>> -drive if=none,...,format=raw,discard=unmap since the default is still
>>> to simply ignore discards.
>>>
>>> You may also want to set the detect-zeroes option to unmap, to discard
>>> all-zero blocks instead of actually writing them.
>>>
>>>
>>> 2. The disk image you created is thick-provisioned. How is qemu supposed
>>> to discard anything in that file? It could turn it into a sparse file or
>>> overwrite it with zeroes I suppose, but both options are undesirable.
>>>
>>> To make use of the discard operation your backing storage has to support
>>> it. Either by beeing thin-provisioned, like qcow2 or raw sparse files,
>>> or by actually beeing a ssd/nvme disk.
>>>
>>>
>>> 3. Your testing method is flawed. You are using a journaling filesystem
>>> to write the data but to read it you access the block device directly .
>>> Even if the discard operation was working strings(1) would still show
>>> the hello-world string in the journal.
>>>
>>> You could try something like this:
>>>
>>> $ echo hello, world > /dev/sda
>>> $ strings /dev/sda
>>> $ blkdiscard /dev/sda
>>> $ strings /dev/sda
>>>
>>>
>>> Regards
>>> Friedrich
>>>
>>> On 4/9/19 4:38 PM, Pascal wrote:
>>>> the blocks do not seem to be discarded on a raw format disk: the data
>>>> remains on the disk...
>>>>
>>>> on host :
>>>>
>>>> dd if=/dev/zero of=/tmp/ssd.disk bs=1M count=128
>>>> qemu -drive media=disk,file=linux.disk -device virtio-scsi-pci,id=scsi
>>>> -device scsi-hd,drive=hd -drive
>>>> if=none,id=hd,file=/tmp/ssd.disk,format=raw
>>>>
>>>> on Linux VM :
>>>>
>>>> fdisk /dev/sda
>>>>  # create one partition on gpt type...
>>>> fdisk -l /dev/sda
>>>>  Disk /dev/sda: 128 MiB, 134217728 bytes, 262144 sectors
>>>>  Units: sectors of 1 * 512 = 512 bytes
>>>>  Sector size (logical/physical): 512 bytes / 512 bytes
>>>>  I/O size (minimum/optimal): 512 bytes / 512 bytes
>>>>  Disklabel type: gpt
>>>>  Disk identifier: B8D98B8E-7790-4043-8F37-D4D8CA218884
>>>>  Device StartEnd Sectors  Size Type
>>>>  /dev/sda1  2048 262110  260063  127M Linux filesystem
>>>> mkfs.ext4 -L ssd /dev/sda1
>>>> mount /dev/sda1 /ssd
>>>> mount
>>>>  /dev/sda1 on /ssd type ext4 (rw,relatime,data=ordered)
>>>> echo hello world > /ssd/test
>>>> cat /ssd/test
>>>>  hello world
>>>> sync && sysctl -q vm.drop_caches=3
>>>> rm -f /ssd/test
>>>> sync && sysctl -q vm.drop_caches=3
>>>> fstrim /ssd
>>>> umount /ssd
>>>> strings /dev/sda1 | grep 'hello world'
>>>>  hello world
>>>>
>>>>
>>>> Le mar. 9 avr. 2019 à 08:36, Narcis Garcia  a
>>>> écrit :
>>>>
>>>>> Thank you.
>>>>>
>>>>> * I use RAW images because of it's easier to offline mount/chroot when
>>&g

Re: [Qemu-discuss] Discard disk image holes for sparse shrink

[Narcis Garcia]

I see now the simple:
-device virtio-scsi-pci
makes all -disk (media=disk) to be detected by guest as SSD

Additionally, adding "discard=unmap,detect-zeroes=unmap" to disk image
specification makes host Qemu to discard sparse image holes and recover
host disk space when guest sends discard signal!

This is my successful test with Debian 9 (stable):

$ dd if=/dev/zero of=ssd.img obs=1M seek=128 count=0
$ qemu-system-... -device virtio-scsi-pci -drive
file=ssd.img,media=disk,index=0,discard=unmap,detect-zeroes=unmap

Thank you everyone.


El 9/4/19 a les 19:19, Friedrich Oslage ha escrit:
> 1. You need to set the discard option for the -drive parameter, eg
> -drive if=none,...,format=raw,discard=unmap since the default is still
> to simply ignore discards.
> 
> You may also want to set the detect-zeroes option to unmap, to discard
> all-zero blocks instead of actually writing them.
> 
> 
> 2. The disk image you created is thick-provisioned. How is qemu supposed
> to discard anything in that file? It could turn it into a sparse file or
> overwrite it with zeroes I suppose, but both options are undesirable.
> 
> To make use of the discard operation your backing storage has to support
> it. Either by beeing thin-provisioned, like qcow2 or raw sparse files,
> or by actually beeing a ssd/nvme disk.
> 
> 
> 3. Your testing method is flawed. You are using a journaling filesystem
> to write the data but to read it you access the block device directly .
> Even if the discard operation was working strings(1) would still show
> the hello-world string in the journal.
> 
> You could try something like this:
> 
> $ echo hello, world > /dev/sda
> $ strings /dev/sda
> $ blkdiscard /dev/sda
> $ strings /dev/sda
> 
> 
> Regards
> Friedrich
> 
> On 4/9/19 4:38 PM, Pascal wrote:
>> the blocks do not seem to be discarded on a raw format disk: the data
>> remains on the disk...
>>
>> on host :
>>
>> dd if=/dev/zero of=/tmp/ssd.disk bs=1M count=128
>> qemu -drive media=disk,file=linux.disk -device virtio-scsi-pci,id=scsi
>> -device scsi-hd,drive=hd -drive
>> if=none,id=hd,file=/tmp/ssd.disk,format=raw
>>
>> on Linux VM :
>>
>> fdisk /dev/sda
>>  # create one partition on gpt type...
>> fdisk -l /dev/sda
>>  Disk /dev/sda: 128 MiB, 134217728 bytes, 262144 sectors
>>  Units: sectors of 1 * 512 = 512 bytes
>>  Sector size (logical/physical): 512 bytes / 512 bytes
>>  I/O size (minimum/optimal): 512 bytes / 512 bytes
>>  Disklabel type: gpt
>>  Disk identifier: B8D98B8E-7790-4043-8F37-D4D8CA218884
>>  Device Start    End Sectors  Size Type
>>  /dev/sda1  2048 262110  260063  127M Linux filesystem
>> mkfs.ext4 -L ssd /dev/sda1
>> mount /dev/sda1 /ssd
>> mount
>>  /dev/sda1 on /ssd type ext4 (rw,relatime,data=ordered)
>> echo hello world > /ssd/test
>> cat /ssd/test
>>  hello world
>> sync && sysctl -q vm.drop_caches=3
>> rm -f /ssd/test
>> sync && sysctl -q vm.drop_caches=3
>> fstrim /ssd
>> umount /ssd
>> strings /dev/sda1 | grep 'hello world'
>>  hello world
>>
>>
>> Le mar. 9 avr. 2019 à 08:36, Narcis Garcia  a
>> écrit :
>>
>>> Thank you.
>>>
>>> * I use RAW images because of it's easier to offline mount/chroot when
>>> some issue happens.
>>> * I call directly qemu instead of libvirt
>>>
>>> I'll try to parse these parameters to a qemu-system call.
>>>
>>>
>>> El 8/4/19 a les 22:03, Friedrich Oslage ha escrit:
>>>> Yes.
>>>>
>>>> You'll have to use the virtio-scsi driver, to my knowledge it's the
>>>> only
>>>> driver that supports block discards.
>>>>
>>>> Quick example:
>>>>
>>>> # create a new empty disk
>>>> $ qemu-img create -f qcow2 disk.qcow2 10G
>>>>
>>>> # check size, should only be a few kilobytes
>>>> $ du -sh disk.qcow2
>>>>
>>>> # add it to your vm
>>>> $ virtsh edit your-vm
>>>>    
>>>>  >>> detect_zeroes='unmap'/>
>>>>  
>>>>  
>>>>  
>>>>    
>>>>    
>>>>  
>>>>    
>>>>
>>>> # in your vm, format and mount it
>>>> $ mkfs.ext4 /dev/sda
>>>> $ mount /dev/sda /mnt/discardtest
>>>>
>>>> # put some data on it
>>>> $ dd if=/dev/urandom of=/mnt/discardtest/dummy.bin bs=1M count=10

Re: [Qemu-discuss] Discard disk image holes for sparse shrink

[Narcis Garcia]

A test to check if guest Linux kernel treats vdisk as SSD:
Instead of:
mount /dev/sda1 /ssd
mount
Do this:
mount -o discard /dev/sda1 /ssd
mount

Anyway I don't think 'strings' test must be reflecting real blocks
discard behavior if not:
1. qemu taking image file actions for guest discard signals
2. Raw disk image being sparsed:
dd if=/dev/zero of=/tmp/ssd.disk obs=1M seek=128 count=0


El 9/4/19 a les 16:38, Pascal ha escrit:
> the blocks do not seem to be discarded on a raw format disk: the data
> remains on the disk...
> 
> on host :
> 
> dd if=/dev/zero of=/tmp/ssd.disk bs=1M count=128
> qemu -drive media=disk,file=linux.disk -device virtio-scsi-pci,id=scsi
> -device scsi-hd,drive=hd -drive if=none,id=hd,file=/tmp/ssd.disk,format=raw
> 
> on Linux VM :
> 
> fdisk /dev/sda
> # create one partition on gpt type...
> fdisk -l /dev/sda
> Disk /dev/sda: 128 MiB, 134217728 bytes, 262144 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: gpt
> Disk identifier: B8D98B8E-7790-4043-8F37-D4D8CA218884
> Device StartEnd Sectors  Size Type
> /dev/sda1  2048 262110  260063  127M Linux filesystem
> mkfs.ext4 -L ssd /dev/sda1
> mount /dev/sda1 /ssd
> mount
> /dev/sda1 on /ssd type ext4 (rw,relatime,data=ordered)
> echo hello world > /ssd/test
> cat /ssd/test
> hello world
> sync && sysctl -q vm.drop_caches=3
> rm -f /ssd/test
> sync && sysctl -q vm.drop_caches=3
> fstrim /ssd
> umount /ssd
> strings /dev/sda1 | grep 'hello world'
> hello world
> 
> 
> Le mar. 9 avr. 2019 à 08:36, Narcis Garcia  a écrit :
> 
>> Thank you.
>>
>> * I use RAW images because of it's easier to offline mount/chroot when
>> some issue happens.
>> * I call directly qemu instead of libvirt
>>
>> I'll try to parse these parameters to a qemu-system call.
>>
>>
>> El 8/4/19 a les 22:03, Friedrich Oslage ha escrit:
>>> Yes.
>>>
>>> You'll have to use the virtio-scsi driver, to my knowledge it's the only
>>> driver that supports block discards.
>>>
>>> Quick example:
>>>
>>> # create a new empty disk
>>> $ qemu-img create -f qcow2 disk.qcow2 10G
>>>
>>> # check size, should only be a few kilobytes
>>> $ du -sh disk.qcow2
>>>
>>> # add it to your vm
>>> $ virtsh edit your-vm
>>>   
>>> >> detect_zeroes='unmap'/>
>>> 
>>> 
>>> 
>>>   
>>>   
>>> 
>>>   
>>>
>>> # in your vm, format and mount it
>>> $ mkfs.ext4 /dev/sda
>>> $ mount /dev/sda /mnt/discardtest
>>>
>>> # put some data on it
>>> $ dd if=/dev/urandom of=/mnt/discardtest/dummy.bin bs=1M count=1000
>>> $ sync
>>>
>>> # on host, check size...it should be about 1GB
>>> $ du -sh disk.qcow2
>>>
>>> # in vm, delete file and trim it
>>> $ rm /mnt/discardtest/dummy.bin
>>> $ sync
>>> $ fstrim /mnt/discardtest
>>>
>>> # on host, check size...should only be a few megabytes
>>> $ du -sh disk.qcow2
>>>
>>>
>>> It works with other guest OSes as well, for Windows you just use the
>>> Optimize-Volume cmdlets instead of fstrim.
>>>
>>> You also don't have to use qcow2 for backing. Anything that can handle
>>> discards will do, including sparse files.
>>>
>>>
>>> My advice, however, would be to use qcow2, since sparse files don't work
>>> particularly well. Executing the example above would leave you with
>>> about 300MB at the end instead of less than 10MB.
>>>
>>> Regards
>>> Friedrich
>>>
>>> On 4/5/19 4:04 PM, Narcis Garcia wrote:
>>>> No; I want to study the possibility of recovering allocated blocs of
>>>> host filesystem when guest filesystem removes its files (unallocates its
>>>> blocks).
>>>> Host -> HD or SSD (independent) with sparse-mode image
>>>> Guest -> Virtual SSD (to signal discards)
>>>>
>>>>
>>>> El 5/4/19 a les 16:01, Pascal ha escrit:
>>>>> hello,
>>>>>
>>>>> if I understand correctly, you want to study the possibility of
>>>>> recovering deleted files from an SSD disk: is that right ?
>>>>>
>>>>> regards, lacsaP.
>>>>>
>>>>> Le jeu. 4 avr. 2019 à 08:24, Narcis Garcia >>>> <mailto:informat...@actiu.net>> a écrit :
>>>>>
>>>>>  Is there a way to specify a disk to be detected as an SSD drive?
>>>>>
>>>>>  Once reached this, I want to look for the possibility to recover
>>>>> host
>>>>>  space when a guest discards disk image blocks, and this image is
>>>>> RAW
>>>>>  format and sparse allocated file.
>>>>>
>>>>>  Thank you.
>>>>>
>>>
>>
>>

Re: [Qemu-discuss] Discard disk image holes for sparse shrink

[Narcis Garcia]

Thank you.

* I use RAW images because of it's easier to offline mount/chroot when
some issue happens.
* I call directly qemu instead of libvirt

I'll try to parse these parameters to a qemu-system call.


El 8/4/19 a les 22:03, Friedrich Oslage ha escrit:
> Yes.
> 
> You'll have to use the virtio-scsi driver, to my knowledge it's the only
> driver that supports block discards.
> 
> Quick example:
> 
> # create a new empty disk
> $ qemu-img create -f qcow2 disk.qcow2 10G
> 
> # check size, should only be a few kilobytes
> $ du -sh disk.qcow2
> 
> # add it to your vm
> $ virtsh edit your-vm
>   
>      detect_zeroes='unmap'/>
>     
>     
>     
>   
>   
>     
>   
> 
> # in your vm, format and mount it
> $ mkfs.ext4 /dev/sda
> $ mount /dev/sda /mnt/discardtest
> 
> # put some data on it
> $ dd if=/dev/urandom of=/mnt/discardtest/dummy.bin bs=1M count=1000
> $ sync
> 
> # on host, check size...it should be about 1GB
> $ du -sh disk.qcow2
> 
> # in vm, delete file and trim it
> $ rm /mnt/discardtest/dummy.bin
> $ sync
> $ fstrim /mnt/discardtest
> 
> # on host, check size...should only be a few megabytes
> $ du -sh disk.qcow2
> 
> 
> It works with other guest OSes as well, for Windows you just use the
> Optimize-Volume cmdlets instead of fstrim.
> 
> You also don't have to use qcow2 for backing. Anything that can handle
> discards will do, including sparse files.
> 
> 
> My advice, however, would be to use qcow2, since sparse files don't work
> particularly well. Executing the example above would leave you with
> about 300MB at the end instead of less than 10MB.
> 
> Regards
> Friedrich
> 
> On 4/5/19 4:04 PM, Narcis Garcia wrote:
>> No; I want to study the possibility of recovering allocated blocs of
>> host filesystem when guest filesystem removes its files (unallocates its
>> blocks).
>> Host -> HD or SSD (independent) with sparse-mode image
>> Guest -> Virtual SSD (to signal discards)
>>
>>
>> El 5/4/19 a les 16:01, Pascal ha escrit:
>>> hello,
>>>
>>> if I understand correctly, you want to study the possibility of
>>> recovering deleted files from an SSD disk: is that right ?
>>>
>>> regards, lacsaP.
>>>
>>> Le jeu. 4 avr. 2019 à 08:24, Narcis Garcia >> <mailto:informat...@actiu.net>> a écrit :
>>>
>>>  Is there a way to specify a disk to be detected as an SSD drive?
>>>
>>>  Once reached this, I want to look for the possibility to recover
>>> host
>>>  space when a guest discards disk image blocks, and this image is
>>> RAW
>>>  format and sparse allocated file.
>>>
>>>  Thank you.
>>>
> 

Re: [Qemu-discuss] Discard disk image holes for sparse shrink

[Narcis Garcia]

No; I want to study the possibility of recovering allocated blocs of
host filesystem when guest filesystem removes its files (unallocates its
blocks).
Host -> HD or SSD (independent) with sparse-mode image
Guest -> Virtual SSD (to signal discards)


El 5/4/19 a les 16:01, Pascal ha escrit:
> hello,
> 
> if I understand correctly, you want to study the possibility of
> recovering deleted files from an SSD disk: is that right ?
> 
> regards, lacsaP.
> 
> Le jeu. 4 avr. 2019 à 08:24, Narcis Garcia  <mailto:informat...@actiu.net>> a écrit :
> 
> Is there a way to specify a disk to be detected as an SSD drive?
> 
> Once reached this, I want to look for the possibility to recover host
> space when a guest discards disk image blocks, and this image is RAW
> format and sparse allocated file.
> 
> Thank you.
> 

[Qemu-discuss] Discard disk image holes for sparse shrink

[Narcis Garcia]

Is there a way to specify a disk to be detected as an SSD drive?

Once reached this, I want to look for the possibility to recover host
space when a guest discards disk image blocks, and this image is RAW
format and sparse allocated file.

Thank you.

Re: [Qemu-discuss] QtEmu 2.0 - GUI for QEMU

[Narcis Garcia]

Thanks for your time.


El 30/1/19 a les 12:43, Sergio Carlavilla ha escrit:
> Hi,
> 
> I'm proud to announce the release (well, the release happen a month ago) 2.0 
> of QtEmu
> 
> With QtEmu 2.0 I made a complete rewrite from scrath of QtEmu with Qt 5 
> support.
> 
> The highlight of the release:
> - Support of GNU/Linux, FreeBSD and Windows.
> - Support of QEMU 2.x and 3.x
> - Rewritten in Qt5
> - Support for Xorg and Wayland
> - New machine wizard
> 
> Repository: https://gitlab.com/qtemu/gui
> 
> If you have any sugestion, please contact me!
> 
> Bye and thanks for your time.
> 

[Qemu-discuss] From -usbdevice host: to -device usb-host,

[Narcis Garcia]

In environments with Qemu 2.8.1 I use:
qemu... -usbdevice host:046d:08b2

In environments with newer versions... Should I specify with this syntax?
qemu... -device usb-host,046d:08b2
(comma and vendor:product)

?

Thank you.

Re: [Qemu-discuss] Qemu Window size

[Narcis Garcia]

Which Qemu syntax are you using exactly for this virtual machine?
Qemu version?
Host operating system and version?
Guest operating system and version


El 22/10/18 a les 12:43, Peter Fodrek ml ha escrit:
> Dear Qemu experts,
> 
> We are using extreme old  CAD/CAM  DOS based program with 4:3 display radio, 
> but on new MS Windows  machine with 16:9/16:10 display ratio. As a result  
> squares are displayed as rectangles and circles as ellipses. 
> 
> I was missed to find out  window size/geometry  parameter  for Qemu manual.
> 
> Is anyone able to send me  what I missed to find out or possibly agree that 
> this is not possible, please?
> 
> I look forward hearing from you
> 
> Yours faithfully
> 
> Peter Fodrek
> 
> 
> 
> 
> 
> 
> 

Re: [Qemu-discuss] Can't access network: XP guest, Solaris host

[Narcis Garcia]

I had same problem here with MSIE and its libraries for third party
applications, but now I've tested one and it's browsing*. I don't know
if it's due to be IE8 now instead of IE6.

Host: Debian 9 with Qemu 2.8.1
Guest: Windows XP Pro SP3 with "Windows Internet Explorer" 8

$ qemu-system-x86_64 -cpu host -m 1024 -device rtl8139,netdev=net0
-netdev user,id=net0 -enable-kvm -boot c -drive
"file=windowsxp-pro.img,media=disk,index=0"


(*) Except some sites such as duckduckgo.com or wikipedia.org but I can
reach mozilla.org to download a fully working browser.


El 31/08/18 a les 19:13, Michele Denber ha escrit:
> I built qemu 2.12.0 on a Sun/Oracle M3000 SPARC64 running Solaris
> 10U11.  I was able to start up a Window XP guest but not matter what I
> try, I can't get XP to talk to the Internet in user mode networking. 
> Telnet reports "connect failed" to any IP and IE is unable to connect to
> anything either by name or by IP.  XP's Control Panel shows the emulated
> Ethernet card as present and TCP is set up.  The guest's LAN status
> reports 262 packets sent and 4 received at the moment.
> 
> I'm starting it with:
> 
> ./qemu-system-x86_64 -m 2047 -boot d  -usb -device usb-tablet  -smp 3
> -netdev user,id=n0,net=192.168.0.0/24 -device rtl8139,netdev=n0 -hda 
> /bkpool/qemuimages/XP.img -cdrom /bkpool/qemuimages/xp.iso &
> 
> My host has a static IP at 192.168.0.20 and I set the guest's IP to
> 192.168.0.21 inside XP.  A LAN scan shows the Sun's IP present but not
> the qemu guest.  I've read all the documentation several times but still
> don't get it.  What am I doing wrong?
> 
>     - Michele
> 

Re: [Qemu-discuss] Cannot ssh into a VM when using launching qemu with hostfwd

[Narcis Garcia]

I use the complete syntax including listening address (localhost here):

user,hostfwd=tcp:127.0.0.1:10022-:22


El 30/08/18 a les 22:12, Kevin Wilson ha escrit:
> Hello,
> 
> I am using qemu version 2.11.1 on Ubuntu 18.04
> 
> I am trying to launch a VM and ssh into it without using tap devices
> and iptables.
> 
> When I try to use "-redir" I get a message that it is deprecated.
> 
> So I tried using the hostfwd option, according to the man page.
> 
> This is how I launched qemu:
> 
> /usr/bin/qemu-system-x86_64 -name us-vhost-vm1 \
> -cpu host -enable-kvm -m 2048 -object
> memory-backend-file,id=mem,size=2048M,mem-path=/mnt/huge,share=on
> -numa node,memdev=mem -mem-prealloc \
> -smp cores=2,sockets=1 -drive file=$vm_img,index=0,media=disk,format=$FORMAT \
> -netdev user,id=myid,hostfwd=tcp:10022-:22 -device
> rtl8139,netdev=myid,id=net0,mac=00:00:00:00:10:01
> 
> The vm_img I am using is an Ubuntu 16.04 qcow2 image.
> 
> The VM starts, and when I run ifconfig -a inside it I do eth0, which
> is an rtl8139 device (as ethtool -i eth0 shows).
> Also on the VM (guest), both the PermitRootLogin without-password
> and PermitRootLogin in /etc/ssh/sshd_config were set to yes, and I can
> ssh 127.0.0.1 in the guest itself.
> 
> But when I try to ssh from the host with "ssh localhost -p 10022",  I
> cannot connect, it simply hangs endlessly,  and does not prompt me
> for user.
> 
> What can be the reason for that it does not work for me ?
> 
> Regards,
> Kevin
> 

Re: [Qemu-discuss] Monitor mode with -display curses

[Narcis Garcia]

Are you both talking about Qemu console?
...or a guest console?


El 21/08/18 a les 21:44, Alberto Garcia ha escrit:
> On Tue, Aug 21, 2018 at 09:17:39PM +0200, Vincenzo Romano wrote:
>> But I would then get "just" the monitor. Not the console.
>> I need both.
>> Thanks anyway.
> 
> I'm not sure if I'm following you... if you have '-display curses'
> you'll already have the guest console on the terminal emulator where
> you're running QEMU.
> 
> If you want to have both the console and the monitor in the same place
> you can try with -nographic. This way you have the guest serial port
> and the monitor in the same place and you can switch between them
> (press 'C-a h' for help). You need to pass console=ttyS0 to the guest
> kernel.
> 
> Berto
> 

Re: [Qemu-discuss] Wireless TAP Networking on a Windows host

[Narcis Garcia]

I guess you could put wireless device and VMs at same bridge.

br0 {wlan0, tap0}


El 08/08/18 a les 23:54, user 96710 ha escrit:
>  I'm fairly new to Qemu and virtualization, I hope you can give me some
> advice.
> 
> Afaik, the main difference between SLIRP and TAP is that TAP is more
> performant, however TAP needs either a bridge or a NAT set up for it to
> work. I've successfully set up a bridge and I have connection in my guests,
> but only at home where I can connect my laptop to the Ethernet. The bridge
> stops working on wi-fi. So when I have a wireless connection I would need
> to set up NAT but I have no idea how that is done. Any source that can help
> me with that? Or is there an alternative way?
> 
> Thanks.
>