2020-10-21
Keeping VMware Workstation VMs running when I quit from VMware
VMware over 'ssh -X' is surprisingly chatty even when iconified, to the tune of 200 KB/sec inbound. Maybe I need to investigate some remote desktop thing I can detach from and reattach to.
(I'm now keeping some VMs running full time.)
(The primary reason I'm keeping a VM up all the time right now is that it's our only Ubuntu 20.04 test machine and we need experience with that. As far as running an X GUI program like VMware over a DSL link goes, it works generally okay, although it's not great.)
To be specific, this is VMware Workstation Pro, which I still use because it's the best option for my specific needs (especially without rebuilding my office workstation's network configuration). I regularly need or at least want the full VMware GUI and the power it gives me, but if I keep it running (even without a running VM and iconified), it consistently uses up about 200 KB/sec of incoming ('down') bandwidth on my DSL link.
(Using nethogs confirmed
that the process responsible for the bandwidth was my 'ssh -X'.)
If you quit from the VMware Workstation GUI with running VMs, it will give you the option to keep them running in the 'background'. When I first tried this, they would abruptly be stopped later, so I thought my only option was to keep the GUI running. Just recently I discovered that I could keep them running if I quit out of the VMware GUI but didn't actually log out of my 'ssh -X' session. Having to keep my session logged in this way is a bit irritating (and has some limits) but at least it stops the bandwidth usage.
(Nohup'ing the vmware command when I ran it from the 'ssh -X'
session kept the VM running after I logged out, but then abruptly
shut it down when I logged back in and ran vmware again. This is
not a desirable property.)
But that's only half of the potential advantages of some sort of remote desktop thing. The other half is that it might let me deal with VMware rendering the consoles (or displays) of virtual machines at one pixel for one pixel resolution even though I'm using a HiDPI display. This is a reasonable decision for VMware to make, but it does have the effect of making both Linux text consoles and any GUI stuff rather small. I can see things and work with them if I have to, but it would be more comfortable if they were bigger.
VMware supports connecting to VM consoles with VNC, as I found out on Twitter, and some Linux clients support scaling up VNC sessions; specifically I've seen this work with Remmina. But it would be nicer if I ran all of the VMware GUI inside some remote desktop session where I could just scale all of it up on my side. Scaling up on my local desktop would also use a lot less bandwidth than running 'ssh -X' and having the VMware GUI scale up everything on the remote machine and push it over the link.
(I'm not sure I like the remote VMware console experience with Remmina, but my impressions of it right now are strongly coloured by how my freshly installed Fedora 32 test VM doesn't seem to want to usefully run Cinnamon. When I log in, either in the VNC client or in the VMware GUI, all I get is a black screen. Cinnamon claims to be running without problems but nothing is being displayed.)
PS: Although it's officially 'VMware', that has always looked wrong to me and I reflexively capitalize it as 'VMWare'. Sometimes I correct that in Wandering Thoughts entries, and sometimes not.
A mystery uncovered by Fedora 32 changing my default font
I upgraded my home machine to Fedora 32 earlier this week. Everything went smoothly, except that afterward various web pages looked just a little bit different in my Firefox. After poking around and finding a handy Firefox font related thing, I discovered that Fedora 32 had changed what the standard system 'serif', 'sans-serif' and 'monospace' font names mapped to from DejaVu (in Fedora 31) to Bitstream Vera (in Fedora 32). The two fonts are very close (DejaVu is a modification of Bitstream Vera), but apparently just far enough apart that I can tell the difference.
In theory this could all be controlled through Fontconfig. In practice my simple brute force fix was to remove the Bitstream Vera fonts on the grounds that I didn't need them and they aren't there on a standard Fedora 32 install. But afterward I started poking around the Fontconfig files in /etc/fonts/conf.d to see if I could spot why the change happened, and wound up more confused than before.
My office workstation is still on Fedora 31 and it is definitely
using the DejaVu fonts (you can tell with 'fc-match serif' and
so on). However, it has Bitstream Vera fonts installed, and both
my Fedora 31 and 32 machines have an /etc/fonts/conf.d/60-latin.conf
file that appears to specify that the Bitstream Vera fonts should
be preferred over the DejaVu versions:
<description>Set preferable fonts for Latin</description>
<alias>
<family>serif</family>
<prefer>
<family>Bitstream Vera Serif</family>
<family>DejaVu Serif</family>
<family>Times New Roman</family>
<family>Thorndale AMT</family>
[...]
Setting the magic $FC_DEBUG environment variable on my Fedora
31 machine (documented in fonts.conf) did
not provide any enlightenment; it may provide debugging, but it
doesn't make fc-match explain its decisions. Fedora 31 and 32 have
essentially the same version of Fontconfig (2.13.92-3.fc31 and
2.13.92-9.fc32 respectively), so that isn't a smoking gun either.
So, as has happened before, I started with a surprising change and have wound up with a mystery of why my Fedora 31 machines worked (and work) the way they did. As far as I can tell, the system fonts should have mapped to Bitstream Vera even on Fedora 31.
(I'm also left with the puzzle about why Fedora even seems to prefer Bitstream Vera over DejaVu, given that DejaVu was created to improve on Bitstream Vera and long ago Fedora switched to them. Bitstream Vera isn't even installed on normal from-scratch Fedora installs and hasn't been for some time, which may be part of why this bit of configuration has lingered on.)