2017-07-17

Running graphical Linux apps on Windows with WSL

As you have probably heard by now, Windows now comes with something amazing called WSL - Windows Subsystem for Linux.

WSL allows you to run your favourite CLI tools on a Windows workstation. Install WSL from Windows Store, search for Ubuntu for example. Read more about WSL in here: https://msdn.microsoft.com/en-us/commandline/wsl/about

What WSL does not natively support is running graphical applications, aka. X applications.

Trying will result in: Error: Can't open display.


Solution

Luckily there are usually ways to go around official limitations, in this case by installing a 3rd party X server on Windows. One example is VcXsrv which can be downloaded from here: https://sourceforge.net/projects/vcxsrv/

Ensure you have installed/enabled WSL, install VcXsrv and go to your Linux by launching Bash on Ubuntu on Windows. Run the following commands:

 sudo apt install x11-apps
 export DISPLAY=:0
 xeyes

In Fedora you'd use dnf instead of apt, naturally.

Running xeyes should look something like this:



2017-07-13

Running Fedora 26 on Azure

Fedora 26 was released earlier this week. I wanted to test how it works on Azure, and since Fedora is not currently available from Azure Marketplace I had to create my own VM image.

Connected to Fedora 26 server running on Azure
Here is a small how to document I wrote during the exercise, feel free to try it out yourself!

Download the installation ISO

I used the Server edition since there's not much use for the graphical tools on Azure.



Create a local VM

