@olivierlambert Yep.

Here's the video of the test - https://www.youtube.com/watch?v=tiVdR74PNjw

@olivierlambert Just ran the test on both XOCE and XOA, and looks like it takes about 8 minutes to get to 8.6GB downloaded before the transfer rate drops to zero. I also observed the transfer rate drop to zero at 8.3GB for a short while before picking back up and stalling at the 8 minute mark.

I made a video of the test - it's uploading to my YouTube channel now, when it finishes I'll update this post with the link.

@olivierlambert I didn't time it. I'm leaving home to drop the kids off at school, then off to work afterwards. I'll run it again and time it and report back.

@olivierlambert You were right. Looks like while we were troubleshooting this issue (about two days ago), I ran an xe vm-export command, though it failed, enough of the XVA file got created and that was sufficient to fill the partition up.

This didn't become obvious until I opened XCP-ng Center today and saw the following alarm:

Disk Usage for Control Domain on server 'WGSDAC-SV-VMH01' has reached 92%. 
XCP-NG's performance will be critically affected if this disk becomes full. 
Log files or other non-essential (user created) files should be removed.

So I deleted the culprit file and freed up the storage space, and now the export is downloading. However, it's timing out before all the file is downloaded. It gets all the way up to about 8.6 GB downloaded then the transfer rate drops to 0 B/s.

I suspect this is due to the file being deleted on the host before the transfer completes. Is there a quick way to increase the timeout?

From XOCE Instance:

From XOA Instance:

@Danp Unfortunately, I don't see any errors in the log of the VM or on the Host. Within the browser's console, the only thing that comes up is the following:

Fortunately, when I attempt the operation via the xe cli, it results in the following error:

Yet the XOCE pool tasks showed that it completed successfully:

@Danp As requested:

My Use Case:
I am performing a Proof-of-Concept within an air-gapped environment at work. One of tests I'm performing is to validate the VM Export/Import functionality. So I exported this VM from the air-gapped lab environment I've setup at work and brought it home to test if I could import into the pool running at my church (on a physical host). However, it suffered a catastrophic drive failure and I ended up having to rebuild it. With the rebuild done, I was able to import the VM successfully. Now I'm attempting to export it so I can take it back to work and import it, to complete my testing.

As requested, neither clicking the Download VM link nor the OK button result in a successful download. I'm using Chrome, and have also tried Edge. I don't have Firefox on my PC, but I could install and test if you think it's necessary.

@Danp Just got in the car to drive to work. I'll try doing what you've asked when I get to work (in about an hour).

@Danp Yes, understood - but a short period of time is a rather vague statement, don't you think?

I tried doing the download immediately after I copied the link, failed each time. So I decided to wait for the export task to complete then execute the download - it also fails. Do you know where the xva file is stored temporarily? Perhaps I can access the file system and move it to another location before it gets deleted.

I recall that when I exported this VM from the test lab at work, I experienced a similar issue and I simply paused the download (within the browser) and then resumed it, and that's how I got the transfer to start. Unfortunately, I wasn't tracking the precise timing of that, as it seemed rather random. I also tried that on this system, to no avail.

Also, does the temporary file get stored on XO or on one of the hosts?

@Danp Of course, thanks for replying.

