default memory parameter too small on x86_64 today

[johann peyrard]

Launching a centos74 iso VM today does not work anymore on x86_64 without increasing the size of the memory parameter. For example with this command :

$ /opt/qemu-3.0.0/bin/qemu-system-x86_64 --curses -enable-kvm -drive file=file.dd,index=0,media=disk -drive file=centos-x86_64.iso,index=1,media=cdrom

[ 3.047614] Failed to execute /init
[ 3.048315] Kernel panic - not syncing: No init found. Try passing init= option to kernel. See Linux Documentation/init.txt for guidance.
[ 3.049258] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.0-693.21.1.el7.x86

Increasing the size from the default 128MiB to 512MiB let the VM works without problem.
So, ok, it's not a qemu problem, it's more a "User problem" and interface problem for me.
But it push me in the end to launch VirtualBox instead of qemu, because the default parameter does not work anymore... And I had no time to investigate why it does not work because the message is not visible.
Debian iso with the same command line for example show a message to tell me that there is not enough memory, so it help me to track the real issue behind.

But... In the end, I think today, the default memory parameter on x86_64 is too small and it can lead some people like me to switch to VirtualBox.
VirtualBox, in the wizard is set by default to 4MiB Ram size, which tell you... Ok I need to put more. And, you know that 4MiB is not enough in the end.

Regards,

Johann

[Daniel Berrange (berrange)]

IMHO, if achieving ease of use comparable to VirtualBox is your benchmark target, then launching QEMU directly is really the wrong way to approach things. QEMU is a very low level piece of infrastructure not a complete end user desktop solution. For that it is better to look at using an application such as virt-manager, or GNOME Boxes. These provide higher level solution over QEMU and do smart things during installation, using libosinfo to automatically determine the best memory, disk, network, etc settings for each particular guest OS rather than relying on some hardcoded defaults.

That said all said, I don't rule out that we could change our memory defaults, but picking an optimal value is hard. Even 500 MB is considered to be unsupported from a RHEL-7 pov - the documented minimum for RHEL-7 is 1 GB per vCPU. The installer is quite likely to crash with 500 MB depending on what options you select durin intsall.

[johann peyrard (jpeyrard)]

Hi Daniel,

I use qemu for a long time now so for me it's easier to use than any other
solution.
I think I began to use as my preffered VM tool in 2003.
But, I still think that keeping this value at 128MB is low today.
Maybe in this case reducing this value to make it crash is another option,
for example 4MB.
Or just print a message if it is an iso file that ramsize is set to 128MB,
maybe you need more ram.
It is just quick thought, some OS will handle this correctly, some os won't.
For example in my example I say that debian say it explicitely in the 80x25
screen in red.

Today I see all people around me are moving to VirtualBox because it just
work out of the box.
And Qemu is near to work out of the box with 2 or 3 parameter in the end.
Definitely I have a prefference for Qemu, because it's more "shell
friendly".

It was just my quick thought about it.

Johann

Le mer. 5 déc. 2018 à 12:31, Daniel Berrange <email address hidden> a
écrit :

> IMHO, if achieving ease of use comparable to VirtualBox is your
> benchmark target, then launching QEMU directly is really the wrong way
> to approach things. QEMU is a very low level piece of infrastructure not
> a complete end user desktop solution. For that it is better to look at
> using an application such as virt-manager, or GNOME Boxes. These provide
> higher level solution over QEMU and do smart things during installation,
> using libosinfo to automatically determine the best memory, disk,
> network, etc settings for each particular guest OS rather than relying
> on some hardcoded defaults.
>
> That said all said, I don't rule out that we could change our memory
> defaults, but picking an optimal value is hard. Even 500 MB is
> considered to be unsupported from a RHEL-7 pov - the documented minimum
> for RHEL-7 is 1 GB per vCPU. The installer is quite likely to crash with
> 500 MB depending on what options you select durin intsall.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1801933
>
> Title:
> default memory parameter too small on x86_64 today
>
> Status in QEMU:
> New
>
> Bug description:
> Launching a centos74 iso VM today does not work anymore on x86_64
> without increasing the size of the memory parameter. For example with
> this command :
>
> $ /opt/qemu-3.0.0/bin/qemu-system-x86_64 --curses -enable-kvm -drive
> file=file.dd,index=0,media=disk -drive file=centos-
> x86_64.iso,index=1,media=cdrom
>
> [ 3.047614] Failed to execute /init
> [ 3.048315] Kernel panic - not syncing: No init found. Try passing
> init= option to kernel. See Linux Documentation/init.txt for guidance.
> [ 3.049258] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
> 3.10.0-693.21.1.el7.x86
>
> Increasing the size from the default 128MiB to 512MiB let the VM works
> without problem.
> So, ok, it's not a qemu problem, it's more a "User problem" and
> interface problem for me.
> But it push me in the end to launch VirtualBox instead of qemu, because
> the default parameter does not work anymore... And I had no time to
> investigate why it does not work because the message is not visible.
> Debian i...

[Thomas Huth (th-huth)]

The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience.

[Launchpad Janitor (janitor)]

[Expired for QEMU because there has been no activity for 60 days.]