Topics created by CJ

@CJ the fix has been merged and will be available in the next release.

@Danp That's the same image I referenced but with everything at a single site. I'm looking for details regarding the hosts and SRs. In the documentation that's all hidden inside that green XenServer XCP-ng box.

My concurrency is only 1 right now because I'm trying to find my bottleneck. Regardless of what it's set to, I'm stuck at ~150MBps for the whole backup job. But that's just what the UI reports. Looking at the network stats I see different things moving anywhere from ~50MBps to over 500MBps.

@norrisson I don't believe so. I think I just built a new VM to replace it.

@olivierlambert @stormi is the one who helped me find and fix the issue. I just wanted to update my old thread in case someone else happened across the problem until it gets fixed in XO.

FWIW, a filter of !"SR_type":"udev" would remove both DVD and Removable Storage entries

@CJ It may be easier to ensure reliability and prevent other possible issues from happening. I'm not an expert when it comes to the underlying code, but I would take an orphaned VDI over say some form of corruption or something like that.

I'm guessing a little if I'm being honest, but cancelling it mid transfer might break some things, could leave a partial VDI that is locked for example, etc...

@olivierlambert I have not. I looked at it last year but haven't checked on it since.

I just tried it now and I remember one of the reasons I haven't used it. The self signed certs give my browser fits and I have to open each host up in a new tab to accept them by IP.

The console UI seems to work the same in XO lite as in XO. There doesn't seem to be any way to copy and paste.

Roughly, a snapshot is created and transferred while all new blocks written are mirrored to the destination. When the entire snapshot is created on destination, the VM is frozen few ms to finish consolidating the mirrored blocks into the destination snapshot. And then the memory is transferred.

@CJ Gotcha, I see, yeah either way I think having more control over backups would be useful, never really a downside to that haha.

@julien-f Awesome. I was mostly concerned that I was tagging the VM incorrectly as I didn't want it to backup. I'm happy to report that the tag worked correctly. 🙂

Looking through things, I think I've determined part of the reason for the larger backups. When I turned on memory snapshots that means that the memory is now getting saved as a separate VHD and then transferred.

Is it possible for the backup job status to provide more information regarding memory vs actual disk parts of the snapshots? For example, the cleanup task now shows two unused VHD, which I assume is the separate memory and disk VHD for the snapshot.

@florent I'm not sure what's going on, but the incorrect size warning seems to be intermittent now.

Jan 22nd - No size warning. Half of the VMs cleaned 1 unused VHD, the others had 0.
Jan 23rd - Size warning and 1 unused VHD cleaned on half of the VMs. Others had neither.
Jan 24th - Same as Jan 23rd.
Jan 25th - Size warning and 2 unused VHD cleaned on half of the VMs. Others had 1 unused VHD cleaned.
Jan 26th - No size warning. All VMs cleaned 1 unused VHD.

It doesn't seem host related as each host had VMs in both categories. Hope this helps. Let me know if you need any more info.

It's completely unrelated 🙂

Dear @CJ,

We have added an article in our documentation that explains why full exports sometimes happen unexpectedly. You can find this article on this page.

I hope it clarifies, do not hesitate to tell us your opinion!

@CJ Please test the branch email-local-hostname which make the local hostname configurable and keep me posted.