Veeam and XCP-ng
-
@Tristis-Oris said in Veeam and XCP-ng:
it has nothing to do with xen or provisioning type.
Then what is the root cause of this error below? I mean I can read: 'There is insufficient space.'
As I understand it, if XCP is creating a snapshot on an SR with thick provisioning, it takes up the same amount of storage as the original VDI.
So, I was trapped because of my mistake. But with Veeam and its Linux Agent, I could back it up regardless of insufficient space.
That's what I wanted to convey.{ "data": { "mode": "full", "reportWhen": "failure" }, "id": "1709124708488", "jobId": "72174171-6b1d-40ff-99f9-847f7c577fd3", "jobName": "XXXXX", "message": "backup", "scheduleId": "95f41044-842f-41c0-85ea-b65089b50f7f", "start": 1709124708488, "status": "failure", "infos": [ { "data": { "vms": [ "e06fd66b-9e4d-8df0-71f4-a8508ab677c1" ] }, "message": "vms" } ], "tasks": [ { "data": { "type": "VM", "id": "e06fd66b-9e4d-8df0-71f4-a8508ab677c1", "name_label": "XXXXX_Debian-10.13" }, "id": "1709124711140", "message": "backup VM", "start": 1709124711140, "status": "failure", "tasks": [ { "id": "1709124711152", "message": "snapshot", "start": 1709124711152, "status": "failure", "end": 1709124739540, "result": { "code": "SR_BACKEND_FAILURE_44", "params": [ "", "There is insufficient space", "" ], "task": { "uuid": "825de1b6-967f-c1dc-1415-c852ef6179c0", "name_label": "Async.VM.snapshot", "name_description": "", "allowed_operations": [], "current_operations": {}, "created": "20240228T12:51:51Z", "finished": "20240228T12:52:19Z", "status": "failure", "resident_on": "OpaqueRef:8f335799-cec0-4024-83de-87a5b44839af", "progress": 1, "type": "<none/>", "result": "", "error_info": [ "SR_BACKEND_FAILURE_44", "", "There is insufficient space", "" ], "other_config": {}, "subtask_of": "OpaqueRef:NULL", "subtasks": [ "OpaqueRef:0c1f09de-c43d-4e71-9865-47d7c0dc6b46" ], "backtrace": "(((process xapi)(filename ocaml/xapi/xapi_vm_clone.ml)(line 80))((process xapi)(filename list.ml)(line 110))((process xapi)(filename ocaml/xapi/xapi_vm_clone.ml)(line 122))((process xapi)(filename lib/xapi-stdext-pervasives/pervasiveext.ml)(line 24))((process xapi)(filename lib/xapi-stdext-pervasives/pervasiveext.ml)(line 35))((process xapi)(filename ocaml/xapi/xapi_vm_clone.ml)(line 130))((process xapi)(filename ocaml/xapi/xapi_vm_clone.ml)(line 171))((process xapi)(filename ocaml/xapi/xapi_vm_clone.ml)(line 209))((process xapi)(filename ocaml/xapi/xapi_vm_clone.ml)(line 220))((process xapi)(filename list.ml)(line 121))((process xapi)(filename ocaml/xapi/xapi_vm_clone.ml)(line 222))((process xapi)(filename ocaml/xapi/xapi_vm_clone.ml)(line 442))((process xapi)(filename lib/xapi-stdext-pervasives/pervasiveext.ml)(line 24))((process xapi)(filename lib/xapi-stdext-pervasives/pervasiveext.ml)(line 35))((process xapi)(filename ocaml/xapi/xapi_vm_snapshot.ml)(line 33))((process xapi)(filename ocaml/xapi/message_forwarding.ml)(line 131))((process xapi)(filename lib/xapi-stdext-pervasives/pervasiveext.ml)(line 24))((process xapi)(filename ocaml/xapi/rbac.ml)(line 205))((process xapi)(filename ocaml/xapi/server_helpers.ml)(line 95)))" }, "message": "SR_BACKEND_FAILURE_44(, There is insufficient space, )", "name": "XapiError", "stack": "XapiError: SR_BACKEND_FAILURE_44(, There is insufficient space, )\n at XapiError.wrap (file:///opt/xo/xo-builds/xen-orchestra-202402270007/packages/xen-api/_XapiError.mjs:16:12)\n at default (file:///opt/xo/xo-builds/xen-orchestra-202402270007/packages/xen-api/_getTaskResult.mjs:11:29)\n at Xapi._addRecordToCache (file:///opt/xo/xo-builds/xen-orchestra-202402270007/packages/xen-api/index.mjs:1006:24)\n at file:///opt/xo/xo-builds/xen-orchestra-202402270007/packages/xen-api/index.mjs:1040:14\n at Array.forEach (<anonymous>)\n at Xapi._processEvents (file:///opt/xo/xo-builds/xen-orchestra-202402270007/packages/xen-api/index.mjs:1030:12)\n at Xapi._watchEvents (file:///opt/xo/xo-builds/xen-orchestra-202402270007/packages/xen-api/index.mjs:1203:14)\n at process.processTicksAndRejections (node:internal/process/task_queues:95:5)" } }, { "id": "1709124739553", "message": "clean-vm", "start": 1709124739553, "status": "success", "end": 1709124739561, "result": { "merge": false } } ], "end": 1709124739562, "result": { "code": "SR_BACKEND_FAILURE_44", "params": [ "", "There is insufficient space", "" ], "task": { "uuid": "825de1b6-967f-c1dc-1415-c852ef6179c0", "name_label": "Async.VM.snapshot", "name_description": "", "allowed_operations": [], "current_operations": {}, "created": "20240228T12:51:51Z", "finished": "20240228T12:52:19Z", "status": "failure", "resident_on": "OpaqueRef:8f335799-cec0-4024-83de-87a5b44839af", "progress": 1, "type": "<none/>", "result": "", "error_info": [ "SR_BACKEND_FAILURE_44", "", "There is insufficient space", "" ], "other_config": {}, "subtask_of": "OpaqueRef:NULL", "subtasks": [ "OpaqueRef:0c1f09de-c43d-4e71-9865-47d7c0dc6b46" ], "backtrace": "(((process xapi)(filename ocaml/xapi/xapi_vm_clone.ml)(line 80))((process xapi)(filename list.ml)(line 110))((process xapi)(filename ocaml/xapi/xapi_vm_clone.ml)(line 122))((process xapi)(filename lib/xapi-stdext-pervasives/pervasiveext.ml)(line 24))((process xapi)(filename lib/xapi-stdext-pervasives/pervasiveext.ml)(line 35))((process xapi)(filename ocaml/xapi/xapi_vm_clone.ml)(line 130))((process xapi)(filename ocaml/xapi/xapi_vm_clone.ml)(line 171))((process xapi)(filename ocaml/xapi/xapi_vm_clone.ml)(line 209))((process xapi)(filename ocaml/xapi/xapi_vm_clone.ml)(line 220))((process xapi)(filename list.ml)(line 121))((process xapi)(filename ocaml/xapi/xapi_vm_clone.ml)(line 222))((process xapi)(filename ocaml/xapi/xapi_vm_clone.ml)(line 442))((process xapi)(filename lib/xapi-stdext-pervasives/pervasiveext.ml)(line 24))((process xapi)(filename lib/xapi-stdext-pervasives/pervasiveext.ml)(line 35))((process xapi)(filename ocaml/xapi/xapi_vm_snapshot.ml)(line 33))((process xapi)(filename ocaml/xapi/message_forwarding.ml)(line 131))((process xapi)(filename lib/xapi-stdext-pervasives/pervasiveext.ml)(line 24))((process xapi)(filename ocaml/xapi/rbac.ml)(line 205))((process xapi)(filename ocaml/xapi/server_helpers.ml)(line 95)))" }, "message": "SR_BACKEND_FAILURE_44(, There is insufficient space, )", "name": "XapiError", "stack": "XapiError: SR_BACKEND_FAILURE_44(, There is insufficient space, )\n at XapiError.wrap (file:///opt/xo/xo-builds/xen-orchestra-202402270007/packages/xen-api/_XapiError.mjs:16:12)\n at default (file:///opt/xo/xo-builds/xen-orchestra-202402270007/packages/xen-api/_getTaskResult.mjs:11:29)\n at Xapi._addRecordToCache (file:///opt/xo/xo-builds/xen-orchestra-202402270007/packages/xen-api/index.mjs:1006:24)\n at file:///opt/xo/xo-builds/xen-orchestra-202402270007/packages/xen-api/index.mjs:1040:14\n at Array.forEach (<anonymous>)\n at Xapi._processEvents (file:///opt/xo/xo-builds/xen-orchestra-202402270007/packages/xen-api/index.mjs:1030:12)\n at Xapi._watchEvents (file:///opt/xo/xo-builds/xen-orchestra-202402270007/packages/xen-api/index.mjs:1203:14)\n at process.processTicksAndRejections (node:internal/process/task_queues:95:5)" } } ], "end": 1709124739563 } -
@KPS said in Veeam and XCP-ng:
Application aware backups (active directory, sql, etc.)
So the challenge with this is that currently, there isn't a Windows Signed Driver that is developed by the Vates team for this. You'd be using the driver from xenserver for windows.
This AFAIK hasn't been built for the intention of being backup aware, but for providing an HCL to each guest.
Vates would have to build (either into or their own) guest utility that supports application awareness, which can be done by using the "Driver Development Kit (DDK) 8.0.0"
-
@jbamford said in Veeam and XCP-ng:
there is having something faster and there is something that’s going to be reliable
How about fast and reliable, which is Veeam.
I’m not saying that Veeam isn’t going to be reliable but what I am going to say is that you are at more risk of backups not being reliable
If this is a Production environment I would go with the XCP-ng and XO because if something goes wrong
That's a pretty hot take that Veeam, an industry leading product where their only business is backup and they are damn good at it, is going to somehow be less reliable than the, in my opinion, half-baked solution that exists in XO (while I appreciate the work the team is doing to make this better and better, seriously, I love reading the monthly progress updates, the fact remains). Additionally, the fact that XO requires at least double the provisioned storage of a VM in order to properly coalesce snapshots is a drawback that Veeam doesn't require.
While I agree with the answer someone else gave that this question should be getting asked to Veeam, I think the discussion here is important as it may drive interest to Vates to work with Veeam. Especially now that a lot of VMWare customers that are accustomed to all that Veeam can do are making their way to XO, I'd expect Veeam integration to be at least in consideration.
-
@DustinB said in Veeam and XCP-ng:
Vates would have to build (either into or their own) guest utility that supports application awareness, which can be done by using the "Driver Development Kit (DDK) 8.0.0"
And they should if they want to compete with VMware and Hyper-V. I think a native, completely Vates-controlled guest utility should be high on the priority list. Preferably, one that is automatically distributed by Windows Update (admittedly, I don't know the cost for this) or automatically installed on Linux systems, controlled by a setting at the VM and/or Pool level.
-
@KPS said in Veeam and XCP-ng:
- Instant restore "pendant" is missing --> makes restore speed MORE critical
While not entirely the same, depending on the reason you are restoring, you can restore to the most recent snapshot taken by your scheduled backups or setup a separate snapshot schedule independent from your backups.
To add to your list, XO also can't snapshot (and therefore backup) VMs that are configured with USB passthrough due to an XCP-NG 8.2 limitation. Support has told me this "should be solved" in 8.3, but to me should does not mean confirmed and there is no timeframe that I'm aware of for 8.3 stable release.
-
@tc-atwork that’s not entirely true. I’ve had a few clients that has had issues with Veeam where backups get stuck and never finish until you restart Veeam. When having problems like this, this in my opinion is not good enough for backups.
My previous job had 8 Hypervisors in a Cluster which also used Veeam and backups was getting stuck.
-
@tc-atwork said in Veeam and XCP-ng:
@DustinB said in Veeam and XCP-ng:
Vates would have to build (either into or their own) guest utility that supports application awareness, which can be done by using the "Driver Development Kit (DDK) 8.0.0"
And they should if they want to compete with VMware and Hyper-V. I think a native, completely Vates-controlled guest utility should be high on the priority list. Preferably, one that is automatically distributed by Windows Update (admittedly, I don't know the cost for this) or automatically installed on Linux systems, controlled by a setting at the VM and/or Pool level.
Right, I don't disagree that this should be a very high priority, but as the saying goes "one does not make many". (or something like that).
Using the XenServer driver is likely quite sufficient for many others, and while that doesn't address the needs of everyone it's likely covering the bulk of the paying customers today, which those customers get to vote on different features.
-
J jasonnix marked this topic as a question on
-
J jasonnix has marked this topic as solved on
-
@jasonnix XOA does the primary things Veeam does. Backups, backup copies, full/incremental replication, and file level restores. The only thing I've ran into that XOA can't do is something like restoring active directory objects directly to a domain controller, or native SQL Server level restores without having to restore the whole VM. Those are the only instances where I'd consider running the Veeam agent directly. XOA works perfectly otherwise.
-
For those saying that Veeam does not offer any advantages over native backups of XCP-NG, may I ask (and this is a genuine inquiry not a sarcastic comment) is there a way to restore these backups to another hypervisor?
For us, one of the best thing about using a 3rd party backup solution like Veeam, is that it tend to support other hypervisors and more importantly, the ability to restore backups from one hypervisor to another. This is critical for us because, as has been proven in this Broadcom saga, you can't trust a single solution because one day, you might get screwed. I am not saying Veeam is perfect and I am in no way affiliated with them but in my current situation, I am not beholden to Broadcom's whims because the minute I found out they suddenly jacked our license fees to 4x our current subscription costs, I immediately started looking at other hypervisors but the immediate concern was, well, what do we do with our years' worth of backups? The built-in backup solution of XCP-NG (or the orange contender) cannot read backups made from Veeam or any other backup solution. Well, thank goodness we're using Veeam because Veeam supports other hypervisors, so at least we could restore any of our old backups to the new hypervisor we choose.
This isn't a criticism of Veeam and XCP-NG (I read Olivier's post in the Veeam forum his willingness to work with Veeam to get XCP-NG supported). I am partial to XCP-NG but without support from Veeam, we just can't move to it (and I suspect the OP is in the same boat as us).
-
@MAnon This is a valid point actually, and without additional work, you couldn't just restore to another hypervisor.
Veeam is likely going to properly support XCP-ng.
And for what it's worth, you can use agent based Veeam backups in the VMs and that works fine.
