Continuous Replication - problem on coalesce

Gheppy

I cloned the result and started the VM, it can't find the boot hdd.
I mounted the resulting disk in another VM with a good operating system, the result being a disk that is not formatted and not initialized.

olivierlambert

Hmm weird, have we broke anything on master regarding that @julien-f ?

Anyone else could try to reproduce this behavior?

Gheppy

the problem start with commit 9139c5e9d6b4306ba4078e6fa128a36f65417792

olivierlambert

Thanks, we are taking a look right now.

olivierlambert

We try to spot a problem but we couldn't reproduce.

Can you describe the problem functionally speaking? (not from what's happening behind in your opinion)

Gheppy

I have the following configurations:
1.
An XCP-NG server, on which I have a VM with an application (a windows) and a VM with XOCE,
On the server I attached a NAS (synology) on iSCSI with LVM.
Every day there is a backup with CR and once a week a full backup

An XCP-NG server, on which I have a VM with an application (a windows)
and A server on which I have a VM with XOCE, connected to each other on the 10gb switch.
On the second server I attached a NAS (TrueNAS core) on iSCSI at operating system level and then mounted in XCP-ng as local ext3.
Every day there is a backup with CR and once a week a full backup

The behavior is difficult to detect on LVM, always having the same size.
This behavior can be seen on ext3 because there you can see vhd and its size.

I will make some print screen with the configurations

Gheppy

XOCE is on Ubuntu 20.04 and is installed according to the documentation.
At the moment everything works as before with commit 65e62018e6aeabf64cf9def01ad043dfbdff5c18

In log everything seems ok, only the physical result ( vhd ) is wrong

to understand the abbreviations:
RAID - is the local raid of the server
iSCSI - is the connection to the NAS
iSCSI-ext - is the connection to the NAS at the level of the XCP-NG operating system and mounted in XCP-NG as local-ext

first configuration
photo1

photo2

photo3

second configuration
photo1

photo2

photo3

photo4

photo5

olivierlambert

But what behavior? It's still unclear to me what is the actual problem

Please describe the problem itself. You can't boot a cloned replicated VM?

Gheppy

No, I can not.
The result of a clone is a VM with two disks without content and partitions, one where the operating system should be and the second where the database should be.
I have attached the two disks to a VM with a functional operating system ( windows ) and both appear unformatted and uninitialized.
What two disks have as the occupied space on the XCP server's ext partition ( after clone ) are the only the value of the last CR has.

olivierlambert

If you try to boot directly the replicated VM (force boot it), does it work?

Gheppy

No, I will make a video with the problem for you to see

Gheppy

On the link below is the video with the problem.
Server is with all hdd on local controller, no iSCSI

https://ncloud.neandria.ro/index.php/s/xDtKKMwGoqqAYiE

olivierlambert

Thanks for the video, it's more clear now

And you don't get this issue at all with the commit before?

Gheppy

yes, I have no problem with commit before.
For now I'm on commit 65e62018e6aeabf64cf9def01ad043dfbdff5c18 and all is ok,