Work

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 # Clone the VM qm clone 9000 4140 --name nzbget.ka.beiheimdaheim.de --full=true --storage vmstorage # Set the nameserver qm set 4140 --nameserver=10.76.41.1 # Set the ipconfiguration qm set 4140 --ipconfig0 ip=10.76.41.40/24,gw=10.76.41.1 # Configure the virtual network adapter. qm set 4140 --net0 virtio,bridge=vmbr0,tag=41 # Enable autoboot qm set 4140 --onboot 1 # Set the RAM of the VM qm set 4140 --memory 2048 # Set the vCPU count for the VM qm set 4140 --cores 2 # Start the VM qm start 4140

Step 1: Download the Ubuntu image 1 2 3 4 5 6 SRC_IMG="https://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-amd64-disk-kvm.img" #VMSTORAGE="/vmstorage" VMSTORAGE="/var/lib/vz/images" IMG_NAME="jammy-server-cloudimg-amd64-disk-kvm.qcow2" IMG_PATH="$VMSTORAGE/$IMG_NAME" wget -O $IMG_PATH $SRC_IMG Step 2: Add necessary packages 1 2 sudo apt install -y libguestfs-tools sudo virt-customize -a $IMG_PATH --install cloud-initramfs-growroot,atop,htop,nano,vim,qemu-guest-agent,curl,wget,unattended-upgrades,git Step 3: Modify /etc/ssh/sshd_config 1 sudo virt-customize -a $IMG_PATH --run-command "sed -i 's/.*PasswordAuthentication.*/PasswordAuthentication yes/g' /etc/ssh/sshd_config" Step 4: Modify /etc/apt/apt.conf.d/50unattended-upgrades 1 2 export EDITOR=nano sudo -E virt-edit -a $IMG_PATH /etc/apt/apt.conf.d/50unattended-upgrades Step 5: Modify /etc/default/grub 1 2 3 export EDITOR=nano sudo -E virt-edit -a $IMG_PATH /etc/default/grub sudo virt-customize -a $IMG_PATH --run-command "update-grub" Step 6: Install ohmybash 1 2 sudo virt-customize -a $IMG_PATH --run-command "git clone https://github.com/ohmybash/oh-my-bash.git /opt/ohmybash" Step 7: Fix timezone 1 sudo virt-customize -a $IMG_PATH --timezone "Europe/Berlin" Step 8: Create the Proxmox template 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 TEMPL_NAME="ubuntu2204-cloud" VMID="9000" MEM="512" DISK_SIZE="10G" DISK_STOR="vmstorage" NET_BRIDGE="vmbr0" qm create $VMID --name $TEMPL_NAME --memory $MEM --net0 virtio,bridge=$NET_BRIDGE qm importdisk $VMID $IMG_NAME $DISK_STOR qm set $VMID --agent enabled=1 qm set $VMID --scsihw virtio-scsi-pci --scsi0 $DISK_STOR:vm-$VMID-disk-0 qm set $VMID --ide2 $DISK_STOR:cloudinit qm set $VMID --boot c --bootdisk scsi0 qm set $VMID --serial0 socket --vga serial0 qm set $VMID --ipconfig0 ip=dhcp qm set $VMID --ciuser=christian qm set $VMID --cipassword="bla" qm set $VMID --searchdomain=ka.beiheimdaheim.de qm resize $VMID scsi0 $DISK_SIZE qm template $VMID

Since I got the pleasure of watching some Windows boxen with Nagios, I took the Windows Update plugin from Michal Jankowski and implemented it. It took me some time, to initially set up the nsclient++ correctly so it just works, but up till now the check plugin sometimes reported the usual “Service Check Timed Out”. Usually I ended up increasing the cscript timeout, or the nsclient++ socket timeout, but it still kept showing up. Since I rely heavily on my surveillance tools, I have the demand, that as few as possible false positives show up. So I ended up chasing down this error today, and after that I have to say it was quite simple. ...

I was fighting with our VTL again, and TSM was thinking all the drives were offline. In order to update the drive status, you’d need to go into the ISC and select each drive and set them to ONLINE. Since I’m a bit click-lazy, I wrote a simple nested for-loop, which gives me the output to update all the drives at once: 1 2 3 4 5 for i in 1 2; do for k in $( seq -w 1 32 ); do echo "UPDATE DRIVE VTL$i VTL${i}_DR${k} ONLINE=YES" done done Result is a list like this: ...

I had this weird plugin error the other day which bothered me on Friday. I decided to go fixing it. So after poking around in the vCenter installed software list. I couldn’t find the Auto Deploy in the list, so I figured due to my recent vCenter reinstallation while keeping the database, I forgot to reinstall Auto Deploy. I went ahead and started the Auto Deploy setup from the DVD again, until I received this weird looking error. Apparently the setup thought (and decided correctly) that Auto Deploy was already installed in my vCenter. ...

