Agreed (and disagree at the same time).
Yes, btrfs is the choice of the guest/client.
But the VM/guest freezing up though (or seemingly or apparently looking like that it froze) which necessitated the forced shutdown and then powering on the VM again – that, I would think, would fall under the purview of the hypervisor.
(And a part of this is because I am doing like a direct compare-and-contrast between proxmox and xcp-ng simultaneously, so whatever I am doing on one hypervisor, I am doing the same thing on the other one, with maybe about 1.5 seconds lag (as fast as I can move the mouse over to click the same buttons, at approxmiately the same time.)
Proxmox didn’t exhibit this freezing issue.
xcp-ng did so, at least twice so far, whilst trying to configure/get the HTTP server running, and going through multiple reboots so that I can time them to see which one would be faster. (It was a way for me to test the performance, albeit, not a GREAT way to test it, without using ANY other tools/software than just the OS/guest itself.)
I know, but I can only report on my observations, as they are happening.
(I was only enabling and disabling the HTTP server in SLES12 SP4 via yast (the GUI) and when that become unresponsive, I would try it via the terminal inside the guest and it took would become unresponsive, and then I would go to “advanced → force shutdown” and after the guest/VM powers down, I would immediately start it back up again.)
(and for the HTTP server configuration, I would just uncheck the box to listen on port 80 on the loopback interface, and then click next, next, next, until the end, and then click on the option to start the apache2 server on boot, and then close/finish that).
And then the only other thing that I would do as well would be to delete the network bridge (as it only has one NIC interface anyways), and then set the static IPv4 address, subnet mask, gateway, dns servers, and hostname of the guest/VM. (Did this in both xcp-ng and proxmox.)
That’s all that I’m doing with it. (And then to test the reboot times, or actually to test whether the HTTP server would start on boot like it is supposed to, I would disable the HTTP server, and reboot, and then time the reboot, and then go back into yast to see if the HTTP server started back up like it was supposed to (or not), and if it didn’t, I would enable/start the HTTP server service and reboot it again, and then time the reboot again as well.
Rinse. Repeat (to collect repeatability data).
xcp-ng has a standard deviation of 5.660984 seconds whilst proxmox has a standard deviation of 1.09739 seconds (on the reboot times).
The max/mins (in seconds) are as follows:
xcp-ng: 61.75/45.96
proxmox: 37.22/34.08
Initially, I would have thought so as well.
But seeing how xcp-ng appears to have failed to install SLES12 SP1 using the SLES12 SP3 template, my observations would suggest or indicate that I might not actually be able to do that. If I was able to install SLES12 SP1 using the SLES12 SP3 template, I would observe the data that would abide by that.
However, I ended up switching to SLES12 SP4 because I wasn’t able to get SLES12 SP1 installed in xcp-ng. (In Proxmox, I was able to install SLES12 SP1 no problems.) I waited about an hour (maybe close to an-hour-and-a-half) whilst the installer for SLES12 SP1 tried to boot up in xcp-ng before finally calling it as that it failed to execute the SLES12 SP1 installation, and that’s when I stopped the SLES12 SP1 VM in proxmox, deleted it, and then re-created new VMs on both that are both SLES12 SP4 where in xcp-ng, I was using the SLES12 SP4 template.
Being new to this, I have no idea why this was happening, but due in part to this, I ended up testing the system until around 4:30 AM this morning.
But I would surmise then, that until that is released, I would need to use multiple browser windows to be able to control the system and monitor the VM’s/guest’s performance?
Would that be correct?
(And this is with the assumption that I am not installing any additional software in the guest/client VM (e.g. TigerVNC or TurboVNC or something like that – this is just using what’s available to me, as the user, out of the box.)
(Sidebar: proxmox already allows you to detach the console using noVNC that’s built into proxmox)