How to delete Hyper-V Virtual Networkcards in Windows 10

As a "Edge" Version user of Docker for Windows, I tend to reinstall Docker from time to time, just to get a clean base. However, Hyper-V digs quite deep into the system and creates its own virtual network interfaces, which you just can't delete from the Hyper-V Manager.

Best option is to use (READ ALL BEFORE COPY AND PASTE, PLEASE!):

netcfg -d

in a Administrator CMD window.

This does only delete virtual network devices - HOWEVER, it does delete devices like i.e. your OpenVPN interface AS WELL - AND does DELETE ALL SETTINGS of other network interfaces, i.e. your IP configuration or all your saved WIFI credentials.

So use with care!

Taken from: https://serverfault.com/questions/584316/how-to-delete-hyper-v-virtual-switch-extensions-adapters-from-device-manager

NFS Benchmarking RPi 3B, RPi 3B+ & BPi

3-14, PiDay. Sadly the day Stephen Hawking passed away - and the day the new Raspberry Pi 3B Plus was unveiled.
Some days later, I got a small package:

With that small thing at hand, I was looking through the list of changes:

  • Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC @ 1.4GHz
  • 2.4GHz and 5GHz IEEE 802.11.b/g/n/ac wireless LAN, Bluetooth 4.2, BLE
  • Gigabit Ethernet over USB 2.0 (maximum throughput 300 Mbps)
  • Power-over-Ethernet (PoE) support (requires separate PoE HAT)

Ok, CPU bumped from 1.2 to 1.4 GHz, new WiFi with 802.11ac (and 5 GHz support), BLE 4.2, PoE "support" - and Gigabit over USB 2.0.
Well, not too bad.
One of the biggest downsides of the RPi - since its release - was the design choice to add Ethernet over USB 2.0 - while sharing the one and only USB 2.0 lane of the BCM with all the other USB sockets of the RPi. While this choice leads to lower production costs, it also limits the speed of Ethernet / USB especially in case where people tried to implement NAS or File sharing applications with an added USB Drive over Ethernet. To see how much the new design improved that old problem, I decided to Benchmark an "old" RPi 3B with the latest RPi 3B+ in the discipline of NFS.

Test setup:

  • Raspbian Stretch Lite (March 2018 / 2018-03-13 / Kernel 4.9)
  • WD PiDrive 314 GB as HDD via USB
  • Gigabit Ethernet Switch
  • Benchmarking system: Windows 10 with MS NFS Client, Crystal Disk Mark 4.0.3 and Gigabit Ethernet
  • NFS Exports Options: (rw,sync,no_subtree_check,all_squash,anonuid=65534,anongid=65534)

The benchmark started with the old RPi 3B and no surprises:

The RPi 3B is lacking throughput at its USB 2.0 lane.

Next up, was the new RPi 3B+:


And - yes - the new design really showed some improvement, to say the least.

However, I was wondering: What would happen if I added an SBC with a real USB 2.0 connection and real Gigabit Ethernet to the test?
Well - I did that. Welcome the now 4 years old Banana Pi 1:

We are talking here about a 1 GHz Dual Core A20 processor with 1 GB RAM which is - i need to repeat - 4 years old - releases just 2 months before the Raspberry Pi 1 B+ came out - I direct competitor of the RPi 1st Generation. But, what happens if we use the SATA port - which is also included on the BPi? With... lets say... some Samsung 850 EVO 250 GB SSD - which I had laying around? 😉

And what happens if I plug that in via USB?

Ok. Thats a bit confusing, to say the least. Could be that the SATA port is actually just coupled via USB to the BPi - however, I saw benchmarks on which the SATA port performed a lot better on the BPi. For this benchmark, I used ARMBIAN:

ARMBIAN Debian Server mainline Kernel
Armbian_5.38_Bananapi_Debian_stretch_next_4.14.14
Welcome to ARMBIAN 5.38 stable Debian GNU/Linux 9 (stretch) 4.14.18-sunxi

So, bundling an SSD with some old SBC board will not give you the needed freedom to just drop buying expensive storage for your datacenters and replacing them with small boards - sadly ;). However, we could see that the new RPi 3B+ improved a lot in one of its weak points - but still gets beaten by an very old - and still very feisty rival.

[VMWare] Deploy vCenter Server Appliance to ESXi 6.5

To deploy the vCenter Server Appliance (vcsa) to an ESXi 6.5 Server, you need to grab the latest vCenter Server for Linux from http://vmware.com/go/evaluate-vsphere-en - at the moment, thats the Version 6.5.0U1d from 19.12.2017 - which equals to the file VMware-VCSA-all-6.5.0-7312210.iso. After downloading that DVD Image, just burn it to a DVD or unpack it. You can then go on with Deploying it via GUI - or via CLI.

For deploying it via GUI, just start vcsa-ui-installer\win32\installer.exe - if you're on a Windows PC - or execute the installer / Installer.app files in the lin64 or mac folders.

If you want to deploy it via CLI using a template, you should navigate to vcsa-cli-installer\win32. Within that folder, you will find the vcsa-deploy.exe - that is the one we are going to use.

Now, we need to provide a template for deploying our vcsa:

