сряда, 13 юли 2016 г.

Virtual manager freezing

This seems to be universal problem. During the use of the virtual machine (I use qemu), it periodically freezes. The problem is not observed with ssh, so obviously, the problem is not in the virtual machine itself, but as suggested in the video acceleration or something.
The suggestion was to do
$vblank_mode=0 /usr/bin/virt-manager
I tried it, it still freezes.
Second attempt is the solution given here.
IT tells you to do (rc.local should have $chmod a+rx rx.local):
 sudo nano /etc/rc.local

if test -f /sys/kernel/mm/transparent_hugepage/enabled; then
   echo never > /sys/kernel/mm/transparent_hugepage/enabled
fi
if test -f /sys/kernel/mm/transparent_hugepage/defrag; then
   echo never > /sys/kernel/mm/transparent_hugepage/defrag
fi
exit 0

The problem is that my system is using systemd so the rc.local is not even being read.
So to enable it I've found this:
Create a file /etc/systemd/system/rc-local.service with the following contents:
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU General Public License as published by
#  the Free Software Foundation; either version 2 of the License, or
#  (at your option) any later version.

[Unit]
Description=/etc/rc.local Compatibility
ConditionPathExists=/etc/rc.local

[Service]
Type=forking
ExecStart=/etc/rc.local start
TimeoutSec=0
StandardOutput=tty
RemainAfterExit=yes
SysVStartPriority=99
 
[Install]
WantedBy=multi-user.target
  
Then, just run systemctl enable rc-local.service as root to enable it.
You can also test it/run it now by running systemctl start rc-local.service

I still don't know if it works, because I have to test the virtual machine and systemctl enable gives an error: "sudo systemctl enable rc-local.service
The unit files have no [Install] section. They are not meant to be enabled
using systemctl."
Ok, after revising rc-local.service to contain the [Install] section, everything works like a charm.
And guess what, my virtual machine is finally not freezing. I've been using it for hours now and it seems to work flawlessly. Yay!

сряда, 6 юли 2016 г.

Primusrun not working on Sabayon (Gentoo)

Recently I got this odd error when trying to start primusrun:
"primus: fatal: failed to load any of the libraries: /usr/lib64/opengl/nvidia/lib/libGL.so.1:/usr/lib32/opengl/nvidia/lib/libGL.so.1:/usr/lib/opengl/nvidia/lib/libGL.so.1
/usr/lib64/opengl/nvidia/lib/libGL.so.1: wrong ELF class: ELFCLASS64
libGLX.so.0: cannot open shared object file: No such file or directory
/usr/lib/opengl/nvidia/lib/libGL.so.1: wrong ELF class: ELFCLASS64"

Obviously, this is not a critical error, but it prevented me from using my beloved nvidia card so I had to fix it. It turned out, it might be a problem of the nvidia driver in Sabayon being compiled without a -compat flag. I'm not that sure if that's the case, but anyway, Steam wasn't working and that was a pain.
I still don't know how to fix this, but I found a work around it. It is to run:
$ vblank_mode=0 optirun -b primus steam
Oddly enough, I discovered that this make a damaric change in the performance.
For example:
$glxspheres
Polygons in scene: 62464 (61 spheres * 1024 polys/spheres)
Visual ID of window: 0xb4
Context is Direct
OpenGL Renderer: Mesa DRI Intel(R) Haswell Mobile
60.719441 frames/sec - 67.762896 Mpixels/sec

$optirun glxspheres
Polygons in scene: 62464 (61 spheres * 1024 polys/spheres)
Visual ID of window: 0x20
Context is Direct
OpenGL Renderer: GeForce GT 750M/PCIe/SSE2
270.979545 frames/sec - 302.413172 Mpixels/sec

$ vblank_mode=0 optirun -b primus glxspheres
Polygons in scene: 62464 (61 spheres * 1024 polys/spheres)
ATTENTION: default value of option vblank_mode overridden by environment.
ATTENTION: default value of option vblank_mode overridden by environment.
Visual ID of window: 0xb4
Context is Direct
OpenGL Renderer: GeForce GT 750M/PCIe/SSE2
ATTENTION: default value of option vblank_mode overridden by environment.
ATTENTION: default value of option vblank_mode overridden by environment.
317.778206 frames/sec - 354.640478 Mpixels/sec

Surprising, huh? I didn't realize the nvidia makes that much difference. Nice.

P.S. Btw, the packages which I reinstalled were:
bumblebee bumblebee-nvidia virtualgl linux-headers libglw primus
And yeah, another thing, how to restart bumblebee:
systemctl enable bumblebeed.service
systemctl start bumblebeed.service

четвъртък, 30 юни 2016 г.

How to resize partition in virtual machine

First, find the directory where your  *.qcow2 file resides.
$ ls -la *.qcow2
should show the file you're looking for
Then use qemu to resize the file.
$sudo qemu-img resize X*.qcow2 +10GB
will add 10GB to your file. Make sure not to add more GBs than you'd like the file to have, because then you cannot shrink it back to less. I found it out the hard way :)
All this is done with the virtual machine turned off.
Then comes the complicated part.
You need to convince you're virtual OS that it has more space. So this is what I did (following source):
So start your virtual machine, start a terminal and work there.
 First, check your current partition table:
$df -h
and make sure you're working on the correct partition. In my case, I had to work on /dev/sda.
Then delete the last partition on /dev/sda
$su
$fdisk /dev/sda
$p
to print the current partition table.
I had
/dev/sda1 -> primary, root partition
/dev/sda2 -> extended
/dev/sda5 -> SWAP.
Obviously different situation from the instructions, so I decided to delete /dev/sda2 and work from there.
So to delete /dev/sda2
$d
$2
$w
This finalizes the destruction.
Then I had the space in the end of my virtual hard empty. I created a new partition
$fdisk /dev/sda
$n
$p
all else was the default ones, just make sure the final cylinder is indeed the final of the "disk", because for me, the first time, it wasn't.
After that you finish with $w and exit.
Then you need to reboot to finalize.
$sudo reboot
In the better case, you could use
$resize2fs /dev/sda1

to expand your root hard. It didn't work for me, so I started gparted
$sudo gparted
and deleted the new partition, because resize2fs gave me some error with cylinders.
After deleting, I created a new ext4 partition and I hit "Apply". The idea was to fix the error I got previously.
Then when it was ready, I deleted the new partition, clicked on /dev/sda1 and told it to resize to the end (or almost) of the now unformatted region. I left little space in the end which I formatted as swap, just so that I have some. Then I clicked Apply and gparted did the magic.
Now I have 20GB bigger virtual hard, which is 10GB more than I planned for, but still, it all seems to work fine.
Yay!