Description of problem: On a Mageia v7 x86-64 Host, installing Mageia v7 beta1 classical .iso inside virtualbox is very slow. Tested installing both x86-64 and i586 ISOs with several configurations including the default Plasma5 one. Installing a https://en.wikipedia.org/wiki/Manjaro_Linux from .iso works quickly enough on the same host and vbox as well. My system is: An Intel Core i3 CPU (x86-64). 8 GB of RAM. Intel Corporation Sandy Bridge Integrated Graphics Controller (rev 09) A 2 TB hard-disk. A 21″ Wide LCD Screen by LG. Intel Corporation Cougar Point High Definition Audio Controller. Intel Corporation 82579V Gigabit Network Connection. Note that the system has been thru quite a few urpmi upgrades and accumulated some cruft and churn, so maybe there is a magic incantation to fix it. The host system in general works fine, though there are some delays in urpmi/etc.
Current beta1 classical iso is broken, and a new isos are coming... just monitor the qa list for the announcement
CC: (none) => tmb
(In reply to Thomas Backlund from comment #1) > Current beta1 classical iso is broken, and a new isos are coming... just > monitor the qa list for the announcement @ Shlomi in reply to your question in dev channel: Martin wrote his mail about the round 4 ISOs 45 minutes after tmb's comment, so yes, those are the new ISOs tmb wrote about :-)
Assignee: bugsquad => isobuildCC: (none) => marja11
Keywords: (none) => 7beta1
I've just timed an install of the default Plasma desktop and applications using the round 4 Mageia-7-beta1-x86_64 ISO. Time from clicking on the Next button in the Language Selection screen to reaching the Congratulations screen was just over 5 minutes. My host system is Intel Core i5-3550 (Ivy Bridge) 16GB RAM 300GB SSD Mageia 6 x86_64 My guest system is configured for 2 processors, 4GB RAM, hardware virtualization enabled, 20GB VDI storage. (using a SSD does make a big difference)
CC: (none) => mageia
Using the latest x86-64 classical ISO ( b1b74b032167db9da98a6171c8ab1f0997223f711582e2da9c5b6e52b89acfcd29739163a0a9f8a4b188e48813ac80f1ccb9064e1f3413b318ec4b4ac09ada74 ) it is still too time consuming here. Some possible leads: 1. After pressing the details, I see that often the package installer gets stuck on one package and it takes it several minutes to install it. 2. While this is happening, iotop on the host shows disk writes of about 300 KB/s . htop shows some CPU activity.
It's time to advertise using virt-manager instead of VirtualBox... else at the prompt time, you may workaround slow VBox by typing "linux divider=0" instead of just <enter>
CC: (none) => thierry.vignaud
That should be divider=10, not divider=0.
CC: (none) => davidwhodgins
(In reply to Dave Hodgins from comment #6) > That should be divider=10, not divider=0. Hi! That doesn't seem to help with my issue here: installation is too time consuming. I used it in the vbox vm bootup. I will try virt-manager next but last time I tried its GUI was incomplete and counterintuitive.
(In reply to Thierry Vignaud from comment #5) > It's time to advertise using virt-manager instead of VirtualBox... > > else at the prompt time, you may workaround slow VBox by typing "linux > divider=0" instead of just <enter> I checked now and an installation of the mga7 .iso on virt-manager exhibits the same problem.
Some steps you can take to try and speed things up. As per https://rudd-o.com/linux-and-free-software/tales-from-responsivenessland-why-linux-feels-slow-and-how-to-fix-that Create the file /etc/sysctl.d/tales.conf on the host with the lines between the following dashed lines, and then reboot the host. --------------------- # Stop applications from being swapped to disk vm.swappiness=1 # Don't shrink the inode cache vm.vfs_cache_pressure=50 --------------------- The above should reduce or even eliminate swap usage on the host. On my 16GB ram host, I've had 6 vb guests running with 2GB ram for each each, and zero swap usage. In the vb settings for the guest: - On the Display tab, increase video ram to the max (128MB). - On the storage tab, delete the existing virtual drive and create a new one ensuring the storage on the physical disk is set to use fixed size instead of the default of dynamically allocated. While this takes more space on the host's hard drive, it stops vb from having to get the host to add more space every time a new block is written in the guest. This has a very noticeable impact during installs. BTW, what the divider=10 option does is cause the desktop or desktop586 kernel to only look for things like mouse movements 100 times per second instead of 1000 times per second. In vb guests I normally install the server kernel which is already set to 100HZ. In theory that can make the mouse seem a little jerky, but I've never seen any problems with it. That info is from bug 44
Hi Dave, (In reply to Dave Hodgins from comment #9) > Some steps you can take to try and speed things up. As per > https://rudd-o.com/linux-and-free-software/tales-from-responsivenessland-why- > linux-feels-slow-and-how-to-fix-that > Create the file /etc/sysctl.d/tales.conf on the host with the lines between > the following dashed lines, and then reboot the host. > --------------------- > # Stop applications from being swapped to disk > vm.swappiness=1 > # Don't shrink the inode cache > vm.vfs_cache_pressure=50 > --------------------- > > The above should reduce or even eliminate swap usage on the host. On my 16GB > ram host, I've had 6 vb guests running with 2GB ram for each each, and zero > swap usage. > > In the vb settings for the guest: > - On the Display tab, increase video ram to the max (128MB). > - On the storage tab, delete the existing virtual drive and create a new one > ensuring the storage on the physical disk is set to use fixed size instead > of the default of dynamically allocated. While this takes more space on the > host's hard drive, it stops vb from having to get the host to add more space > every time a new block is written in the guest. This has a very noticeable > impact during installs. > > BTW, what the divider=10 option does is cause the desktop or desktop586 > kernel > to only look for things like mouse movements 100 times per second instead of > 1000 times per second. In vb guests I normally install the server kernel > which > is already set to 100HZ. In theory that can make the mouse seem a little > jerky, > but I've never seen any problems with it. That info is from bug 44 thanks! I tried all that but installing the mageia ISO is still slow here and , like I said, manjaro was installed quickly enough even before all that.
(In reply to Shlomi Fish from comment #8) > (In reply to Thierry Vignaud from comment #5) > > It's time to advertise using virt-manager instead of VirtualBox... > > > > else at the prompt time, you may workaround slow VBox by typing "linux > > divider=0" instead of just <enter> > > I checked now and an installation of the mga7 .iso on virt-manager exhibits > the same problem. Did you make sure it used virtio for everything (storage, network, ...)?
(In reply to Thierry Vignaud from comment #11) > (In reply to Shlomi Fish from comment #8) > > (In reply to Thierry Vignaud from comment #5) > > > It's time to advertise using virt-manager instead of VirtualBox... > > > > > > else at the prompt time, you may workaround slow VBox by typing "linux > > > divider=0" instead of just <enter> > > > > I checked now and an installation of the mga7 .iso on virt-manager exhibits > > the same problem. > > Did you make sure it used virtio for everything (storage, network, ...)? Hi! Sorry for the late reply but https://duckduckgo.com/?q=virtio+virt-manager&atb=v140-1&ia=web refers to https://wiki.libvirt.org/page/Virtio which implies that the OS was already installed before virtio is enabled. So how do I enable virtio during the installation? Regards, Shlomi.
Sorry form getting this from ashes, but, by default for what unknown reason, virtualbox does not use host I/O cache. To activate it and accelerate I/O on hard-disk, you need to open you VM's Settings > Click on "Storage" > Check "Use Host I/O Cache". This considerably accelerate Mageia installation and I/O on harddrive within virtualbox. @Shlomi, Are you still be affected by this? Please give us some feedback.
Severity: normal => minorTarget Milestone: --- => Mageia 8Keywords: 7beta1 => feedbackStatus: NEW => ASSIGNEDCC: (none) => ouaurelienPriority: Normal => LowAssignee: isobuild => ouaurelienSummary: On a Mageia v7 x86-64 Host, installing Mageia v7 beta1 classical .iso inside virtualbox is very slow. => On a Mageia x86-64 Host, installing whatever Linux distribution inside Oracle Virtualbox is very slow.
Reporter, could you please reply to the previous question? If you don't reply within two weeks from now, I will have to close this bug as WORKSOME as performance is OK my current Mageia 8 Cauldron system. Thank you. Configuration used: UEFI Host x86_86 Intel Core i5 6600K 3.5Ghz, Intel VT-d activated 16 Go RAM System is installed on NVME SSD Magiea Cauldron 8 NVIDIA nonfree drivers M7 Client and M8 Cauldron Client install are OK, run fine BUT option in VM's Settings > Click on "Storage" > Check "Use Host I/O Cache" must be set manually. Found same behavior on openSUSE, Ubuntu Host.
Keywords: (none) => NEEDINFO
To resolve this: Option in VM's Settings > Click on "Storage" > Check "Use Host I/O Cache" must be set. By default, it is deactivated. We have not received feedback to the information we have requested above, we will assume the problem was not reproducible, or has been fixed in one of the updates we have released for the reporter's distribution. Users who have experienced this problem are encouraged to upgrade to the latest update of their distribution, and if this issue turns out to still be reproducible in the latest update, please reopen this bug with additional information. Closing as OLD.
Status: ASSIGNED => RESOLVEDKeywords: NEEDINFO, feedback => (none)Priority: Low => NormalResolution: (none) => OLDTarget Milestone: Mageia 8 => ---Severity: minor => normal