Saturday, October 26, 2019

Virtualise a running legacy physical Linux server (P2V)

problem: You have a legacy physical Linux server, live in production, that you would like to virtualise (P2V) with near zero downtime?

My goal was to take a physical Linux P node running live-production and virtualise it. Primarily so the physical hardware could be repurposed as a hypervisor or retired. I didn't want to create and allocate multi terabyte disks that were present in the P partition table, nor have to use md raid in the V guest which the P node was using, because the target hypervisor (Proxmox 5) used ZoL/ZFS. I also wanted to mitigate downtime/reboots on the running P node as it was busy performing production tasks.

solution: I have documented the steps I took without using specific P2V tools

After researching multiple ways of solving this problem, I documented my steps on server fault.

There were multiple questions on the Stack Exchange network and some of the answered helped but there wasn't really an end to end guide on the process, at least not for my circumstances and goals. So after documenting and running my own steps, I posted the answer for others to use as a reference.

Check the answer on server fault for the details:

Once I had successfully V'ed the P node, and had the V node running in my Proxmox PVE lab, I also posted my steps for repurposing the P node as a Proxmox hypervisor. This was a little tricky but with tips from the Proxmox forum I was able to make a clean Proxmox install with native ZoL/ZFS via network booted rescue image on the Hetzner service provider.
It was then possible to take a backup of the V node and transfer it to the new hypervisor and restore it with qmrestore.

Everything worked as hoped in the end. In the journey I had refreshed on some Linux knowledge and picked up a few new techniques. I had successfully repurposed the P node as a hypervisor and had the legacy Linux node running as a V in the new hypervisor. All with near zero downtime to production.


Props to:
Various Q&A authors @ the Stack Exchange network.
Various post authors @ Proxmox forums.
The various wiki authors @ the Proxmox wiki page for Migration of servers to Proxmox VE.
I also cited some useful links in my answer on server fault.

Firefox instances using profiles are grouped in a single group

problem: Windows from separate Firefox instances using profiles are grouped in a single group on the taskbar 

Lets say you have 3 Firefox profiles (about:profiles), or 3 portable Firefox instances, and you have the separate instances all running at the same time. I had the issue that all the windows from the various profile instances were grouped into a single group on the task bar, and I could not find a way to un-group them.

Until recently I've been primarily been a Chrome user, so I was used to separate profile instances having their own taskbar group. Excessive CPU/resource utilisation aka fan noise and less battery have pushed me back towards Firefox.

impact: hard to know which windows relate to which profile

This problem impacts productivity and increases frustration because you've no immediate idea which windows relate to which profiles. If you're like me and like to keep certain topics clean and separate, like work and private life, and various project work, this is a major issue.

solution: there is a config tweak workaround

There was an official bug fix for this issue titled "No way to un-group separate instances on Windows 7 TaskBar". It took me at least an hour of research to find and get this setting working after a number of dead ends, so sharing it here.
  1. Open about:config
  2. Right click "new" > "boolean"
  3. When prompted set the name to taskbar.grouping.useprofile and the value to true
  4. Restart Firefox
Note that the new setting does not use the browser. prefix.


Props to:
ptsampoukas @ MozillaZine forums for pointing me in the right direction.

Friday, May 4, 2018

Microsoft Visio 2013 :: Import of image file failed: '[name of the image file]'

problem: I cannot insert an image file into Visio 2013 (INSERT > PICTURES > (any graphic formats .png, .jpg, etc).

The popup message is: "Import of image file failed: '[name of the image file]'". Pasting the image also didn't work and complained with a pop up about not enough memory.

impact: cannot import images in Visio

solution: install Visio KB3114720

Here is a link to the update for Visio 2013 (KB3114720) (Applies to: Microsoft Visio 2013 Service Pack 1)

Interestingly enough making a new windows profile and trying to insert an image in Visio in the new profile worked fine. Opening that saved drawing in the profile that was not working showed a box with an X inside where the image had been successfully inserted in another profile.

Pasting from mspaint did work, but things like transparency were lost in this case.


Props to:
Pieter Pessemier @

Tuesday, September 5, 2017

xterm .Xresources not being applied at awesome startup (x2go)

problem: xterm settings not being applied at awesome startup (x2go)

impact: have to manually merge after awesome startup

solution: use a custom launch script that merges settings before awesome starts

#!/bin/sh [ -f ~/.Xresources ] && xrdb -merge ~/.Xresources exec /usr/bin/awesome

Tuesday, July 18, 2017

windows 10 and smb share mounting not working // system error 64

problem: net use w: \\hostname\path errors with system error 64

impact: cannot mount the share

solution: check the smb protocol version of the server (and client)

Client Windows 10 Pro 1703

Mounts to linux smbd v4 were working ok
Mounts to linux smbd v3.6.6 were not working

using elevated powershell we could see the existing shares
PS C:\Windows\system32> Get-SmbConnection
This can be useful if comparing working shares vs. non working shares as it shows the Dialect version of SMB protocol.
In this case the linux smbd 4.x version was using Dialect 3.x The linux smdb 3.6.6 was having the system error 64 after some trials we forced the smb protocol in the smdb.conf
[global] min protocol SMB2 max protocol SMB2
After an smbd daemon restart the windows client was able to connect and the Dialect was 2.0.2

Our conclusion was that win10 client was trying to speak SMB3 with the older smbd daemon which it doesn't support.

There were errors in the smdb logs that helped us reach this conclusion.

Saturday, March 28, 2015

error: C compiler cannot create executables

problem: error: C compiler cannot create executables

I was getting this on Debian systems and after some research found this solution worked for me on more than one occasion.

solution: reinstall binutils

aptitude reinstall binutils

Tuesday, April 1, 2014

problem: blocked/denied permissions on an NTFS folder which you don't own

impact: prevents you working with the folder and its contents

solution: use the SYSTEM account

some copy
psexec -s -i cmd