@cmanos No problem, glad I could helped.
As Olivier also pointed above, it's not an issue anymore when using QCOW2 which is currently in beta, so hopefully it's only a short workaround
I can imagine that a fix could be to send "keepalive" packets in addition to the XCP-ng export-VM-data-stream so that the timeout on XO side does not occur
Yes, they are created either:
on demand for users
when we need in XO 6
Now, XO 6 is becoming the main driver for new endpoint as the UI is providing more and more features.
@carloum70 Disk migration isn't supported by the provider yet. What you can do it's only ignore the changes to the sr_id of a given disk.
For example for the first disk:
lifecycle {
ignore_changes = [
disk[0].sr_id
]
}
You can also manually do the migration in XO and then after edit your HCL to update the sr_id with the new ID. It should do the trick.
@olivierlambert Ok cool, iSCSI is on its own Network on a Direct connection with Multipathing. In the past i have had problems with VMs going in Read Only Mode.
Thanks for your reply.
That's the issue. Why they don't have it is the problem/mystery.
Try to check if new replicated VMs got it. If not, I would check if you are correctly up to date.
@joearnon The browser javascript logs may give you useful information about what issue happened during the import as seen from XO's side.
However the disappearing SR issue makes me think you should look at XCP-ng logs, in particular /var/log/SMLog for storage-related logs and /var/log/daemon.log.
@jsawyer77 Did you follow the documentation when building XO? If not, then what process did you use?
Also, check to see if libvhdi-utils is installed and which version.
@olivierlambert You inadvertently solved this one, too, n parallel with @tony .
So, basically, as suspected, a template is nothing more than populating stuff that's in the basic and advanced webforms on Orchestra, anyway.
@julien-f said in Warnings showing in system logs following each backup job:
We'll see how many reports we get regarding this
One more from me. But it was actually your tech support that discovered them in conjunction with a ticket we have open.
@olivierlambert said in Backup failure: HTTP request has been canceled:
It's a problem when XO tries to get address from your srv02.xxx.com.
It just makes no sense that DNS would be an issue on this network. I guess if XO momentarilly looses connection during DNS lookup it could cause this problem. I've noticed sometimes that the webui of XOA sometimes can show red ? if I start live several live migrations. Maybe unrelated?