I used a Windows 10 laptop running Hyper-V to create a local VM with the following details:

  • generation 1 VM type (Hyper-V specific)
  • 8GB disk (note: larger the file longer it takes to upload to Azure!)
  • 1024 RAM startup memory (depending on your laptop's RAM size)


NOTE! do not make snapshots/checkpoints during VM creation. Otherwise exporting the image becomes difficult at least in Hyper-V.

Fedora 26 installation


  • Standard partition (not LVM since Azure can't handle LVM booting well currently)
  • XFS filesystem
  • remove swap (Azure will add it later automatically)
  • add only root password, no users


After installation is complete turn off the VM and remove the installation DVD ISO drive if needed.

Modify the VM

Linux VMs need to be modified a bit to be Azure compatible.

Start your new Fedora VM, log in and verify your networking works at this point:
 ip addr show

Update the system:
 dnf -y update

Edit network configuration to disallow Network Manager to mangle with the main interface:
/etc/sysconfig/network:
 NETWORKING=yes
 HOSTNAME=localhost.localdomain

/etc/sysconfig/network-scripts/ifcfg-eth0:
# add/edit these lines, remove all others including IPv6:
 DEVICE=eth0
 ONBOOT=yes
 BOOTPROTO=dhcp
 TYPE=Ethernet
 USERCTL=no
 PEERDNS=yes
 IPV6INIT=no
 NM_CONTROLLED=no

Turn of static udev rules for network devices, could break when cloning VMs:
 ln -s /dev/null /etc/udev/rules.d/75-persistent-net-generator.rules

Ensure networking is started on boot:
 systemctl enable network

Reboot and verify you still get an IP address. Much easier to fix at this point if you broke something.

Modify some boot options. Note the two console= parameters to allow messages also on local console for debugging, remove other parameters if needed)

/etc/default/grub:
 GRUB_CMDLINE_LINUX="rootdelay=300 console=tty0 console=ttyS0 earlyprintk=ttyS0 net.ifnames=0"

Generate new grub files:
 grub2-mkconfig -o /boot/grub2/grub.cfg

Ensure the Hyper-V drivers are included in the image:
/etc/dracut.conf:
 add_drivers+=" hv_vmbus "
 add_drivers+=" hv_netvsc "
 add_drivers+=" hv_storvsc "

 dracut –f -v

Install Azure Linux Agent from Fedora repository:
 dnf -y install WALinuxAgent python
 systemctl enable waagent
 dnf clean all

/etc/waagent.conf:
 ResourceDisk.Format=y
 ResourceDisk.Filesystem=ext4
 ResourceDisk.MountPoint=/mnt/resource
 ResourceDisk.EnableSwap=y
 ResourceDisk.SwapSizeMB=4096

Apply the Azure agent settings:
 waagent -force -deprovision
 export HISTSIZE=0
 logout

On your virtualization manager convert the disk to .vhd + fixed size file fedora26.vhd. The exact procedure depends on your hypervisor technology.

Create managed disk and VM

Upload the fedora26.vhd to Azure as "page blob" via Azure cli or portal. In this example I used "rg1" and "container1".

Create a managed disk, using Azure CLI 2.0 in this example:
 az disk create --resource-group rg1 --name fedora26managed --source https://username.blob.core.windows.net/container1/fedora26.vhd

Verify its really there:
 az disk list -g resourcegroup1 --output=table

Create your vm with 5GB (or more) additional data disk:
 az vm create --resource-group rg1 --location westeurope --name fedora26 --os-type linux \
 --admin-username username --ssh-key-value ~/.ssh/id_rsa.pub --attach-os-disk fedora26managed \
 --size Standard_DS1 --data-disk-sizes-gb 5

At this point your new Fedora 26 server VM should be created, up and running happily.

Azure portal

 Disclaimer: I work for Microsoft as Cloud Solution Architect since 2017/06.


2017-05-10

Resize Linux VM system disk on Azure

So you have created a Linux VM in Azure with too small disk? Resizing the disk is possible, but requires couple of steps which I will describe here.

My resource group is named "group1" and the VM is named "rhel7a". The Linux VM I used is a RHEL, but the commands are applicable for at least CentOS and Fedora as well.




Running Azure CLI 2.0 on your laptop (or management server):
First step is the enlarge the device on Azure.

Turn off your VM by stopping it, otherwise it's not possible to modify the disk:
# az vm stop --resource-group group1 --name rhel7a

Deallocate the VM:
# az vm deallocate --resource-group group1 --name rhel7a
Check your VM disk name and expand it to for example 40GB:
# az disk list -g group1 --output table

# az disk update --resource-group group1 --name rhel7a_disk1_30de1433bf824608b0c3ee6c8b2b52a0 --size-gb 40

Start the VM:
# az vm start --resource-group group1 --name rhel7a

Now login and continue inside the VM:
# ssh username@13.95.xx.xx


This part happens inside the Linux VM:

First we will make expand the partition and check the disk name you are about to modify:

# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        19G  1.4G   16G   4% /
devtmpfs        1.7G     0  1.7G   0% /dev
tmpfs           1.7G     0  1.7G   0% /dev/shm
tmpfs           1.7G  8.3M  1.7G   1% /run
tmpfs           1.7G     0  1.7G   0% /sys/fs/cgroup
/dev/sda1       976M  140M  769M  16% /boot
/dev/sdb1       6.8G  2.1G  4.4G  32% /mnt/resource
tmpfs           345M     0  345M   0% /run/user/1000

Modify the partition by deleting and re-creating it. Data will not be lost:

# fdisk /dev/sda
Command (m for help): p
   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048     2099199     1048576   83  Linux
/dev/sda2         2099200    83875364    40888082+  83  Linux

Command (m for help): d
Partition number (1,2, default 2): 2


Partition 2 is deleted

Command (m for help): n
Partition type:
   p   primary (1 primary, 0 extended, 3 free)
   e   extended
Select (default p): p
Partition number (2-4, default 2): 2
First sector (2099200-83886079, default 2099200): (press enter here)
Using default value 2099200
Last sector, +sectors or +size{K,M,G} (2099200-83886079, default 83886079): (press enter here)
Using default value 83886079
Partition 2 of type Linux and of size 40 GiB is set

Command (m for help): p

At this point you'll need to reboot the server:
# reboot

Now log in again with ssh and continue by resizing the ext4 filesystem:
# resize2fs /dev/sda2
resize2fs 1.42.9 (28-Dec-2013)
Filesystem at /dev/sda2 is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 5
The filesystem on /dev/sda2 is now 10222020 blocks long.

For xfs filesystem you can do: xfs_growfs -d /dev/sda2


Verify the filesystem is seen at correct size:

# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        39G  1.4G   36G   4% /
devtmpfs        1.7G     0  1.7G   0% /dev
tmpfs           1.7G     0  1.7G   0% /dev/shm
tmpfs           1.7G  8.3M  1.7G   1% /run
tmpfs           1.7G     0  1.7G   0% /sys/fs/cgroup
/dev/sda1       976M  140M  769M  16% /boot
/dev/sdb1       6.8G  2.1G  4.4G  32% /mnt/resource
tmpfs           345M     0  345M   0% /run/user/1000

And we are ready!