XCP-ng 8.3 public alpha 🚀
-
Great relief, I was beginning to have doubts about myself
-
@jhansen said in XCP-ng 8.3 public alpha
:Great relief, I was beginning to have doubts about myself
So, it works but ONLY for snap taken during a backup, not a manual snapshot
-
@olivierlambert
I'm trying that this weekend.
Thanks in advance. -
@olivierlambert
Here as promised a test of the [NOBAK] function.About the SR:
NVME Raid
Size: 2.4 TB used of 5.5 TB total (2.9 TB allocated)About "SRV-Test" VM:
0 "SRV-Test" "NVME Raid" 50GB /dev/xvda
1 "[NOBAK] SRV-Test Drive" "NVME Raid" 1.5 TB /dev/xvdbManual snapshot takes both drives and ignores the [NOBAK]
Backup via Xo works, only the first drive is backed up.
You can follow this under TASKS in the XO.
Under "File Restore" in the XO there are no data for the second drive.So beautiful - so good. The idea would actually be to back up a server with very large drives partially.
So I change my VM to the following:
0 "SRV-Test" "NVME Raid" 50GB /dev/xvda
1 "[NOBAK] SRV-Test Drive" "NVME Raid" 1.5 TB /dev/xvdb
2 "[NOBAK] SRV-Test second test drive" NVME raid 2 TB /dev/xvdcMy SR looks know:
NVME Raid
4.4 TB used of 5.5 TB total (4.9 TB allocated)Exactly the same result as the first test, both with the manual snapshot and with the XO backup.
Actually, the manual snapshot should not work at all, because there is not enough space on the SR to include all the drives, but due to thin provisioning it works because the drives are almost empty.Now I'm filling the drives with data so I'm sure there isn't enough space on the SR for a full snapshot of all the data.
As expected, I get the error message "The specified storage repository has insufficient space" when taking a manual snapshot Everything is understandable since the manual snapshot saves the entire VM and there is no space for the 3.5 TB snapshot on the SR.
Now I make another backup with XO, which previously only backed up the 50 GB of the first drive.
UPS ... After a few seconds, the error "SR_BACKEND_FAILURE_44(, There is insufficient space, )" and the backup was aborted.So, XO seems to first test whether a complete backup/snapshot can be created with all drives and then backs up the 50 GB of the first drive.
In my opinion a bit suboptimal because it doesn't solve the problem to always have twice the space on the SR as you used, even if I only want to back up the system disk of a VM with a few GB, for example.
Conclusion of the test:
A) Manual Snapshot with only part of drives ([NOBAK]), does not work.
B) Backup with XO with only part of the drives ([NOBAK]), works, but only if there is enough space for a complete snapshot of the VM on the SR.Hope you can use with my little test for something.
-
Do you mean that the VM snapshot space is computing with all disks despite we decided to ignore one? If that's the issue, then it's a XAPI bug/something that we should add in the first place
-
@olivierlambert
Exactly, it looks like the snapshot of the entire VM is always calculated first. If there is enough space then only the selected drive is taken in the backup, if not the Backup is aborted.
In other words, only if you can take a manual snapshot of the VM, XO's backup will then only backup the selected drive.
It would be good if the backup only checked whether there was enough space for a snapshot of the selected drive. -
Okay so it's not on XO, but on XAPI then. @psafont and @BenjiReis I assume it's a basic check in VM.snapshot that's not doing the right computation since we can ignore disk
-
@olivierlambert
Seems like that to me too. Let me know if you found a solution. I leave the test VM on my Xen server so that I can test again at any time. -
@olivierlambert Snapshot is in essence a VDI clone, I don't see any checks being done before the filtering for ignored VDIs is done. And that is done pretty early on, not sure why there are operations affecting virtual block devices from ignored VDIs: https://github.com/xapi-project/xen-api/blob/master/ocaml/xapi/xapi_vm_clone.ml#L416
-
I will try to reproduce it locally with
xeand keeping you posted, thanks! -
Okay so it works with
xe. I'll see with XO doing a backup now. -
I can't reproduce the bug with XO. Here is my test setup @jhansen :
1x VM with 2 disks:
- 1x 10GiB disk on a SR with plenty of space
- 1x [NOBAK] 900GiB local LVM disk (thick) on a 1TiB SR (you can't snapshot the disk without SR disk space failure)
I did a delta backup with XO and it worked.
-
@olivierlambert
I will make a retry of the test.
Is the drive empty or filled with data
If the disk are empty it works for me to. -
@olivierlambert
by the way: which version of XO are you using, not that I am using an older one and that the cause is there.
My drives are also local LVM so should be "Thick" too. -
XOA on
latest -
@olivierlambert
Hello,
I created a new SR and installed a new VM and
installed a new XO.
The last one was definitely the answer.
It's working now, so as far as backup via XO goes.
I tested everything extensively, with different VM, SR and different drive fill levels, all ok.
A manual snapshot won't work, but that's what it is.
My old XO installation, unfortunately I didn't write down the version, was from January. Also, when I reinstalled, I switched from stable to latest as you indicated.
Unfortunately, I can't say whether the pure stable update or the change to latest was the solution.
But the main thing is a happy ending.
Greetings Joerg -
I did some testing with the 8.3 and it all went smooth except for one thing. We did a backup of a VM on 8.3 and if we try and restore it to version 8.2 I get the error
"IMPORT_INCOMPATIBLE_VERSION"which makes sense and it's just a lab system so nothing critical. Is there a way to bring it back to 8.2 or should I update the rest of my lab to 8.3?
-
What kind of backup? Delta should work (CR and warm migration too). Only basic backup with XVAs aren't able to be restored on an older version (like many things in XAPI world, it's only forward compatible)
-
This was a full backup not a delta so that makes sense. I think I need more of my lab servers to be on 8.3 so I can do some more testing. I did not find any issues and nothing broke using it so I need to try harder.
-
Great
In general: go for delta backup. It's faster (by a decent margin) because XVA generation is not really optimized on XAPI side. Even if you compare a first delta (so a "full") vs an XVA, it might be 30 to 50% faster to generate.
