I never said THAT was impossible, as long the OS kernel started, you can use whatever drivers you like. I was just answering the fact PVHVM was a real mode since the start, and it's not. You can't have a PVHVM template, it doesn't make sense (unless you have already an OS installed).
That's all I said 🤷 You are moving the goalposts every time.
I was able to make NUT work with XCP-NG. I used and followed the instructions in this post.
On issuing the command:
[21:56 xenserver1 ups]# ./xen-shutdown.sh
All VMs shutdown EXCEPT for the Xen Orchestra. I tried remove and reinstall Xen Tools
apt install xe-guest-utilities
I'm on Ubuntu 18.04
Is there something that should be done with Xen Orchestra? Like I said, all other VMs shutdown quickly and properly. I only have Ubuntu 18.04 and one instance of FreePBX. FreePBX shutdown properly too.
Update: it seems that after 5-10 minutes (not sure yet as I haven't timed it), the entire XCP-NG does shutdown but not sure if it was a forced of graceful shutdown on the VM running XO.
@asai Thanks for the response! Not only do I have the same messages but the C Drive was wiped (almost like every file was deleted except those which were open, the server has 6 other drives which weren't affected). I'm suspecting an issue with the Storage Repository because it's the only drive on that repository. I do have a weekly backup that runs on Sundays through Xen Orchestra. So extremely odd that it happened on the 24th, I was only googling the error message from the log! Ugh!
I ordered a new server ($$$$) which I'll transition all the VMs to and then I'll wipe and reload the current one and test/validate it from scratch since I don't trust it at this point.
The State field lists 6 states for a Xen Domain, and which ones the current Domain is in.
r - running The domain is currently running on a CPU
b - blocked The domain is blocked, and not running or runnable. This can be caused because the domain is waiting on IO (a traditional wait state) or has gone to sleep because there was nothing else for it to do.
p - paused The domain has been paused, usually occurring through the administrator running xm pause. When in a paused state the domain will still consume allocated resources like memory, but will not be eligible for scheduling by the Xen hypervisor.
s - shutdown The guest has requested to be shutdown, rebooted or suspended, and the domain is in the process of being destroyed in response.
c - crashed The domain has crashed, which is always a violent ending. Usually this state can only occur if the domain has been configured not to restart on crash. See xmdomain.cfg for more info.
d - dying The domain is in process of dying, but hasn't completely shutdown or crashed.
So when you live migrate a VM, Xen will decrease memory dynamically to the minimum. If you didn't plan correctly dynamic min to a value that's OK for your system, you might have memory problems for your operating system (eg if you system can't survive with less than 4GiB RAM and the dynamic min is set to 3GiB, this will cause problems!). So planning is important.
There's some edge cases also in migration when you have to tell Xen about memory management when you grow/reduce amount of RAM. But it works generally OK if you took care of dynamic min as I said.
Thank you very much for your valuable advice. I will never run any third party application directly in xcp-ng. I meant inside a VM that will run on the xcp-ng hypervisor, like Xen Orchestra is.
So, I need to create a VM and set the correct network and then run nmap -sT -P0 -p 443 xo-domain to test the connection.