I did indeed make both changes at the same time.

The status of the backup this morning is completely normal (even on ADDS VMs).

I think that the forced shutdown in order to correct the status error caused a problem during the next delta. Why only on ADDS VMs? I can’t explain it.

I had no errors on these VMs at that time.
(Especially since I have another full backup job that doesn’t cause any problems).

It's empty. Why ?

So, as planned, I changed the snapshot to “normal” in the backup job and performed a forced shutdown on the replicated VMs.

This morning, the job status is “successful,” but two VMs (both of which have the ADDS role—this may be a coincidence) are showing this warning:

The type is still delta despite the warning message.

For alle the other VM, the backup seems ok.

Unfortunately, I need to have a CR job that works because we have a constraint this weekend.
However, I'm available to provide you with logs if necessary.

I could let you know if changing the status of the replicated VM (from suspended to forced shutdown) has an impact on the backup chain. (with normal snapshot).

Thank you for that answer.
I will make the following changes:

• Switch the snapshot to normal
• Turn off replicated VMs
• Lanch the job

Is there any documentation with details about the different snapshot modes (Normal, with memory, or offline)?

Thanks.

Hello,

Any answers to these questions?
This morning, the backup didn't run correctly (the first delta backup after yesterday's full backup). For your information, this is a delta job that has been running perfectly for months. I simply added the CR.

For your information, we have not changed the status of the CR VM; it has not changed.

Here are the errors

Thanks for this first reply.

So how restart a VM create :

• with a CR job
• with the snapshot with memory
• and keep the backup chain healthy?

For now, I'm using the "With memory" option because I think it's the best choice for reliably restoring VMs such as an AD or a SQL Server database. Am I wrong?

Hello,

We are currently testing a scheduled CR job to an SR on an xcp-ng host.
This backup takes snapshots with memory.
The VMs backed up to the SR are therefore in a suspended state.
When I try to restart the VM using the “Start a copy” option (to avoid breaking the backup chain), I get a message stating that the virtual machine is in a suspended state but should be shut down. Two questions:

• I assume that if I shut it down, I lose the benefit of suspension?
• Will the backup chain be affected if I change the VM’s state?

Thank you

Thank you.
So this host will have a separate network/storage partition since it will be in a dedicated pool?

Yes, the connection to this host should be quite good.

If I lose XOA on my master host, what is the procedure for start these replication VMs? From another XOA or Xo Lite? Once the incident is resolved, is it possible to merge the replication VM with the original VM?

Hello,

We have two hosts in a pool with 'classic' backups (Backup and delta).

I would like to mount a DR/CR plan by adding a third dedicated host of the first two in order to store the VMs ready to start.
His independence (but I may be mistaken) would allow him not to be subject to a failure of the master host.

How to add it in XOA without putting it in the same pool?

Basically, what are the best practices for this configuration?

Thank you,

For information :
The downgrade change nothing.
The only solution was to reinstall xcp with the upgrade option (even if it was up to date before the bios update)

If we go back to the original problem, the latest version of the Bios changes nothing (there is no information about the BIOS on the Host page)

@olivierlambert said in 2CRSI BIOS update not available:

I'm not aware of this problem, have you changed the mode (BIOS vs UEFI) after BIOS update? I think we already tested a BIOS update and it worked well. Let me ping @AtaxyaNetwork about this.

Hi,

Have you had any feedback on this issue?

Thanks

@olivierlambert No, i changed nothing.The boot Mode is UEFI (see first screenshot).
I will check if a downgrade (if it's possible) fix this issue.

Hey,

We have update the Bios to the latest version.

There is a new problem.. We cannot boot now.
The boot device 'XCP-NG' is missing

There doesn't seem to be any problem detecting disks in the BIOS (or clusters).

Do you know this problem ?
2CRSI support seems to say that the only solution is a reinstallation

Thanks and happy New Year

Ahah ok, it's fun!
I need to find the procedure for the update and I'll let you know.

Thanks!

@MathieuRA I think, i found a problem.
I have just check the Bios version during the boot of my host.
The Product Name is also NULL

It seems to be a factory configuration problem (2CRSI)

What type of information do I need to find in the product name (or Manufacturer Info on XOA) ? Just Server model?

@MathieuRA
Here is the information :

Hi,

The output is "True".
My two hosts have acces to the json script.

My servers are not 1.44gg but 1.4SR which is clearly visible in the script output (by the way, there's an error -> there is an extra "_" at the end of the last URL)

Is it possible to modify the script to work with the 1.4SR model?

Thank's

@gthvn1 I just have the latest version of XOA (latest branch).

Hop : f12475ad40702dd8ae2817d4446c360d380edda4d846a1bfee3ec88853e7060c /etc/xapi.d/plugins/ipmitool.py