<
Proxmox STRATO Server
01 Preparation Server and VM 02 Network and SSH 03 Firewall 04 Serial Console 05 Installation Mixed topics
>

Proxmox on a server from STRATO

Diffrent topics about a proxmox on a STRATO server

From time to time there arise issues due to the server at STRATO or Proxmox that needed to be taken into account. But it's not always so much that I want to create my own website for it. But theese things are often worth mentioning, so I collect it here and present it together.

Select a topic:

New STRATO Server - Proxmox moves

After around a year with the first server, the prices for the servers increased. That wasn't much compared to the total price. But then there was an offer price for a different type of server that was in the “Limited Hardware” category without an agreed time limit. Thanks to the offer, I was able to reduce the price to the old price level and also carry out a small hardware upgrade. After thinking about it for a while, I decided to make the switch. That means I ordered the new server and canceled the contract of the old one few days later. Cancellation means you can until the day of the notice period still use the server completely. After that everything is switched off. You can also withdraw your cancellation beforehand via your customer login. From then on I still had almost a month to prepare everything. Here's a comparison of the servers:

Old Server

In the picture you can see a section of the configuration of my server. It has a Intel Xeon CPU which has 4 cores. As you can see, it had harddisks and also one SSD.
The harddisks are seen to be used for user data and setup as a Soft-RAID-1 on the initial setup. There are also variants which have a Hard-RAID but this I did'nt prefer because of known reasons.
The SSD is alone in the machine, so it is not raided. On it the OS was installed. To have the Harddisks also in a Soft-RAID-1 configuration when the Proxmox was installed I setup them with ZFS as RAID-1 and used them only to install the VMs and containers there.
The server has a connection at 100Mb/s maximum. This is enough for me, as I will never be able to have more speed on my side (on download). No diffence if I am mobile or at home. If it is required to have faster traffic or you want to utilize your fibre channel connection, it is also possible to pay for a gigabit traffic package.

New Server

The new server now has the same configuration of network, CPU cores and RAM size.
The CPU is also a younger generation Xeon CPU. In comparison, this brings with it a few technical innovations. The RAM technology is now of more modern DDR4 memory and therefore faster.
This server no longer has hard drives. It only comes with two SSDs, which are initially configured as Soft RAID-1. The OS is installed on them and the user data must also be saved on them.
The more modern CPU and faster RAM are nice and make the system faster. However, with the SSDs and the loose of the hard drives, it is a change. How I dealt with it below.

Change of the configuration of the SSDs

I first had to deal with the change due to hard drives and SSDs. The SSDs are configured in the STRATO original with Linux MD-RAID. You shouldn't use that for Proxmox anyway, especially not for your guests.
I think a RAID makes sense for hard drives because they can quickly fail due to vibrations. Naturally, there are more vibrations in a data center than on a computer at home. However, SSDs do not have the problem of being sensitive to shocks. In principle, they can also fail. However, this is less likely here than with hard drives. Therefore, I don't think it's necessary to configure RAID-1 for SSDs and have decided to use the SSDs individually.
One possible way is then to have the SSDs configured individually in Proxmox as storage for VMs. But you can have the SSDs bundled which adds up the storage volumes. A RAID-0 does this, but requires disks of the same size. To do this, Proxmox would have had to set up the entire system with ZFS, which is supported but incompatible with the old provisioning VM. LVM+ext4 was used there. Proxmox uses LVM for volumes by default. The root gets its own volume and guests are stored in the so-called LVM thin. LVM, in turn, can also be used to distribute the so-called volume group across several disks (physical volumes). The LVM doesn't care about different sizes.
So I decided the first SSD will have the LVM containing "root" volume on it and behind it the LVM thin volume. The second SSD "extends" the volume group and the LVM-Thin volume extends over the entire SSD. So I have 960GB SSD available instead of 480GB. The VMs are then placed to the LVM thin area.

Let Proxmox move - from server to server

The normal way to move Proxmox to a new server is to make a backup of all machines (must be stored external), reinstall Proxmox on the new server and restore the machines from the backup there. But a new installation was too complicated for me. Since the old system was already running LVM for the system, I had another idea. Of course, I still made a backup of all machines.
But I then restarted both servers boot into the Rescue OS (the new one was already initially set up and I had copied data). On both then SSH and the already known "dd" tool are available and you can then copy the entire SSD from old to new through an SSH tunnel. The old SSD was also smaller than the new one, so it fit easily on the new one. So I had the Proxmox installation moved from the old server to the new one via SSH tunnel.
Once there, I first had to change LVM to the new size of the first SSD. On the other hand, I had to reduce the root volume from 126GB to 20GB so that there is space at the end for LVM-Thin. I then configured the other SSD for LVM and increased Proxmox's volume group to include the second SSD. As a last step, as in the installation instructions, I went to a change root in the Proxmox and did the post-configuration again. When I completed it, I switched the new server to “standard operating system” and restarted it.
Only one point was missing. Due to the new host name, Proxmox created the system as a new Proxmox "node", which is why I had to clean up some rests of the old system. But that happened quickly. I then created the LVM thin volume in Proxmox and registered it as a new storage. And as a final step, I restored the VMs or containers from the backup. After that everything was finished and runs for some time now. Above all: it runs more stable than the old one. I then left the old one running with minimal operation for the rest of the month.

