Great, node version 18.18.2 seem working again!
Thank you very much
Great, node version 18.18.2 seem working again!
Thank you very much
Dear all,
after upgrade to version 5.125.1 / 5.127.1 the connection to xcp-ng is only stable for a few seconds. After connecting for a few seconds the connection to the server is droped and no reconnection is done. Only "disable" and "enable" in server/settings the connection is stable again for a few seconds. Then dropped again. Any ideas?
The only thing is to think on that script during a major update of xcp-ng to a newer version. Because after installation the autostart.service has to be implemted again.
I don't really remeber about the solution, but assume I deleted the old logfiles too. I did never observe the same failure again.
I'm also running xcp-ng on a Supermicro X11 with a XEON Silver 4210 CPU.
Hi all,
got some weird "crypto_comp_decompres failed" messeges during boot of XCP-ng. Does anyone no if it matters or not? Investigated this for the first time.
Some internet search stated to delete old logfiles in /sys/fs/pstore, but not sure if this helps.
Thanks and best regards.
Just goto your VM -> disks -> button on right side with "boot order" -> boot order can be set by drag/drop between the shown possibilities.
I switched due to SSD replacement and XCP-ng new installation. I didn't think about that switching from ext3 to lvm does also have an effect from thin to thick provisioning
Anyway I found the explaination, here -> "a snapshot on a LVM based SR will double the whole VM disk size!"
But I will think about to switch to ext4 -> topic solved, thank you!!
Yes for sure, but in the past the snapshot didn't stay on the local storage drive with the full volume. Don't know what is different now. I did run delta-backups over a year now without any topics. In the past I used ext3, now using lvm, does this make any difference?
Second issue seem to be that there is now "no remaining space" reported, but the drive has ca. 50% volume free...
ok understand, thank you!
But why is the behavior different? Here is an example what's happening at the moment:
Why is this happening? In previous versions there where no remaining snapshots on the local storage left.
Hi all,
I'm using XO from the sources. After update to 5.51 (xo-server) and 5.50 (xo-web) the "backup NG" is gone, only "backup" is available now.
If I'm runing a daily delta-backup, the delta-backup-files are stored to the remote backup share but the local-storage is flooded with a snapshot-file. The snapshot-file is not deleted and the local-storage run out of capacity.
Can anybody help?
that's relatively easy to explain, only the naming is doubled:
Deleting updates does show no difference, it is never updated, even waiting for some days. Also a reboot does not make any difference.
screenshot from "remotes" in XOA:
screenshot from "storage" of host:
If setting up the share completely new, free space is reported correct. After deleting old backups, free space is only correct in remotes.
unfortunately "start delay" is not working as expected. The function what you marked above is to change the start delay of an existing "vApp". Here is an example of my setup:
The value whould change the "Delay interval" later by XOA, nothing else. Otherwise is vApp feature also not working on my XCP-ng installation, I think it was never really tested.
If you want to implement start delays to your VM's you can follow this guide:
xe appliance-list
#!/bin/sh
xe appliance-start uuid=uuid-autostart-vApp
[Unit]
Description=autostart script for boot VM
After=graphical.target
[Service]
Type=simple
ExecStart=/path/to/your/autostart-script.sh
TimeoutStartSec=0
[Install]
WantedBy=default.target
systemctl enable autostart.service
Editing of boot delay time is then possible via XOA which is already a nice feature at all for "fine tuning" or adapt if new VMs are added to the autostart vApp.
@olivierlambert whould it make sense to open an additional feature request? vApp-implementation was several times discussed with no "final statement" I think.
Dear all,
I've got a suspicious topic about reporting of free space of backup HDDs. First of all my system:
First of all, the vm backup is working as expected, no issues with non-working backups.
About the backup situation:
Issue: remaining free space on backup drive is not reported correct (used / free)
The issue seem to be if removing some backups, the free space is reported within VM page in the right way (also "df" show the right values), but the remaining space after deleting is not reported back to XCP-ng?
Has anyone an idea about the issue?
Any ideas for a more elegant way than to write a script? For my point of view vApps should work without HA mode but unfortunately it doesn't work on my XCP-ng server. Only console/script start of the vApp using
xe appliance-start uuid= "set here the uuid of the vAppp"
is working. But it is again rework for the next XCP-ng version, I think manually set vices in systemd are not persistent through an update. Will vApp supported also in future? there are some discussions about it, if really needed.
my solution for now:
By the way, the start delay feature edits the time delay between two start up groups of the vApp feature.
Is it possible to turn on HA mode on a single machine Setup?
The topic you mention is using vApps or high availability.
I mean this quite new feature "Start delay (seconds), programmed the last days in XO:
Do I need to define a HA mode?
Hi all,
there is a new feature available in XO to set a defined time in seconds to delay the autostart of a VM.
For details about the new feature can be found here: implementation of start delay for VM - issue #3909
It seems the parameter is also set in the VM correctly. Here is a shortened part of result of xe vm-param-list uuid=...:
live ( RO): true
guest-metrics-last-updated ( RO): 20190313T06:38:53Z
can-use-hotplug-vbd ( RO): unspecified
can-use-hotplug-vif ( RO): unspecified
cooperative ( RO) [DEPRECATED]: true
tags (SRW):
appliance ( RW): <not in database>
snapshot-schedule ( RW): <not in database>
is-vmss-snapshot ( RO): false
start-delay ( RW): 240
shutdown-delay ( RW): 0
order ( RW): 0
version ( RO): 0
generation-id ( RO): 6481430157605823834:6102110844557853395
hardware-platform-version ( RO): 0
has-vendor-device ( RW): false
requires-reboot ( RO): false
reference-label ( RO):
I tested with 2 VMs:
VM1: auto-start enabled with 0 seconds boot-delay
VM2: auto-start enabled with 240 seconds boot-delay (see above)
What is happening:
Instead of starting VM1 on boot and start VM2 240s later, it happens that VM2 is starting immediately and VM1 is started an undefined time later. For my point of view, XO implementation is working but there is something not working in my XCP-ng installation.
Can anybody help?