Please take time to read carefully the previous link I send.

If you can't spot it, re-read it slowly, you might see this link: https://xenbits.xen.org/docs/unstable/support-matrix.html

It should work, yes.

Hi @mauricio_hps

This is a XCP-ng forum, please try with XCP-ng 😉 https://xcp-ng.org

@talbaror by the way you can find discussion about all this, and what users have tried, etc., at:

https://xcp-ng.org/forum/topic/2496/xcp-ng-nfs-timeout-values-and-storage-node-active-standby-failover https://github.com/xcp-ng/xcp/issues/334 stormi created this issue in xcp-ng/xcp open Use NFS hard mount instead of soft mount to avoid RO VMs (or offer option)? #334

5% sounds too much for me, but I'll check it in some populated pools (with host's cpu below 80%) to have a better idea.

@Otis2772 Where is your time synchronization coming from? Time differences can be caused by a slew of things including power settings (VM or not), CPU availability, networking connectivity, etc. Are they all the same OS or different OSes?

64 hosts tops. But in general, people tends to use around 16 to 20 hosts max in a pool.

Don't forget about support 😉

Check dmesg in the VM

I am back to the office and I am troubleshooting different settings and connection setups. I appreciate all your input. The issue is configuring the right NIC0/NIC1/WAN/ and LAN. Once I am done I post my setting. Thanks again for everyone.

Wow, didn't know it was possible to violate those rules!

Yep.. that did it... started it on the older host, and can now migrate it backwards and forwards with on issues...

Thanks Olive... as always.

Peter.

@r1 @olivierlambert Hello!

There is nothing in any logs at all, on either the Dom_0 or Dom_U at the time of the crash, the journal on the Dom_U stops updating at the instant of the freeze and only resumes after it has been destroyed and re-started.

We are in the process of moving sites to HVM, that is an ongoing part of our plan, 1 down...

We've not tried running a screen session, but that is a very good idea, and we'll do that - thanks! I don't believe we've tried running in debug mode either, so will pursue that too.

Thanks for the advice, I appreciate it - I know it isn't anything even remotely related to your work, but as an XCP-ng user personally, I wasn't sure where else to try.
Thanks, Mark

Also you might use http://irqbalance.github.io/irqbalance/ to help "spreading" the load on various CPUs.

In XO: Advanced tab of the VM. Enable nested virt, then boot the VM. That's it!

In FreeNAS. exports file you should have fsid=123, with a unique number for each exported path. If not it can cause a problem if the nfs server is rebooted while the pool is up.

https://linux.die.net/man/5/exports
https://www.suse.com/support/kb/doc/?id=000017897

The stale mounts are in xcp-ng.
But this is just a theory.

During the power outage. Did all xcp-ng hosts and the FreeNAS as boxes go down? How did you boot up? You wrote you set up fresh servers?

Okay, this makes sense, thank you for the clarification. The reason I was asking I've been having crazy issues with xcp-ng on my server with VMs crashing all the time on boot etc and have been trying to troubleshoot and just wanted to look into this as I've done every other thing I can possibly think of. thanks again!

Yes, for this generation of CPU, you can't run ESXi superior to 6.5.

@johanb7 I had the same problem in the past with FTDI-based USB device. I could see it in Xen host, but not in VM. I've spent many evenings trying to make it visible in VM, but with no luck though.

I don't know why, but seems that some USB devices won't attach to VM.

@gofm not sure on windows but on linux the walltime is written in UTC to the CMOS when you shutdown or when you explicitly call hwclock command. the time written in the virtualized CMOS should contain an offset to the host clock so when the VM start it read the host time plus the offset. I suppose that if you disable the time sync in windows, set the time and reboot you will come up with a correct clock.
I have no link to point you at, this is just a sum of things I remember but may be dated and/or wrong still if you can reboot your Windows VM could be worth testing.