Yeah I might go QEMU eventually too. The only reason I was going for vmware player was because at the time I wanted to get weebshin impact to run, but since that’s pretty much dead already anyway it’s not a necessity anymore. It just kinda bothered me today and I wanted to try it again (also need a Windows VM for something else, doesn’t need GPU acceleration tho).
1 Like
I used to use virtualbox occasionaly back when I used Windows, and it was pretty solid.
Didn’t really try vmware-player.
On Linux, I started from scratch with virt-manager for the whole pass through gaming, and that was some fun poking at it.
And then I remember that virtualbox was from/brought by Oracle, not Vmware.
I used virtualbox on Windows too because it was an easy solution (also didn’t know VMware was sort of free at the time), but both VirtualBox and qemu don’t have good working hardware GPU acceleration from what I read, while vmware-player has… supposedly.
Anyway tho, installed VirtualBox and VM didn’t start due to missing Kernel module so… gonna reboot.
OK so I don’t seem to be able to create a QEMU VM through virt-manager, gone through the wizard and at the end it tells me Unable to complete install: 'unsupported configuration: 'directory' storage format is not directly supported by QEMU, use 'dir' disk type instead'. I can’t even select directory or dir anywhere…
So back to VirtualBox… When starting the VM I get AMD-V is disabled in the BIOS (or by the host OS) (VERR_SVM_DISABLED).. I’m confused cause I’m fairly sure that is enabled in BIOS… gonna check.
1 Like
I presume the test in QEMU you just chose to let it crfeate a new storage backing, rather than recreate an existing machine?
The AMD-V thing is odd, but I guess easy enough to check the grub condition/ uefi option
Yes created a new one since I never had a QEMU image to begin with.
Back from my tour through the BIOS and unless the option is in a really obscure place I can’t even disable Virtualisation if I wanted to… or enable for that matter. But I’m fairly sure I ran a Linux VM back on Windows so that shouldn’t be an issue.
As for grub, I’m not sure where to start but my kernel parameters don’t have anything Virtualisation related from what I can tell:
set default_kernelopts="root=/dev/mapper/fedora_localhost--live-root ro resume=/dev/mapper/fedora_localhost--live-swap rd.lvm.lv=fedora_localhost-live/root rd.lvm.lv=fedora_localhost-live/swap rhgb quiet "
On a sidenote: a bit odd that Vbox is the only one of the 3 that is complaining about it, would think all 3 had such checks in place…
1 Like
That is odd, and if that was the problem, I guess the others should have errored out with it.
It appears that AMD-V might also be called SVM mode, which you probably came across, and is probably already set.
it seems some people used
dmesg | grep “AMD-V”
to check for iommu groups, which came up with a bunch of iommu lines. If you have lines like it, then I’d say it must be enabled, and that tree is the wrong one to bark at?
(I had to ctl-f to find then AMD-V bit, which had a bunch of AMD-Vi listings in the OP’s section. I understand this link is for QEMU, but that one check should be agnostic VFIO in 2020 Fedora 32 - An alternate route )
1 Like
Hm, tried that:
[ 0.665140] pci 0000:00:00.2: AMD-Vi: IOMMU performance counters supported
[...]
[ 0.668051] pci 0000:00:00.2: AMD-Vi: Found IOMMU cap 0x40
[ 0.668053] pci 0000:00:00.2: AMD-Vi: Extended features (0xf77ef22294ada):
[ 0.668055] AMD-Vi: Interrupt remapping enabled
[ 0.668055] AMD-Vi: Virtual APIC enabled
[ 0.668155] AMD-Vi: Lazy IO/TLB flushing enabled
I guess that means yes?
1 Like
yeah, I get that output too (more or less)
I gotta hit the hay, but good luck
I can’t get sudo to use my aliases in zsh. The 3 solutions I’ve found online don’t work:
alias sudo='sudo 'alias sudo='nocorrect sudo '-
Defaults env_keep += "HOME"insudoers(although this does work forsudo -ssince it runs my.zshrcinstead of looking in/root)
Most importantly, I alias vi to nvim and I am tired for getting:
% sudo vi
sudo: vi: command not found
Try to use the update-alternatives system instead of aliases. Shell aliases only work for interactive shells.
On my Ubuntu vi has an alternatives entry already. update-alternatives --display vi shows all the options. You can choose one with update-alternatives --config vi. If your nvim isn’t in there, then you’re going to need to add a new alternative of your own. Read the manpage because I forget the details of how to do that.
1 Like
% yay -Ss update-alternatives
%
Every time I sudo nvim something, a folder literally called $XDG_CACHE_HOME appears in my home folder. Wtf?
That means that the code does not implement the Freedesktop standard of using the ~/cache directory.
Report it or add it and submit the fix
**edit.
~/cache is supposed to be ~/.cache
1 Like
I know what the variable is for and I figure maybe someone used single quotes instead of double quotes somewhere (I am using a few plugins), but why would it only happen when I use sudo?
I guess I’ll turn off some plugins and see if it goes away.
Could be that one of the pluggins does not deal with privilege escalation well.
If you were to do a sudo -i and then try, if you get the same thing in the root’s home, then you might have found a legitimate bug.
1 Like
You can always make your own symlinks in /usr/bin, /usr/local/bin or similar locations. Just make sure it appears earlier in PATH than the actual vi. You may need to rename vi to vi.basic or whatever.
1 Like
Yeah, I’ll do that as last resort. I don’t actually have vanilla vi installed at all so there wouldn’t be a conflict.
My problem is that after an install of Arch and cinnamon I am unable to configure an Xorg.conf.new. Also if I startx (after failing to create said Xorg.conf.new) There are letters and icons missing on the toolbar and menus
I’m not sure this is a problem, just a tad weird?
It’s caching so much that it uses swap. I assume it’s normal?
Is there any way to see what it’s caching?
It Linux Mint 20.
Would suggest you check your swappiness threshold:
cat /proc/sys/vm/swappiness
A value of 60 would mean your OS will start slowly moving less used cache to swap as soon as the memory pressure exceeds 40%. 60 Is the default for most distro’s. 60 Is probably fine for most - especially on most general servers. Reducing your swappiness will cause your system not to start swapping so early - but when it does it will be more aggressive and the noticeable slowdown on IO will be harsher.
If you have a very fast SSD and you feel the chances of you running out of RAM is low then you can reduce this to something like 10 or 5. If you do this on a conventional HDD reducing this value will probably increase the responsiveness of your system but when the the system does have to swap your PC will become very unresponsive.
The benefit of the default at 60 is that even though it starts swapping early - it doesn’t do so aggressively and in the event that you suddenly open a large program that requires o lot of memory it can open quickly because space have been already cleared in RAM.
At the end the best value will depend on your setup and how you run your software. I will say this - swapping isn’t necessarily a bad thing.
1 Like