Changing disk UUID after disk replacing in xcp-ng with Xen Orchestra

[top-secrett]

ISSUE TYPE

• Improvement Request

CLOUDSTACK VERSION

Any

SUMMARY

Hello. I use CloudStack with XCP-NG and I am in search of the best backup solution.
All software, including Xen Orchestra, can restore a backup as new VM with a new disk UUID. After that I detach disk from original VM and attach the recovered disk. VM is working fine, but CloudStack cannot manage the disk due to the new disk UUID.
If I replace disk UUID in CloudStack databases, disk management will be performed normally
Example:

update volumes SET path="24c34f4d-35b3-400a-92e3-c27ba154aabf" where id=2283;

Maybe in new version of cloudstack you can add function of manually or automatically changing disk UUID from Cloudstack?
Or import VM from XCP-NG function.

[neil3333]

Hi, I may have the similiar situation, I tested the third-party backup solution for Cloudstack, every time I shutdown the VM and reboot it, the backup fails, with backup server reported cannot find corresponding Virtual Machine, I guess it may caused by VM uuid changed by Cloudstack.

[top-secrett]

@neil3333 yes, it is a promlem too. I think you should open new issue

[DaanHoogland]

this sounds like you want to write a plugin for the backup and restore framework.

Normally a VM uuid would not change in cloudstack. What may happen is that you get a new VM in Xen, but in the cloudstack DB it should not have changed.

[top-secrett]

@DaanHoogland after stop and start VM in CS, VM's uuid changes in Xen. All backup solutions for xcp-ng cannot backup VM after that. It is a big problem, because there is no any full compatible backup soft for xcp-ng with CS

[DaanHoogland]

@DaanHoogland after stop and start VM in CS, VM's uuid changes in Xen. All backup solutions for xcp-ng cannot backup VM after that. It is a big problem, because there is no any full compatible backup soft for xcp-ng with CS

I understand, so these backup solutions run out of bounds from cloudstack, right? cloudstack is unaware and on start recreates the VM (this is how it always works on xen/kvm) What is your backup solution?

[top-secrett]

@DaanHoogland We use XenOrchestra and Vinchin

[DaanHoogland]

@DaanHoogland We use XenOrchestra and Vinchin

/me googling ;)

[top-secrett]

@DaanHoogland should I open new issue?

[DaanHoogland]

@DaanHoogland should I open new issue?

no, I would refine the issue here to be a better specification. We don't need an extra issue. What do we need, either

• adding support to the B&R framework for Vinchin
• dealing with VM restarts (possibly controlled by a setting)

ACS is not aware of out of bounds backup solution and making it aware is making them no longer out of bounds. We (sd in you) need to define a good functional design to how this should work. Next we can decide if it is worth the effort. I would not call it an improvemnt request depending on the way forward. Are you familiar with the B&R framework?

[top-secrett]

@DaanHoogland I didn't deal with B&R framework. I know that problem is in changing VMs uuid, how to solve it without writing plugin I have no idea.
Tomorrow I will explain problem to Vinchin developers, maybe they will find resolution.

[top-secrett]

@DaanHoogland Vinchin didnt find any solution. Perhaps in a next release you will add feature that disables VM reconfiguration?

[DaanHoogland]

@DaanHoogland Vinchin didnt find any solution. Perhaps in a next release you will add feature that disables VM reconfiguration?

If we can figure out how to do that in a clean way, sure. However disks/volumes are first class citizens in cloudstack. allowing a new disk to have the same UUID as prior one is a no go. I am not sure if this can be fitted into the current B&R design (cc @rohityadavcloud ?)