Do you have any boot trace or serial so we can understand where it stops?

@olivierlambert @olivierlambert said in OVA import failing: Keep in mind the file has to flow from your browser toward your XOA, then to your XOA to your host, which might use another network share itself. If your XOA could mount the place where you have your OVA directly, you could use upload-ova utility (see https://github.com/vatesfr/xen-orchestra/tree/master/%40xen-orchestra/upload-ova#usage ) to send them directly. Going to look into that, thank you.

Yes, it's just for testing if it's related XAPI bottleneck (stunnel)

Yep, that's the best solution Have a nice day.

@julien-f is aware of the problem, he's working on getting proxy fully independent on the network connection. Can you check why the connection between XOA and your proxy is interrupted? Is there any reason you have in mind?

@olivierlambert Ok, so I ran the command without the grep on destination and source (grep doesnt find anything.) I couldn't see the UUIDs of the VMs I want to migrate anywhere on the destination list. The two VMs I am trying to migrate on the source: [17:54 xcp-ks ~]# xe vm-list uuid ( RO) : bb75397d-980e-9fd8-aa63-c8b13c38bd3e name-label ( RW): Win10 Print Server power-state ( RO): halted uuid ( RO) : 5c27c06b-0995-73c6-bb2d-d442db947ee8 name-label ( RW): WIN10 Print Release Terminal power-state ( RO): halted My VM list on the destination: [17:50 xcp-city ~]# xe vm-list uuid ( RO) : 3b6f09b1-8d47-7478-b72e-2dd53788a57e name-label ( RW): MLS-VM-Ubuntu_2020-06-29T04:01:46.552Z power-state ( RO): halted uuid ( RO) : 280cf6a8-7c56-9323-0148-ce048a4081d4 name-label ( RW): WServer2019-PublicFacing_2020-05-17T16:51:13.772Z power-state ( RO): halted uuid ( RO) : 9eff99d0-a16b-d91d-5f41-d36e24357ec8 name-label ( RW): WServer2019-HiSec_2020-06-15T07:59:15.309Z power-state ( RO): halted uuid ( RO) : d5896b2d-bb75-262f-9d55-668315419306 name-label ( RW): MLS-VM-SMTP power-state ( RO): running uuid ( RO) : 826f34bd-aaaa-2bdd-61fe-2511f843d713 name-label ( RW): WS-PubNet_2020-06-29T04:57:59.732Z power-state ( RO): halted uuid ( RO) : a55b24bc-02b9-4dcd-a7fc-05f8f107660e name-label ( RW): Control domain on host: xcp-city power-state ( RO): running uuid ( RO) : 2617b8ed-a087-e257-4ca2-0e44de5b8ee9 name-label ( RW): WS-MSAdmin_2020-06-26T03:03:27.154Z power-state ( RO): halted uuid ( RO) : 08d020c9-6314-9c6b-3792-dba8f1d2f15d name-label ( RW): WServer2019-HiSec_2020-06-14T06:48:02.042Z power-state ( RO): halted uuid ( RO) : 6d98ba66-09ad-3754-ef14-ee4a8035717a name-label ( RW): WS-PubNet_2020-06-26T05:16:37.397Z power-state ( RO): halted uuid ( RO) : d513e984-5ef6-ad7f-8ae0-18c483718f23 name-label ( RW): WServer2019-PublicFacing_2020-05-22T12:57:51.293Z power-state ( RO): halted uuid ( RO) : 522e6da7-25e7-22bb-dbda-1584a5c851cf name-label ( RW): XO CE Kubuntu power-state ( RO): running uuid ( RO) : fe1f5255-4779-7510-e657-5e259032bf6a name-label ( RW): MLS-VM-Ubuntu power-state ( RO): running uuid ( RO) : 84876754-324b-aedd-fea4-7e358d0dd74c name-label ( RW): WS-MSAdmin power-state ( RO): running uuid ( RO) : a0921e9a-bb0e-6555-e1ea-8546afa3dd55 name-label ( RW): WServer2019-HiSec_2020-06-15T03:32:08.343Z power-state ( RO): halted uuid ( RO) : 6a1d28d8-f30a-74e8-3ad9-9a1fe6b37e13 name-label ( RW): WS-PubNet power-state ( RO): running uuid ( RO) : 2662852b-8a39-07f9-7a2c-de7e85c1ab76 name-label ( RW): XO CE Kubuntu_2020-03-16T00:16:43.655Z power-state ( RO): halted uuid ( RO) : b1390286-0569-e935-b922-89aa7aaf670c name-label ( RW): [XO Backup Backup XO CE Kubuntu] XO CE Kubuntu power-state ( RO): halted uuid ( RO) : 0da8353c-7ce9-543c-1448-ecaa3df96573 name-label ( RW): WS-HiSec power-state ( RO): running

I said that for both statements: It's not Xen fault if it doesn't work on top of KVM, but Xen accessing some virt features that aren't correctly exposed by KVM. I'm not blaming them, nested virt is a mess to properly code and test. Consider this as experimental everywhere. I missed the "for me". But it's also vague, I don't know your constraints/what do you want. Also, I think I heard that some users made it work with Virtualbox, but it might also depends on your hardware. As I said, nested virt is a mess, and sometimes, some hardware works better than others (or even some VBox versions).

Can you create a GitHub issue gathering our elements here to get a simple but complete "specification"? https://github.com/vatesfr/xen-orchestra/issues/new

Thanks, that help!!!

To get the complete speed, just take a look at XOA network stats while the backup is happening in… Xen Orchestra

It seems I got a kernel panic for some other reason with 5.4.21. It's all working now, thanks.

So on our servers, the C-STATES was already disabled. We are following another lead: to upgrade the linux Kernel to 5.4 (see https://bugzilla.kernel.org/show_bug.cgi?id=204071). We won't be able to test before sometimes but I'll let you know. If this is the problem then this is not related with XCP-ng. Sorry for the late feedback.

@stormi Edit: Thank you! Got it working and looking good. Troubleshooting non related to Netdata. I remember I change my upstream DNS to Quad 9 recently (1 week ago) and I just change it to Cloudflair (1.1.1.1) and it was the problem. Look like Quad 9 (9.9.9.9) does not like the Mirrors for some reason.

We don't have any other report of this issue elsewhere. Double check you are on the completely latest XO version, and alternatively, try with XOA on latest channel.

There's an small update you should see now in your XOA. Install it, and you'll be able to bind the license to this new XOA

Yep, there's basically nothing. It's more SMAPI related than XAPI in the end.

Please take time to read carefully the previous link I send. If you can't spot it, re-read it slowly, you might see this link: https://xenbits.xen.org/docs/unstable/support-matrix.html

XAPI is being modified as we speak to support storage domains.

@moussa854 ok bruh....soooo.... you might want to check your bios settings and make sure VT-d is enabled or if you are on a AMD rig IOMMU or AMD-Vi is enabled. I feel so dumb and overlooked this and after enabling VT-d on my rig everything worked as expected.

It should work, yes.