We packaged a binary for offline merging into XOA. You'll have to build it yourself because our version is not portable so far.
Clone https://github.com/rubiojr/vhd-util-convert, make and put the vhd-util binary inside xo-server/bin/
We didn't had enough time to make a portable stuff for 4.12
Currently uploading new XOA's, but:
@JaredBusch You don't get it. It's not about the XO code itself, it's all about dependencies.
Eg. by making a CRON job which git pull (no problem) everyday but also npm i: that's the issue. If a related dependency changed, and even XO doesn't, you could break the software. We saw the issue recently with lodash team making a big mistake which affected a LOT of projects using it.
edit: again, that's the point of XOA: packing something with QA on the software but also on dependencies. You can imagine this like a distro.
@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.
@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.
"Plain" Xen or KVM would need an agent installed on each host to expose an "enough advanced" API (probably something ugly like libvirt+custom scripts). Take a look a oVirt project for this.
Anyway, XO is only working on XAPI (which is the project name of this Xen API). APIs can be confusing because there is various level of APIs: low level APIs (like lib-xl or a part of lib-virt), and more "turnkey"/complete API like XAPI, which handle a lot of stuff (not only the hypervisor, but also the glue around it).
That's why XAPI project is more than just an API, but a "toolstack". See http://wiki.xen.org/wiki/Choice_of_Toolstacks
For example, Amazon got its own toolstack (not public) on top of Xen.
@wrx7m Thanks for the pricing details, really interesting!
Assisted search filters for pools/hosts/tags are now working. Now on adding a switch on the home view to have also hosts.
Home view can now display hosts too. ISO can be mounted in console, Ctrl+Alt+Del is also working.
Full VM creation will land tomorrow, so we'll cover 80% of previous features. That's where we'll merge in next-release. Keep in mind that was a technical rework first (speed/architecture), we'll do a UI sweep probably for a 5.1
Take a look on the "pulse" on GitHub: https://github.com/vatesfr/xo-web/pulse/monthly
That's serious work!
Commit activity (in red since we started the rework):
It's out guys. To be fair, I'm far from being satisfied, but we had to release it. You can be sure that we'll make a lot of small releases in the next 2 weeks.
@aaronstuder the thing is: we already wrote a book about Node (in French) 
Just bought one Edge Router POE + one Unifi AP: that's fast! Love the CLI!
Okay, so after just few days of technical experiments, here is the deal.
Usually, in a 2 hosts configuration, it's not trivial to avoid split-brain scenarios.
In a very small setup like this (2 hosts only with few disk space), you'll expect the overhead to be the worst possible regarding the proportion of resources. But will see it's still reasonable.
A shared file storage (thin provisioned):
Obviously, in case of using large local HDDs, storage overhead will become negligible.
In theory, going for more than 3 nodes will open interesting perfs scalability. So far, it's just replicating data, but you can also spread them when you have 3+ nodes.
I'm comparing to a dedicated NAS with ZFS RAID10 (6x500GiB HDDs) with 16GiB of RAM (very efficient cache for random read/write) with semi-decent hardware (dedicated IBM controller card), on a NFS share.
| ZFS NAS | XOSAN | diff | |
|---|---|---|---|
| Sequential reads | 120 MB/s | 170 MB/s | +40% |
| 4K reads | 9.5 MB/s | 9.4 MB/s | draw |
| Sequential writes | 115 MB/s | 110 MB/s | -5% |
| 4k writes | 8.4 MB/s | 17 MB/s | +200% |
As you can see, that's not bad.
It's technically doable. But there is a mountain of work to have this in a "one click" deploy. I'll probably make a closed beta for some XOA users, and deploy things semi-manually to validate a bit the concept before spending to much time scaling something that nobody will use in production for some reasons (interest, complexity, etc.).
@Danp That's because despite the added layers, we are making some operations locally and also on a SSD (vs the existing NAS where everything is done remotely)
It's more indicative than a real apple to apple benchmark. The idea here, is to show the system would be usable, performances are not the main objective here.
I also updated the benchmarks with a Crystal Diskmark working on a 4GiB file (avoiding ZFS cache). Difference of performance is now huge, so the impact of the replication is not that bad at the end.
Well, sort of This command is now working:
xe sr-create name-label=XOSAN shared=true content-type=user type=xosan
Still a lot of stuff between this and a viable product, I'm in the middle of testing the solution in terms of resilience and overhead. I need also a layer of glue to at least semi-automate the deployment of XOSAN on a pool, otherwise I'll spent to much time doing it manually for each beta tester ^^
Anyway, developing a storage on current storage architecture of XenServer is really a pain. Eager to see SMAPIv3 in action 