I go to the VM, and click on the export button at the top-right (screenshot #1). Then I set Type = xva and Compression = Zstd (screenshot #2), then click OK, copy the download link and wait for the task to complete, then I paste the link into a new browser tab and execute.

SCREENSHOT #1:

SCREENSHOT #2:

My Environment:

• Xen Orchestra, commit c7657 (Master, commit c7657)
• XCP-ng v8.3

Good-day Folks,

I am attempting to export a VM and not having much success downloading the exported file. The export tasks runs for about 10 minutes and appears to have completed successfully (screenshot #1), however, when I attempt to download it I get an error (screenshot #2).

Anybody seen this before and have any thoughts to share?

SCREENSHOT #1:

SCREENSHOT #2:

Good evening all,

Just a quick update. It's been a couple of days now after the rebuild and everything seems to be humming along fine, so I believe this topic can be marked as resolved. I can confidently conclude that this wasn't an XCP-ng issue, although the error message seems a bit misleading.

Unfortunately, looks like my issue was ultimately a failed disk in a RAID 0 array. The errors XCP-ng was throwing were definitely misleading.

I just rebuilt the array as RAID 10 and have reinstalled XCP-ng v8.3. I should have the entire virtual infrastructure rebuilt in no time, before services this weekend.

@bleader I know, right! Glad this isn't a major production system - mainly for my church and primarily running infrastructure services (DHCP, ADDS, DNS, etc.). Fortunately, I have a physical DC which has the DNS role as well, so I can do without DHCP while I troubleshoot. If need be, I can static critical systems.

Now to your suggestion, I tried to access alt+F2 and alt+F3 from iDRAC and neither were recognized, so looks like I may have to make a site visit and do it directly from the console.

However, it's interesting that after leaving the system alone in that error state, it eventually went into emergency mode (see screenshot below).

@julien-f Hmm, that's a bit disappointing that there isn't much you guys can do to help. No worries, I'll keep testing. My AD environment works fine, since the accounts in question are not locked and are being used daily. The only place they're failing is in XOCE or XOA.

It's gotta be something with how the library is handling characters in either the username or the password. I'll keep testing until I can find a repeatable pattern.

Thanks to both you and @olivierlambert for the help thus far.

@olivierlambert I am very grateful for the assistance thus far. I definitely understand that your time is money, and I'm willing to approach my Church Leadership with a request to purchase the Enterprise License. However, do you offer any discounts off the annual subscription for Non-Profits Organizations? I'd be happy to take this discussion offline if you prefer (kagbasi at wgsdac.org).

Secondly, is this the correct GitHub project for the passport library you mentioned: https://github.com/vesse/passport-ldapauth/issues ? If so, I'll try posting a question there as well, as you've suggested.

@olivierlambert

I had already posted the output of the test-cli.js utility at the beginning of this thread, however, if you want I can do it again just to re-confirm things. Just let me know, thanks.

@olivierlambert

As instructed, I deployed XOA, grabbed a trial license, and updated it to the latest version then tried again; same results. Getting the following error for my admin account (same one I use to log into every other workstation on the network

Code: -32000
Message: could not authenticate user
{
  "message": "could not authenticate user",
  "name": "Error",
  "stack": "Error: could not authenticate user\n    at /usr/local/lib/node_modules/xo-server-auth-ldap/src/index.js:254:15\n    at default.testPlugin (file:///usr/local/lib/node_modules/xo-server/src/xo-mixins/plugins.mjs:280:5)\n    at Xo.test (file:///usr/local/lib/node_modules/xo-server/src/api/plugin.mjs:109:3)\n    at Api.#callApiMethod (file:///usr/local/lib/node_modules/xo-server/src/xo-mixins/api.mjs:417:20)"
}

If I then use one of the test accounts I had created AFTER I started noticing the failed attempts (i.e., after 05/15/2023), it works.

Plugin test
The test appears to be working.

Prior to testing, I logged into the Domain Controller and verified that the service account I'm using to bind to AD was not locked. I'm willing to send whatever screenshots or outputs you need if it helps to get to the bottom of this.

@olivierlambert LOL, of course I did.

I considered the possibility of account lockouts but I've carefully checked each time the test failed and neither the bind account nor the test account were locked.

@olivierlambert This issue still persists. I've updated my XOCE instance; I am currently at the following versions:

• xo-server: v5.118.0
• xo-web: v5.121.0
• Commit: 996ab
• auth-ldap: v0.10.7

Should I file a bug report? (I found a similar issue: https://github.com/vatesfr/xen-orchestra/issues/3846)

lravelo created this issue in vatesfr/xen-orchestra

closed LDAP plugin AcceptSecurityContext error #3846

@olivierlambert Aah, good to know. That explains why I couldn't find any instances of winbind or SSSD...lol.

Anyway, I'm willing to help in any capacity to help further this along. So please let me know if you need me to pull any logs or screenshots, and I'll gladly do it.