@Dashrender The current title is perfect (didn't see the change before)

By the way you can rename the topic title

@Dashrender In any case, it's not a "full" direct push: it goes through xo-server, since we can't tell XenServer to push itself a VM somewhere. In fact, export is always working in "pull": a HTTP handler is opened by XAPI, and listen for HTTP GET request.

This is valid for everything, xe, XenCenter, XO export through your browser, XO backups etc.

So it's not really an overhead with your browser, xo-server just act as a proxy to deliver your file (so if you don't have network bottleneck between you and xo-server that's OK:

XenServer --> xo-server --> browser

A backup will do:

XenServer --> xo-server --> remote point

But as I said, in any case, xo-server will do a HTTP GET.

The main bottleneck is Gzip compression first. If you disable it, that's another potential bottleneck: the XAPI HTTP handler speed.

Note: the possibility to ask XAPI to push a backup somewhere will be discussed with the XAPI team during Xen Hackathon. IDK if they could do something, but I'll be at their office to explain the issue, in front of the whole dev team.

In any case Gzip is extrremly slow but give a good compress ratio. I already told XAPI guys to give a flag to use LZ4, which is much faster but a little bit less efficient on the compress ratio side.

Anyway, disable it and redo a test.

See the Gzip process sucking up all the CPUs in XenServer. I'm betting on far better perfs without it.

Do you have a NFSv3 on the server? Copy/pasting the line displayed in xo-web in the console works?

As you can see, you are not the first: https://bugs.xenserver.org/browse/XSO-44

Import/Export speed is a nightmare

Disabling compression is a good first step to avoid GZIP in XenServer (which is known to be slow).

Hi,

This is not a XO limitation, but a XenServer/XAPI limitation. I heard Citrix is working on it to improve it.

Made around 50 migrations today, no issues, but I'm making mainly those tests on next-release. I really can't explain why this "duplicate" VM is appearing with an UUID coming from nowhere...

This means your VM doesn't have tools installed or your guest doesn't support "soft" calls to suspend/shutdown it (but hard reboot/shutdown always work, that's like pulling the power cord).

Can you open a issue with specifications about how you would like to have this handled? Thanks!

Getting a big fat XML. Yay.

IDK what's inside those data ^^ Do you have the output of these to understand exactly what's inside this backup?

Hi,

What kind of host metadata you would need to backup?

https://github.com/vatesfr/xo-server/pull/232/files

@Danp Continuous replication is not using vhd-util from XO: the merge is done on XenServer side.

Can you fetch the last version and try again?

Investigating.

@JaredBusch said:

My guess is because you are trying to use replication as a backup and that is not what it is?

You cannot point replication to a share. You have to point replication to storage on another host. That is why it is a replica.

If you have NFS storage mounted on another host as available storage, I would guess it would show up there.

This.

Can you please use our forum for those requests? I can't be everywhere at the same time and my answer time would be far longer outside XO forum.