Create VM from Template not creating VM
-
@DustinB So I just confirmed, that when I try and create the VM from the template I created with Fast Clone turned off, its creating another template and not a VM.
-
@SchaffnerOnline So this is the changelog for the build you're using (which is the latest)
It mostly revolves around the load-balancer plugin, do you happen to have Load-Balancing configured?
-
@DustinB I do have that load-balance plugin activated. Though I wouldn't think that doing a VM creation would cause to become a template instead of a VM. I have 3 identical hosts with XO running on a separate mini PC.
-
@SchaffnerOnline yeah neither would I, I'm looking for any frame of reference that might cause this.
-
@SchaffnerOnline I'm unable to reproduce on my XO version, I also have XOA but I gotta run. I get a successful VM that boots.
-
@DustinB I have tried to reproduce it, no luck, it worked like a charm.
I took a working VM, shut it down, converted it to the template, went to add VM, chose the template, renamed, clicked create, and a few sec after I got a functional VM.
On this commit:Then I fired up the commit with the broken self-signed cert but it worked there also.
-
@Bub When you created the VM from your template, was "Fast Clone" enabled or disabled. Sounds like fast clone was enabled, as that works for me too and it only takes a few seconds to create. When you turn "Fast Clone" off, it will take a few minutes to create the VM and that's when it fails.
-
@SchaffnerOnline I just confirmed my "fast clone" was checked!
I ran another test with "fast clone" unchecked just now.
After clicking Create it took a few minutes but then it seemed like my XO disconnected from the master as I got the "Welcome to Xen Orchestra!" page to connect a server.
A few minutes later it came back with a new VM which I created from the template.Checked my templates, and there is no new template there.
I tried twice, one with local storage and one with NFS SR both with the same outcome. both vms were booting up with no problem.
-
So I've been doing some more work to see if I can figure out this issue. And so far no luck.
I'm running a 3 Host environment, that all 3 hosts are identical, HP EliteDesk 800 G3 SFF, Intel i7-7700 CPUs, 64GB memory in each. There is QNAP NAS that is providing NFS storage for the VMs and an NFS ISO storage location. My XCP-NG hosts are running version 8.3 Beta 2
My XO is running on a Mini PC, XO is compiled from sources, and updated today to commit 1b515.
When I create any Windows VM and then convert it to a template. When I then try to create a new VM from that template, instead of creating a VM, it creates another template. What I have found interesting, is that when I try to create this new VM and I give the Disk a new name, when it completes and has created template instead, the name of the disk is the same as the source template and not the new disk name that I gave it when I was filling out the info for the new VM.
When I create a Windows VM from the template I made, but using the "Fast Clone", then it seems to be working correctly. Its creating a VM and the disk name is the new disk name I wanted for the new VM.
I think, but I can't confirm that I think this issue may have started with the changes from this issue:
https://github.com/vatesfr/xen-orchestra/pull/7388If someone can confirm using the same XCP-NG version and an updated XO from sources, or some guidance on where to look in logs that may tell me why instead of a VM being created from the template, its creating another template.
-
If someone else reproduce the same problem, please let me know.
-
214b8
can't reproduce. -
@julien-f I created a new VM to build XO from scratch and when I went to create a new VM from my Windows 10 Template, it just created another template. But I also deployed an XOA (Version 5.91.2), and then asked it to create the VM from my Windows 10 Template, it worked correctly. I upgrade the XOA to the latest channel build (Version 5.92.1) and it worked correctly there as well.
-
@julien-f, I think I might have figured out the issue. I run my entire system on a 1Gbps network. When copying the template to a new VM, it takes about 10-12 minutes for the base Windows 10 VM to copy. We are getting a timeout, it appears based on some testing I did, that if it takes longer than 5 minutes, it times out and thus the template that is created doesn't get the final steps and turned into a VM. Here is the log when I tried to create a new VM from a Debian template I created, but I had put a large file (10 GB) which made the template to VM creation take about 7 minutes. I happened to see an error box pop-up in the upper-right corner and pulled the log:
vm.create { "clone": false, "existingDisks": { "0": { "name_label": "Deb-12-Template-20G", "name_description": "", "size": 107374182400, "$SR": "7b7c9d36-6410-ca59-16c6-84e4922d00ee" } }, "name_label": "Deb 12 Template 20G", "template": "56901d17-0bc8-f48f-9055-9103c303d381", "VDIs": [], "VIFs": [ { "network": "c89c9d93-c08e-6b51-1ba7-cddfc1a85a0e", "allowedIpv4Addresses": [], "allowedIpv6Addresses": [] } ], "CPUs": 2, "cpusMax": 2, "cpuWeight": null, "cpuCap": null, "name_description": "", "memory": 4294967296, "bootAfterCreate": true, "copyHostBiosStrings": false, "createVtpm": false, "destroyCloudConfigVdiAfterBoot": false, "secureBoot": false, "share": false, "coreOs": false, "tags": [], "hvmBootFirmware": "bios" } { "name": "HeadersTimeoutError", "code": "UND_ERR_HEADERS_TIMEOUT", "message": "Headers Timeout Error", "call": { "method": "VM.copy", "params": [ "OpaqueRef:5c4b2c34-c7b6-fa8b-b855-2b9664e11ad5", "Deb 12 Template 20G", "" ] }, "stack": "HeadersTimeoutError: Headers Timeout Error at Timeout.onParserTimeout [as callback] (/root/xen-orchestra/node_modules/undici/lib/dispatcher/client-h1.js:635:28) at Timeout.onTimeout [as _onTimeout] (/root/xen-orchestra/node_modules/undici/lib/util/timers.js:20:13) at listOnTimeout (node:internal/timers:569:17) at processTimers (node:internal/timers:512:7)" }
-
@SchaffnerOnline Thank you, I'll fix the timeout error soon!
-
-
@julien-f Hi Julien, I updated my XO this morning and tested, unfortunately, the same issue still exists. I've attached the log file.
-
@julien-f Wanted to check on this as the fix didn't correct the issue.
Thanks
Mike