OVA Import Never Finishes

planedrop

Been digging on this one for a bit now.

I have an OVA file which I exported from XO and am now trying to re-import it just as a test.

The import icon spins forever (gave it 2 hours, it's a 2GB roughly VM).

I can see the VM listed in XO and it is prefaced with "[Importing...]" and if I try to start it I have to force start it.

After that, it won't boot but instead just goes to the BIOS and hangs. And it seems the OVA file is still locked by Chrome as if it's still in use, but there is no reason it should be.

I've tried this a few times and I also noticed that, even though I get the OVA file, in Tasks on XO it still shows VM OVA Export with 0 progress and it won't go away until the toolstack is restarted.

I did the same with an XVA file and it was flawless so seems to be specific to just the OVA files.

olivierlambert

Hi,

We need more details to help you. Are you on XO or XOA? Are you sure you are up-to-date? If XOA, which release channel?

planedrop

@olivierlambert Yeah happy to provide that.

I'm on XOCE in this case and I am fully updated. This is actually a brand new Ubuntu 20 VM that I just installed XOCE on this morning.

planedrop

I also get the start operation error on the VM if I try to start it.

Andrew

@planedrop You can try the XVA format, I have had better luck with that. I have had OVA export/import take a long time.

As for the Forbidden Operation, that's a normal safety feature as you are starting a backup VM that's a duplicate. You can force start it or make a copy and then start it.

planedrop

@Andrew Yeah the XVA format worked perfectly, I was mostly curious to test the OVA format since the export of such is a relatively new thing.

As for the warning message, I suppose that still pops up even though it was an export/import and NOT a copy due to it being the overall same VM? I renamed it and all that just in case.

I did go ahead and do a force start but I'm getting to the BIOS and nothing else.

Maybe there is something super obvious that I'm missing here, been a pretty long week and I'm tired lol.

planedrop

Nevermind @Andrew and @olivierlambert I figured it out, it was something stupid that I was missing lol. Forgot this VM was a UEFI based one and it defaults to BIOS.

Swapped to UEFI mode and it came right up!

Thanks as always for the incredibly fast replies here on the forums, love it!

planedrop

I will still add that Chrome seems to lock the file though if I keep the XO tab open, I have to close that tab and re-open it to release the file lock so I can wipe the file.

Andrew

@planedrop @olivierlambert
I does seem like something is wrong with OVA import/export (on current XO commit a1bcd).

I start the OVA Import.... the task imports the drive data in 30 seconds and finishes.... the "Import" button continues to spin and does not finish. The new imported VM is there but still named "Importing...".

Export has a problem too as the data is exported (downloaded) but the export task continues to run (stuck at 0%).

No errors in the logs.

olivierlambert

Can you check on which commit are you? Are you sure you waited enough for the import? (so the exported worked well?)

Any error message in logs or xo-server output?

edit: ok just missed your last answer. Check also xo-server output

planedrop

@Andrew Yes this is exactly what I am seeing as well. It fully works but things get a little hung up.

Restarting the Tool Stack fixes the stuck task and closing and re-opening the tab unlocks the file for the import.

@olivierlambert My commit is a1bcd from the About section.

Andrew

@olivierlambert I guess the OVA export worked correctly. The download finished correctly. If I do it again I get the same file size. I waited for things to go as long as they wanted. So I'll say, yes, it worked as well as it could.

The VDI Export task finishes (as the download of the data finishes), but the VM OVA Export task continues to sit there. Also the download is very slow (as others have stated), even on the same LAN (100kBytes/sec).

The only error I see that may be related is from 15 minutes before so I'm not exactly sure to what it is related:

May 13 16:29:39 xo1 xo-server[448]: 2022-05-13T20:29:39.927Z xo:main WARN WebSocket send: {
May 13 16:29:39 xo1 xo-server[448]:   error: Error: The socket was closed while data was being compressed
May 13 16:29:39 xo1 xo-server[448]:       at /opt/xo/xo-builds/xen-orchestra-202205131152/node_modules/ws/lib/sender.js:410:21
May 13 16:29:39 xo1 xo-server[448]:       at /opt/xo/xo-builds/xen-orchestra-202205131152/node_modules/ws/lib/permessage-deflate.js:325:9
May 13 16:29:39 xo1 xo-server[448]:       at /opt/xo/xo-builds/xen-orchestra-202205131152/node_modules/ws/lib/permessage-deflate.js:455:7
May 13 16:29:39 xo1 xo-server[448]:       at afterWrite (node:internal/streams/writable:497:5)
May 13 16:29:39 xo1 xo-server[448]:       at onwrite (node:internal/streams/writable:477:7)
May 13 16:29:39 xo1 xo-server[448]:       at Zlib.cb (node:internal/streams/transform:202:7)
May 13 16:29:39 xo1 xo-server[448]:       at Zlib.processCallback (node:zlib:611:8)
May 13 16:29:39 xo1 xo-server[448]:       at Zlib.callbackTrampoline (node:internal/async_hooks:130:17)
May 13 16:29:39 xo1 xo-server[448]: }

Tool stack restart on the pool master cleared out the stuck tasks.

olivierlambert

Adding @florent in the conversation

planedrop

@Andrew Wanted to go ahead and add that it didn't seem slow to me to do the export, it was only 2GB, but still. It did take a bit to ramp up speed though, I got 4.5KB downloaded and then it sat there for a few minutes, but once it started downloading more data it sped up and the whole 2GB download was done in like 1-2 minutes, not crazy fast but not super slow either.

I will try and test this with a bigger VM when I get the chance to see how it behaves.