I finally got my lab updated and the two vms started, so far so good. Stats data is present, the first time I've seen any of my hosts pull 100% CPU. Hosts are little HP T740 thin clients with AMD V1756B processors and 64GB of ram, in a 3 host pool.
Sorry I can't bring more detail, not really doing work on my XCP lab right now, and lots of shake up around tech. space at work.
I decided to burn my lab down because of some trouble and wanted to start fresh to isolate any problems I may have created in the past. Wiped the disks, built a new NFS share ready for work, installed the XCP-ng OS and configured networking for the management interface on the local machines, all normal stuff. Went back to my desk and logged into XO Lite on each machine, using console --> xsconsole I was able to get all the hosts into a pool, and add an ISO and NFS SR, all seemed to work.
Went to the New VM to create a simple Debian vm on which I intended to host XO-CE from sources. Typed the info in, chose the Debian image from my ISO SR, the rest of the config as normal. Uncheck the boot after creation box, and create.
Click on the VM to bring the console up, then click power on... UEFI loader comes up, and ... Can't find the boot disk. Tried another iso that I knew was capable of EFI boot, same.
Realized I was trying to start in EFI, made a new one in BIOS mode, this one worked but now my screen shots are messed up so I'll probably have to go through and delete stuff with a different XO and go back to grabbing images of the process to write up "for the next guy".
Other than this small issue, it's working and doing it all from XO Lite. Yes still a bunch of missing features, but I know you are working on this. I just wanted to try things this way on this fresh build and see what I could get done from local console and XO Lite.
Nothing really to add, my 3 host Intel production pool updated just fine. The load balancer is always a little weird, but I'm sure it is calculated based on CPU and RAM assigned to each VM, where I split things up based on workload.
It's a small system, and the real workload is handled by 3 Windows VMs so I tend to split them up onto one of the three hosts.
I may get to my lab in the next couple of days, but it isn't doing work so testing is kind of pointless right now. The only thing "doing work" is a VM with XO from sources.
BTW, the ram increase made zero difference in the VDI migration times.
I may still change the ram for each host in production, but I only have like 12 VMs right now and probably not many more to create in my little system. Might be useful if I ever get down to a single host because of a catastrophe. Currently running what it chose for default at 7.41 MiB, roughly doubled that in my lab to see what might happen.
Just got my VMware lab started so all this other stuff is going to back burner for a while. I will say I like the basic ESXi interface that they give you, I can see why smaller systems may not bother buying VCenter. I hope XO-lite gives us the same amount of function when it gets done (or more).
I was looking for a way to mark this solved, can't find it.
I haven't moved things, but after migrating my big lab to my mini-lab, I'm confident that the warm migration is the way to go. It was fast and seamless as long as you have the right network adapters set up. I had to fool with one of my networks to make a VM function, but that was certainly something I overlooked while setting up the mini-lab. A little testing before moving the VMs should make this go easily if using the old servers is the option for this project.
@coolsport00 You actually referenced my post, so I referenced yours as backup to the condition still being present. I think we just need to wait for them to finish making XO-lite what they seem to intend it to be, I think it's going to be good and I think they are doing a great job so far.
Also, I have a post somewhere about the UEFI not working from XO-lite, maybe they can be merged?
Having what is essentially XCP-NG Center from a browser would be nice, no more need to install something on a Windows machine just to get some basic stuff set up until you get a full XOA instance running. Yes I know you can just grab the demo with a single command, but sometimes you want to configure a few things first.
Tom Lawrence has a bit hub with all the artwork that he uses, you might want to find that and check it out.
Documentation is the first thing to get pushed to the back burner, same in my area, same in my larger IT department. Never enough time to document things correctly.
I need to get going with Netbox and see if I can make this speed up what I want to document.
I'll try to remember to upgrade a couple on Monday, been meaning to test the latest drivers on some less critical VMs.
It's likely that both Microsoft and Xen tools are a combination of the fix, I doubt XCP-ng has anything to do with this issue. And I never had time to check the XCP-ng Guest tools for Windows to see if this happened, but I'm guessing no or not tested. All my hosts are now on XCP-ng 8.3 and I don't see any point in testing 8.2 since it is EOL.
And that said, I'm no farther along in my Server 2025 testing, too many other things going on to think about it right now. If I have time I need to burn the vSphere portion of my lab down and install either Harvester HCI or Windows Server for Hyper-V. Broadcom is just (seemingly) going out of their way to prevent people like me (or us) from learning their products and using them in our labs to further that goal. I've explained this several times to VMUG Advantage managers, but they seem so tied up in clawing out some continuing relationships with Broadcom that they will not "rock the boat". I've said these things in Broadcom webcasts as well, always a run-around with no answers.
Sorry for the rant. All that said, eagerly awaiting XCP-ng 9, unfortunately I think the Alpha or Beta may wait until XO 6 is finished (just a guess). The updated kernel brings with it some storage changes that I really want to test, NFS nconnect=XX being one of them to see if I can get a little better performance to/from the disks. ESXi default was nconnect=4 and the VMs were slightly faster to/from their disks (all thin provisioned). The 4k "block" size and smaller is what I want to improve in all this.
Nothing really to add, my 3 host Intel production pool updated just fine. The load balancer is always a little weird, but I'm sure it is calculated based on CPU and RAM assigned to each VM, where I split things up based on workload.
It's a small system, and the real workload is handled by 3 Windows VMs so I tend to split them up onto one of the three hosts.
I may get to my lab in the next couple of days, but it isn't doing work so testing is kind of pointless right now. The only thing "doing work" is a VM with XO from sources.
I got my production system updated yesterday, no issues or oddities with the RPU.
I'm still surprised by how much faster the VMs migrate host to host than they did with 8.2.x, it's like a 4:1 or 5:1 change on my production system. Haven't had time to fool with my lab and see what's what.
Once in a while my rpu will do this, then I handle it manually. Been happening more often since the 8.3 upgrade, but not enough to post about it yet since we are only a couple of updates into the LTS. Still watching though and will probably do this patch on wednesday.
I mentioned waiting for the management agent because that's already a function of checking your backups, so they have part of that puzzle in place.
Best way to implement this from XO would be to wait until the management agent comes up and then move on to the next VMs in the boot order.
I'll have to check out the cli method and see what's involved, there are a few VMs I want to boot in order if the power goes out, things like get the AD VMs up and running so DHCP and DNS are working before other stuff gets booted.
My system is small so I don't have things like the "traditional" LAMP stack with separate application, DB, other VMs so I've never looked into this aspect. But it's right on the surface for VMware and a lot of people are going to be looking for this functionality in one way or another. The VMware drag and drop makes it easy for a Junior level admin to configure a vApp to handle this type of requirement.
@coolsport00 You actually referenced my post, so I referenced yours as backup to the condition still being present. I think we just need to wait for them to finish making XO-lite what they seem to intend it to be, I think it's going to be good and I think they are doing a great job so far.
I have not had time to work on this, and my lab changed significantly, had to spend a bunch of money to move it to a new rack and that rack has been disconnected for months so no real work in XCP or vSphere and learning to migrate VMs from vSphere to XCP which was one of my big intentions.
But a recent post confirms that this "oddity" of trying to create a UEFI VM from XO-lite is still present. I'd bet money that this gets fixed before or when the full release is provided. https://xcp-ng.org/forum/topic/11227/boot-new-vm-to-iso-in-xo-lite
Workaround is to either click the button provided to download XOA, or install Linux and XO from sources in BIOS mode. Then you have the full XO to work with to bring everything else up the way you want it. I see it as a minor annoyance right now, not really a bug or problem.
Also, I have a post somewhere about the UEFI not working from XO-lite, maybe they can be merged?