Proxmox distribution upgrade

If the Proxmox server is in use for a while, the system will have to be upgraded to a new version of the distribution. When that happens depends on Debian's release cycle and how quickly the Proxmox developers have updated their own components. One of the methods is not to try an upgrade, but to make backups of all machines, reinstall it with the new version and then pull the machines back into the system with a restore. Thanks to Proxmox's design, nothing happens to the critical parts, meaning the machines.
But that would be associated with circumstances in the setup of the STRATO server. You would have to go through the entire installation instructions again in order to reinstall the server. The second option is the direct upgrade. This basically works and is a little easier with the STRATO Server in the background.
Some time ago I was upgrading from Proxmox Bullseye to Bookworm and I did the upgrade. The basic procedure is explained on the Proxmox wiki.

more here...
Basic steps to procedure:
  1. Doing backups of all machines. If something goes wrong you have a backup. It is the best te keep the guest shutdown.
  2. Check the status of the installation with the upgrade tool. (When upgrade from 7 to 8: pve7to8.) Some warnings can be ignored, which are typically for this kind of installation. If the most is fine after the first run a good way is to repeat it with the parameter "--full".
  3. Update the infos about the package versions and install updates. Maybe you need to have the newest package versions installed to protect against incompatibility issues.
  4. Update the package sources to the new distro. Therfore you have to update the Debian and the Proxmox repos. I used the "sed" command line. It worked fine.
  5. By calling "apt update" let the tool fetch the new package lists.
  6. Run the upgrade by the call of "apt". While doing this it maby comes to questions about the changes on some files. More below.
  7. Do a clean up run by calling "apt autocremove" and "apt autoclean". After that is done the upgrade is completed and you have to restart the server.

During the upgrade you will be asked what should happen to individual files in the system. You're asked if it should install the developer's version, keep the old one, or do you want to merge both (if possible). You should basically proceed as follows:

In the instructions shown here, it was required to change some files here to let the Proxmox server work. Furthermore, the first distribution upgrade after installation may result in a special query from the boot manager. So here are a few special tips for these.

Changes to the configuration of SSHD

You have to be a little careful here. If the normal settings are set and loaded here, we will lose the connection to the server. In addition, anyone can then suddenly log in with a password, which was disabled in the instructions shown on this page. Here you have select the option to get a shell, where you can edit the file yourself. In the case of upgrading from 7 to 8, the changes included removing a setting that is no longer supported and will be removed soon. Another setting was also renamed. Both things that could be done on the existing file.
If that hadn't been possible, I would write a copy using the $DPKG_CONFIG_NEW variable next to the old configuration file, in which the changes from the configuration of the SSH taken over and then exchange the files. Then nothing should happen.

Changes for the file "/etc/default/grub"

If it asks about changes to the file, then it is due to the serial console settings. Settings were set in the file so that the Grub boot manager supports the serial console on the one hand and the Linux kernel on the other hand when Proxmox starts. It's not a big deal if you let the original settings install here. However, when you restart, the serial console no longer works until you have changed the settings in the file again according to the instructions. Normally completely meaningless. However, to monitor the first start of the upgrade, it may make sense to also watch the serial console. But you can first install the package maintainers version, complete the upgrade up to the point before the restart and then set the settings again ("don't forget update-grub").

Where should grub be installed?

This is the question you get asked when you upgrade Proxmox after the system has been copied from the VM to the STRATO server using the method shown here. The Grub boot manager notices that it can no longer find the disk it previously done a installation on (it is looking for the VM disk). When it comes to making the right selection, you have to keep track over some details which depend on how you have configured the disks on the STRATO server. Servers with ONLY 2xSSD or 2xHDD bundled to a Soft-RAID-1 via ZFS (Linux MD-Raid is not supposed to work with Proxmox) select "/dev/sda". Server with hardware RAID the first disk (sorry, no idea what it's called). If you only have one disk, it is also “/dev/sda”. If you have 1xSSD and 2xHDD like my first server, then the OS is installed without soft RAID and you select "/dev/sda". The hard drives would then be “/dev/sdb” and “/dev/sdc” and you shouldn’t install Grub there. If you done such a mistake then the system no longer boots.
Once you have confirmed this, it should continue install the boot manager. (In an emergency, this can be corrected in the Rescue OS.) This question should no longer be asked for further upgrades.

Rescue OS to make backups and fix problems

The Rescue System can help in various ways with upgrades. On the one hand, you can switch there before upgrading. You have the option of making a complete backup of the Proxmox system. In the server login you select the switch to the rescue system and "No hard reboot". After the server login shows that everything has been changed, you order the Proxmox server to restart. For the backup, I took a dump of the SSD that had root installed. The target I used was a HiDrive, which I mounted via SSHFS. You have to install this briefly in the Rescue OS. Unfortunately, this doesn't work via Windows sharing, i.e. CIFS, even after installation. I had the dump written to the HiDrive as a file using the “dd” command (see installation instructions). With the tool you can also make a dump and store it at home analogously in the reverse direction through an SSH tunnel as described here.
Another use for the rescue is if you have problems due to the upgrade. It should be noted that in case you have to call Proxmox tools (e.g. the "proxmox-boot-tool" or "grub-update" to fix the boot manager), you have to switch to a "Change Root" environment as in the installation instructions shown.