As I wrote before about enabling multipathing for the AutoYaST installation it’s about time I write this one here. Sadly AutoYaST needs a little push in the right direction (as to where to actually put the root device), so here’s part of my AutoYaST profile for such a Cisco blade: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 <profile xmlns="http://www.suse.com/1.0/yast2ns" xmlns:config="http://www.suse.com/1.0/configns"> <bootloader> <device_map config:type="list"> <device_map_entry> <firmware>hd0</firmware> <linux>/dev/sda</linux> </device_map_entry> </device_map> </bootloader> <partitioning config:type="list"> <drive> <device>/dev/sda</device> </drive> </partitioning> <scripts> <pre-scripts config:type="list"> <script> <debug config:type="boolean">false</debug> <feedback config:type="boolean">false</feedback> <filename>config-ucs.sh</filename> <interpreter>shell</interpreter> <source><![CDATA[ cat /tmp/profile/autoinst.xml | sed "s,/dev/sda,/dev/mapper/`/sbin/multipath -ll | grep dm-0 | cut -d -f1`," > /tmp/profile/modified.xml ]]> </source> </script> </pre-scripts> <chroot-scripts config:type="list"> <script> <chrooted config:type="boolean">true</chrooted> <debug config:type="boolean">true</debug> <feedback config:type="boolean">true</feedback> <filename>config-ucs-chroot.sh</filename> <interpreter>shell</interpreter> <location>http://install.home.barfoo.org/autoyast/scripts/config-ucs-chroot.sh</location> </script> </chroot-scripts> </scripts> <software> <packages config:type="list"> <package>multipath-tools</package> </packages> </software> </profile> Now, the profile addition takes care of the placement of the root-device now (simply parses multipath -ll) and adjusts the pulled profile accordingly ( /tmp/profile/modified.xml), which AutoYaST then re-reads. ...

Another .NET update later, an hour spent looking this up. Why is mscorsvw.exe using 25% CPU for >30 minutes? Here’s a short outliner on how to speed it up: The scripts we’ve provided are a convenience for people who don’t want to deal with a command prompt. If you prefer to use the command prompt, you can use the commands below instead. These commands depend on the version of the .NET Framework you have installed and the version of Windows that you have and whether it’s 32-bit or 64-bit. ...

For the past two months we’ve been trying to migrate a bunch (90 or so) VMs from XenServer to ESXi … However for some reason on some of them, the Converter Service would crash. VMware Converter crashing due to rsintcor32.dll Up till Monday, I had no idea why. I decided to look into the error once again, and this time decided just to Google the failing module… And guess what ? Out came this Citrix forum post regarding the failing module. So, after knowing that rsintcor32.dll belongs to the Citrix System Monitoring Agent service (well, I could have guessed that from the DLLs path 😛) I decided to simply stop the service. ...

Well, I’ve been playing around with PowerShell today. I had the task to move (as in change the IP address) two domain controllers into another VLAN. I could have done it the easy way and added the DNS servers by hand (by RDP’ing to each system having these particular DNS servers configured) - which wouldn’t have been very hard considering the domain only has 7 members at this point … ...

Well, I recently decided to rename a bunch of my Standard Port Groups, since they did no longer reflect the network they were providing. Since I’m a lazy bastard (well lazy as in click lazy), I wrote this little PowerCLI script: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 param( [string] $vcenter, [string] $cluster, [string] $oldpg, [string] $newpg, [string] $vlan ) # Add the VI-Snapin if it isn't loaded already if ( (Get-PSSnapin -Name "VMware.VimAutomation.Core" -ErrorAction SilentlyContinue) -eq $null ) { Add-PSSnapin -Name "VMware.VimAutomation.Core" } If ( !($vcenter) -or !($cluster) -or !($oldpg) -or !($newpg) -or !($vlan) ) { Write-Host `n "pg-cluster-rename: <vcenter-server> <cluster> <oldpg> <newpg>" `n Write-Host "This script renames each port group with the name <oldpg> to <newpg>" `n Write-Host " <vcenter-server> - DNS name of your vCenter server." `n Write-Host " <cluster> - Display-Name of the vCenter cluster, on which we are" Write-Host " gonna create the new portgroup." `n Write-Host " <oldpg> - Name of the old Port Group that is to be replaced (ie VLAN2)." `n Write-Host " <newpg> - Name of the new Port Group (ie PG-VLAN2-Produktion)." `n Write-Host " <vlan> - VLAN-ID for of the new port group." `n exit 1 } Connect-VIServer -Server $vcenter Get-Cluster $cluster | Get-VMHost | Get-VirtualSwitch -Name $vswitch | ` New-VirtualPortGroup -Name $pg -VLanId $vlan Get-Cluster $cluster | Get-VM | Get-NetworkAdapter | Where { $_.NetworkName -eq "$oldpg" } | ` Set-NetworkAdapter -NetworkName $newpg -Confirm:$false Get-Cluster $cluster | Get-VMHost | %{Get-View (Get-View $_.ID).configmanager.networkSystem} | %{ $_.RemovePortGroup($oldpg) } Disconnect-VIServer -server $vcenter -Confirm:$false This script basically takes a vCenter instance and a single cluster, then creates a new Port Group on each host, after which it reconfigures all VMs possessing a virtual NIC with that Port Group and then deletes the old Port Group.