XenServer 7 has launched!
-
Definitely not
-
-
As a point of reference...
I did a live migration tonight. So, basically the same sort of thing ... copying a VM from one XS to another.
It clipped along at about 65MBps. Took a little over 30 minutes to migrate about 110GB of data.
So, I don't think it is the hardware, or the network, or anything like that. It must truly be some bug in the exporting...
-
You mean a cross pool migration?
-
@olivier said in XenServer 7 has launched!:
You mean a cross pool migration?
From one standalone to another.
-
That's a cross pool migration
There is no such thing as a "standalone" server (despite XenCenter can say, the pool object is always here, from 1 to many hosts) -
@olivier said in XenServer 7 has launched!:
That's a cross pool migration
There is no such thing as a "standalone" server (despite XenCenter can say, the pool object is always here, from 1 to many hosts)Then it is a cross pool migration of two pools with 1 host each.
-
@olivier said in XenServer 7 has launched!:
That's a cross pool migration
There is no such thing as a "standalone" server (despite XenCenter can say, the pool object is always here, from 1 to many hosts)Like an LVM system with just one block device, one VG and on LV taking up the whole space. The layers are still there.
-
@scottalanmiller said
Like an LVM system with just one block device, one VG and on LV taking up the whole space. The layers are still there.
Why would you bring up that reference?
(INSIDE JOKE.)
-
@scottalanmiller said in XenServer 7 has launched!:
I started watching the bug and voted for it. Fourteen people now watching it.
Did you see the posting to that page today?
Two interesting takeaways...
"In terms of status, I can tell you that we have a good idea of what needs doing, having done some investigation into this a few months ago. We're therefore confident that we know how much work this will be, and what risk (i.e. how much testing) it will take to productise."And, maybe of interest to @olivier...
"On backup specifically, my view is that we need to improve import/export performance, but we also need to look at providing a true backup API that third party vendors can integrate with (the lack of which hurts XenServer because as a consequence there are relatively few backup vendors in our ecosystem). We're also looking at how we provide that." -
That API thing is enormous.
-
Probably a consequence of the increasing pressure coming from here: https://bugs.xenserver.org/browse/XSO-581
This is added to "Wishlist" and transmitted to a XS product manager.
-
You are a XS rock star!
-
@olivier I know you saw it (since you posted) but for anyone not getting e-mails from bugs.xenserver.org ... they are close to hopefully fixing the import/export bug.
-
@BRRABill said in XenServer 7 has launched!:
@olivier I know you saw it (since you posted) but for anyone not getting e-mails from bugs.xenserver.org ... they are close to hopefully fixing the import/export bug.
yep saw that - pretty exciting!
-
@BRRABill said in XenServer 7 has launched!:
@olivier I know you saw it (since you posted) but for anyone not getting e-mails from bugs.xenserver.org ... they are close to hopefully fixing the import/export bug.
Awesome, I saw some emails fly by about that this morning.
-
Now there is something to test. As soon I'm back from Xen Dev Summit I'll test it!
edit: just read the commit message to understand why it was slow
https://github.com/xapi-project/xen-api/commit/3e9fc3cb230a220e87f3d5611bc7e7491d2a34bf -
OMG really?
This saves an enormous amount of time because the sha1 hash can be
computed without forking a new process for each 1MiB chunk of data. -
Glad to see this moving forward. 20MB/sec imports and exports are lame.
-
This will help directly for basic backups and DR. I'm not sure about VHD exports, which are already faster.
