I am using a Thinclient for my XCP Servers. Real small and cheap (if it is used) HP T620 with a 64G M2 SSD and 4 GRam Quadcore AMD CPU. To backup some VM i use a external USB3 HDD. It is running very nice and smoth. Power is between 5Watt an 20Watt excluding the USB Harddrive.
My coutumer had mostly two Servers and a Thin client.
my own Thinclient is used as a server for FHEM Homeautmatisation
Having the same issue here with metadata backups, tried Backblaze bucket and Amazon. Also the vm backups to S3 are failing usually with VDI_IO_ERROR(Device I/O errors) or "Error calling AWS.S3.upload: socket hang up" (but working to NAS). Is there somebody who made backups to S3 to work somehow?
Here is the guide for USB (partly copied from the article):
IMPORTANT: The way I made is is not recommend! Your pfSense should normally not run on a VM using this method but it still works. It's recommended to use a physical pfSense to perform this setup.
a VM running pfSense
all VMs on your XCP-ng host have to run guest gtilities.
a USP with USB Connection
Connecting the USP to a VM via USB
Plug-in the USP via USB into the Server
Enable USB-passthrough in the USB Tab of your Host (XCP-ng Center)
Shutdown the pfSense, attach the USB device to the pfSense VM in the Properties Tab of the VM
Start the VM
If you are using pfSense, you can install nut from the Package Manager. Once installed you will be able to access the setup from Services > UPS.
Select “Local USB” from the UPS Type and provide a UPS Name.
add this to your uspd.conf:
ACL all 0.0.0.0/0
add this to your uspd.users:
password = (YOUR PASSWORD)
allowfrom = all
instcmds = ALL
Attention! The username has to be written with the brackets! ie: [admin]
click on save and pfSense should now detect your UPS and give you its information in the UPS Dashboard.
Configure the XCP-ng host as NUT slave (pfSense is master)
By default the built in repository does not have the required library, so we need to enable the epel repository before we can install the nut-client
yum --enablerepo=* install epel-release
yum --enablerepo=* install nut-client.x86_64
Now we need to tell NUT that we want it to listen to an existing NUT Server, in other words, we want to be a “client”.
Now that NUT knows it will be retrieving information from another network server, we need to tell it what network server to “MONITOR”. You will need to modify only 2 variables in the file /etc/ups/upsmon.conf but take a look around because you can tweak how the NUT Client responds by modifying the settings in this file. For now, lets just tell NUT where to retrieve its information from.
MONITOR (NAME OF YOUR UPS)@(PFSENSE IP) 1 (USERNAME) (PASSWORD) slave
You probably already have a SHUTDOWNCMD in your configuration Just add a comment “#” to the start of the line and add the one provided above. Speaking of the SHUTDOWNCMD, you will notice that we are calling a specific script. This script can be downloaded here.
chmod +x xen-shutdown.sh
!!! I wasn't able to perform the next step because the service started to fail afterwards!!!
The shutdown still works. I try to figure out a solution and add it here.
So on a power failure, the NUT Master sends a message to all subscribed NUT Clients, and the NUT Client shuts down based on its configuration. Wonderful Now our Xen Guests can shutdown, and so can our server. But what happens when we power them back up? We need to make sure that NUT starts on our XenServer.
To do so create a new file, /etc/systemd/system/nut-monitor.service and add the following to it.
Description=Network UPS Tools - XenServer Shutdown
Now that we have a system startup script in place, lets make sure it runs on start up.
systemctl enable nut-monitor.service
systemctl start nut-monitor
Execute this command in the Shell of your pfSense:
This will simulate a power cut!!!
upsmon -c fsd
If you have any questions ask me below.
There is one problem: you have to reattach the USB to the VM after every host reboot!
Thanks for the response. There are no logs in the guest VM, just a cutoff in /var/log/messages.
I am using XO, and using Delta Backups, but they were not happening on the 24th consistently for the last 3 months, only last month did a backup happen on the 24th. They're scheduled on Mon., Wed., and Fri.
Yes, this is a very odd thing. I've been running Xen VMs since 2007 and have never seen this kind of thing.