{
    "__version": "2.3.0",
    "new.vcsa": {
        "esxi": {
            "hostname": "ESXI_IP",
            "username": "ESXI_USER",
            "password": "ESXI_PASSWORD",
            "deployment.network": "ESXI_NETWORK, i.e. VM Network",
            "datastore": "ESXI_DATASTORE"
        },
        "appliance": {
            "thin.disk.mode": true,
            "deployment.option": "tiny",
            "name": "NAME_OF_THE_VCSA_APPLIANCE"
        },
        "network": {
            "ip.family": "ipv4",
            "mode": "static",
            "ip": "IP_OF_THE_VCSA",
            "dns.servers": "DNS_SERVER_OF_THE_VCSA",
            "prefix": "NETMASK_OF_THE_VCSA",
            "gateway": "GATEWAY_OF_THE_VCSA",
            "system.name": "HOSTNAME_OF_THE_VCSA"
        },
        "os": {
            "password": "PASSWORD_OF_THE_VCSA_ROOT_ACCOUNT",
            "ntp.servers": "0.pool.ntp.org",
            "ssh.enable": true
        },
        "sso": {
            "password": "SSO_FOR_VCSA_PASSWORD",
            "domain-name": "DOMAIN_NAME_OF_VCSA_AD - could be vsphere.local",
            "site-name": "DEMOSITE"
        }
    },
    "ceip": {
        "description": {
            "__comments": [
                [
                    "This is a demo template with disabled CEIP / Customer Telemetry"
                ]
            ]
        },
        "settings": {
            "ceip.enabled": false
        }
    }
}

Just fill in the needed variables and save it in the root folder of your installer, i.e. as install_template.json. Then run the installer (in Windows, that means to execute following CMD): vcsa-deploy.exe install install_template.json --accept-eula

The installer will then deploy the vcsa and inform you, as soon as everythings ready:

===============================================================================
vCenter Server Appliance installer finished deploying "HOSTNAME_OF_THE_VCSA".
This appliance is a vCenter Server instance with an embedded Platform Services
Controller.
    System Name: IP_OF_THE_VCSA
    Log in as: Administrator@DOMAIN_NAME_OF_VCSA_AD i.e. Administrator@vsphere.local
Finished successfully.
===============================================================================

You can then log into https://IP_OF_THE_VCSA to the vCenter Server (with the SSO Login, i.e. Administrator@vsphere.local) or https://IP_OF_THE_VCSA:5480 to the vCenter Appliance Administration (with VCSA Login, i.e. root and PASSWORD_OF_THE_VCSA_ROOT_ACCOUNT)

Debian 9 Offline Installation Bug

I had to install a Debian 9.3 without having access to the internet, so I downloaded the full size offline install DVD from https://cdimage.debian.org/debian-cd/current/amd64/iso-dvd. As usual, I inserted the first DVD into the DVD Drive, started the install and everything worked fine - except for the moment where it didn't ;): I needed to switch DVDs for some software - and directly afterwards, Debian came to the "Install Grub" step - and asked politly to insert DVD 1 again - which I tried to do - but could not:

For some reason, the Debian GUI Installer had locked the DVD Drive and I could not remove the DVD - could not open it. I then used the Emergency Eject, inserted DVD 1 and closed the Drive again with very mild force.

However, the Installer did not recognize the new DVD and said, that I needed to insert a DVD. Well...

To cope with that problem, just CTRL+ALT+F1 switch to a different Terminal, enter mount /dev/cdrom /cdrom and switch back to the Installer Terminal with CTRL+ALT+F7 (I think it was ;)) - and hit "Continue" - and from that moment on, it worked again and the installation ended successful after the GRUB installation.

 

[VMWare] Get and upgrade ESXi 6.5 "offline" - without paid license

As I wanted to have a very recent version of ESXi, I went to VMWares website and checked out their Products, Free Products, vSphere Hypervisor section. This, however, only presented me with a ESXi 6.5.0a ISO from 02.02.2017 - too old. However, you'll get the much needed free license - so the visit pays off :).

So to get the latest version and updates, you need to go to http://vmware.com/go/evaluate-vsphere-en - and are presented with the 6.5.0 U1 ISO from 27.07.2017 - a lot better. With said image you can then install your server. Even if you had an old 6.5.0a install, you could download the VMware vSphere Hypervisor (ESXi) Offline Bundle - which will upgrade your old 6.5.0 installation to U1 from that site.

After that, you'll need to check out the very useful VMWare ESXi Patch Tracker on https://esxi-patches.v-front.de/ESXi-6.5.0.html. There you can see, which patches are needed to get your ESXi host to the latest version (in my case I only need to apply the 2017-10-05 patch series to get from U1 to latest). So now switch over to https://my.vmware.com/group/vmware/patch#search and look for ESXi 6.5.0 patches. I did find my needed ESXi650-201710001 patch with release date 05.10.2017 - and downloaded it. From the ESXi Patch Tracker I now know, that the Imageprofile of said Update is called ESXi-6.5.0-20171004001-standard and uses the Buildnumber 6765664. I then enabled SSH on the ESXi Host, shutdown all VMs, put the ESXi Host into Maintance mode and uploaded the ESXi650-201710001.zip to a folder on my Datastore datastore01 into a folder I created called ESXiUpdate.

After that, I could execute said update via SSH with the command esxcli software profile update --depot="[datastore01]ESXiUpdate/ESXi650-201710001.zip" --profile ESXi-6.5.0-20171004001-standard

As you can see, it needs to provide the path to the patch file, as well as the Imageprofilename we found out earlier via the ESXi Patch Tracker. After the successful installation, a reboot is need.

As soon as the machine has booted again, login and check if the Buildnumber now matches the Updates Buildnumber. If this is true, disable the Maintenance Mode, restart the VMs and you're good to go.

If other patches need to be applied, you would re-enable SSH  access, not restart the VMs and not disable the Maintenance Mode and just keep on uploading and applying the updates :).

More infos abot the esxcli commands can be found here - and you can still use your free license with ESXi 6.5 which you acquired at the first steps of this weblog - even if you use the most recent patch (luckily!).

And now, get those machines patched ;)!