I don't think so, I see this message before the update
Posts made by Gheppy
-
RE: Continuous Replication storage issue
-
RE: Task not showing
It seems that the task failed 5 minutes a go, with the error >> HTTP connection has timed out <<, I restarted the task and now everything is displayed.
Thank you
-
RE: Task not showing
This task is an XOCE CR, which appears to run. I see disk growing on backup SR.
It's just that I no longer see it in the task and I no longer see the estimate time to finish.
Except that is not displaying the tasks, everything seems to work.
I will probably find out later what is really happening, now it is at 80% transferred by my calculation. -
RE: Task not showing
It is not the task is not running, it is (on the first 3 photo), but it disappear from task list.
The setting is for 3 days.
-
RE: Continuous Replication storage issue
I have the same message, but the CR is ok. I tested and it starts with no issue
-
Task not showing
After 24+ hours of transfer nothing is displayed in task tab. Yesterday the transfer was displayed in tasks tab.
I'm on commit e48bfa2c88d5e33fff44e9b004f43041166375e0I have attached what is displayed below.
Backup is running
It runs for more than 24 hours
Server has activity
But nothing in the tasks tab
-
XOCE Warning on build
Hi,
I compiled version f4bf56f159db7cc6020060252fadd4a91f17641f
and I get the warning beloweslint-config-standard@17.0.0" has incorrect peer dependency "eslint-plugin-n@^15.0.0"
-
RE: Slow backups (updated XO source issue)
Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz
-
RE: Slow backups (updated XO source issue)
This is on testing environment.
Version of XOCE
Transfer without setting
Transfer with setting
-
RE: Slow backups (updated XO source issue)
From what I've seen:
- when nothing is set, XOCE makes the transfer using a single vCPU to the maximum and the rest up to 5% max . The maximum transfer being up to 23Mb/s
- when the setting exists, XOCE uses all 12 vCPUs between 30% and 45%. The transfer is between 145Mb/s and 350Mb/s.
In both cases, the transfer is done on a 10Gib LAN and I use http mod for connecting to Servers
-
RE: Slow backups (updated XO source issue)
I had the same problem. I have a CR that until applying the setting took up to 5 days (I interrupted the backup to see where the problem is) to make a backup, now with the setting it takes 12 hours.
But the stability of the transfer is better by at least 15% compared to commit afadc8f95adf741611d1f298dfe77cbf1f895231.@Andrew said in Slow backups (updated XO source issue):
@julien-f The time it takes for CR to run seems to be back to normal with the added config
[backups.vm.defaultSettings] validateVhdStreams = false
I have Concurrency set to 4.
There's more than enough local ethernet bandwidth between machines and XO is running on the pool master. There's lots of cores and memory for XO. But with
validateVhdStreams = true
there seems to be some single threaded issues with node because it uses 90%-120% cpu.With
validateVhdStreams = false
the CPU usage is about 110%-150%, so still some single threaded issues but a lot less as node is able to use more than one core (but not all of them).Also... I see the warning that appeared from an earlier commit but does not cause problems:
transfer Suspend VDI not available for this suspended VM
-
error when modifying backup metadata
XOCE commit d7da83359f007236784f2644213b288e24759823
I can't modify a Pool metadata backup, I get the error below.
I can create it without problems, but I can no longer modify it.schedule.set { "id": "b7bbc539-36a2-469b-9dd7-ee521a5a7dc0", "cron": "0 1 1,15 * *", "enabled": true, "name": "", "timezone": "Europe/Bucharest" } { "code": 10, "data": { "errors": [ { "instancePath": "/name", "schemaPath": "#/properties/name/minLength", "keyword": "minLength", "params": { "limit": 1 }, "message": "must NOT have fewer than 1 characters" } ] }, "message": "invalid parameters", "name": "XoError", "stack": "XoError: invalid parameters at Module.invalidParameters (/opt/xen-orchestra/packages/xo-common/api-errors.js:26:11) at Xo.call (file:///opt/xen-orchestra/packages/xo-server/src/xo-mixins/api.mjs:65:20) at Api.#callApiMethod (file:///opt/xen-orchestra/packages/xo-server/src/xo-mixins/api.mjs:397:19)" }
-
RE: Continuous Replication on a large VM
Hello,
I have windows 2008R2 with SQL 2008R2 and a database of 4.3Tb, I use CR successfully (for 2+ years now), I do the transfer on a LAN link in http mode.For a transfer on a 1G LAN, you will have a transfer time of 60-72 hours. You must set in XCP-ng the time to kill the task for 72 hours minimum, in /etc/xapi.conf line 306 set: pending_task_timeout = 259200 # 3 days in seconds.
For a transfer on a 10Gb LAN you will have a transfer of 7-14 hours.
I don't use snapshot with memory but the recovery was ok, I had an event. -
RE: Restore Delta Backup with Full Backup created afterwards
Backup Delta always refers to the last Full Backup. So the ones before the Full Backup can no longer be restored on a backup made after them
-
RE: SR space occupied by backup snapshots
@manilx
I chose ext4, precisely so as not to waste unnecessary space -
RE: SR space occupied by backup snapshots
base copy it's the reference, it's that vdi that contains all the information before snopshoot.
If you use the LVM format it is normal to be like this, if you use the ext4 (vhd) format it will only be the difference.
Because you don't have space, use the ext4 format for SR -
RE: Backup with local usb hdd attached - SR_OPERATION_NOT_SUPPORTED
I tested the same thing with XCP-ng 8.3, it seems to work. I can't wait for it to be ready for production. The first impression is very good.
-
Backup with local usb hdd attached - SR_OPERATION_NOT_SUPPORTED
I have a virtual machine with the following configuration: sda - with OS, sdb - with data and sdc - hdd usb attach. As in the photo below.
And I want to make a backup only to sda and I receive the era below. How to configure the backup so that I don't have this error?
-
RE: A "socket" was not created for HTTP request before 300000ms
It is working for me to, thank you