@florent Thank you, I will try this.

@dcskinner @olivierlambert You can read key/values from the xenstore, and write some (from VM to outside), but you cannot write values "in live" from outside the VM to the inside. It is, but XAPI doesn't provide a interface for it. do the guest tools quiesce the filesystems before snapshotting? Tools are aware of a snapshot so you don't have blocks in flight. do the guest tools quiesce the filesystems before snapshotting? Guests kernel are aware, as it is them that are performing a "suspend" on toolstack request (thus quiece filesystems); although "tools" can only observe that the system has been suspended after the fact by measuring side effects, and not orchestrate it. It's because suspend/resume operation doesn't come from "guest tools" actually, but instead from the kernel drivers. So userland tools has no say on it.

@florent I think you meant it was locking the xoa via .tar.gz but not via .zip which seemed to be the case Yeah I just decompressed the restored .zip and checked number of files and size via ncdu, result: "Total disk usage: 194,5 MiB Apparent size: 193,1 MiB Items: 613" In case I can provide more information for investigating this issue, please let me know. Thanks and best regards

I recreate my ZFS pool. But next time or for other stuck with this kind of issue, I think you should start to rename your ZFS POOL. I think the old ZPOOL name stay in XO configuration shadow settings. To rename a ZFS pool, export it with zpool export [poolname] and then import it with the new name using zpool import [poolname] [newpoolname] And then recreate (sr-create) your STORAGE in XO

@olivierlambert Because Andriy did quite a bit of work before this merge, xcp-ng depends on xenserver releasing the package to the clients before we can integrate it into xcp-ng. I'd say we can release the package February at the earliest

@myles3 Hello Myles3. This post is over 20 days old. The issue was since been resolved by support. I dont remember the exact solution off the top of my head with out looking it up.

@Bastien-Nollet many thanks

Hello , we are on it actually , i'm trying to reproduce issue on my side

Yeah, it's not surprising. Ceph S3 implementation is known to be "average" and failure-prone in those cases.

@cbaguzman for information, I made some changes on vhd-cli so in the future we'll get a more explanatory error message when a command failed because we passed an incorrect argument: https://github.com/vatesfr/xen-orchestra/pull/9386 b-Nollet opened this pull request in vatesfr/xen-orchestra closed feat(vhd-cli): prevent using invalid options #9386

@florent "the export is done by one of the host of the pool" How is this host selected ? Is it the master one, the one hosting the VM, or the less busy one in case of shared storage ?

@olivierlambert Client is a proxmox shop and whilst tolerating services running in XCP-ng / XO world they require that if everything fails they have the ability to pick up the pieces in-house. Proxmox has easy import of .ova but very manual process for .xva hence....

We could probably make the doc even more precise. Adding @thomas-dkmt in the loop for that.

Hi! Thanks for the feedback. Can you be more specific? This might be helpful if others would have the same issue Thanks!

still having initial issue, even on latest XOA or XO CE

Great job, worked perfectly! Thank you very much for your fast support!