Posts made by olivier

Happy to see it tested intensively

Exactly. Job manager is "generic": it allows you to build complex planned stuff (like shutdown those VM during the night, and create another job to start them in the morning).

It's very very generic.

Backup is a kind of specific planned job.

@Dashrender Well, this is not the exact topic to answer it completely, but I want to give you a recap.

Using XOA (the turnkey appliance with support), it means that you have nothing to do, just import the virtual machine, it works (because everything is properly installed AND configured inside the VM).

Plus we got an updater, which allow to jump from your current version to the latest one, in one click. We CAN do that because we know how it's built inside XOA. This turnkey solution is available with different flavors (Free, which having some features to administrate your XenServer, Starter, which is good for backups, Enterprise and Premium).

Using the sources: you need to fetch the source code, install dependencies and build it. You CAN'T have the updater, because it can be installed anywhere in your operating system. We can't know which version do you use etc. That's also why we can't have support on those installation (too much possibilities, environment, Node versions, whatever). And you need to update yourself the installation.

So the best product for your needs depends of your use case. If you think you can install it, configure it and update it when you like, without spending too much time: go for the sources!

If you want something working out of the box with our direct support, go for XOA.

There is really 2 public, and that's great: one for the sources, the other for XOA. This last kind of users can help us to have more resources working on the software. The first public will contribute by testing it, reporting issues and also make sometime pull requests to improve it. That's a real "balance" helping everyone.

@JaredBusch This is the best sentence about agent solutions I ever heard.

@DustinB3403 It was bothering me too ^^ But you know, I prefer to expose the feature first, despite it's not perfect. That's only by using something that you can improving it in the right way!

@coliver Well, I'm not considering myself as a developer ^^ But I'm the original creator of the project (created back in 2009 and very old Xen version!) because I needed a web interface to manage my VMs, as a former Sysadmin

edit: I'm now the project leader, didn't leave it since then

@DustinB3403 No worries But if you need an explanation on any XOA stuff, feel free to ping me. I'll come if I can

Yes, that was just VEEAM diagrams

The delta files *.vhd (if it's the original question) are just "blocks" diff between two disk "states": a "moving" disk (the current VM disk) and a snapshot (which is "frozen", like a photo, that's the definition of a snapshot).

To restore it properly, you need to be sure you "inject" the delta inside a coherent VM disk (if you apply delta on a different disk, it will be a mess. Even if you inject a delta on the "wrong" disk state, a mess too).

That's why we got JSON files to indicate the snapshot chain. We'll apply each delta to stay consistent.

Guys,

You should ping me or create GitHub issues when you have concerns, bug report or questions about XO

For the restore without knowing what's happening: I just updated this yesterday, now the VM is named "[Importing...] VMname" until the restore is completed. See https://github.com/vatesfr/xo-web/issues/641

Already closed, so out for 4.12 around Jan 15

About "Forever forward incremental backup", allowing you to avoid any full export after the initial one, it consists of:

• merging offline (ie: without Xen, by ourselves) the original full backup with its contiguous snaphot
• doing step each time, step by step

So you never need to re-export the full stuff after the first time. A good illustration here, from VEEAM:

This should be out in 4.13 (end of Jan.), 4.12 with some luck.

@coliver We can implement a "remote" of Amazon type, that shouldn't be a problem!

Hi @DustinB3403 !

4.11 is out since today: see https://xen-orchestra.com/blog/xen-orchestra-4-11/

SMB will come for 4.12 (mid Jan. max), due to validation time.

About XO best practice, everything is in the doc. About XO+XS best practice, it depends of your current infrastructure. In general, we spend some time to give our customers some leads, but it's more difficult to give large amount of time with the whole community (I would like to, but improving XO is a priority!). Sometimes I can help, at least I do my best to.

Briefly, in your case: we'll implement a "continuous replication" of VM directly to another host/pool (using delta+vm streaming, see the doc part about it). I think it will be suited for your need.

Yes: everything is in the sources (except non-direct XO feature, like the turnkey appliance with the updater).

@scottalanmiller The thing is we don't want to use a system dependency (ie Debian package), but use a SMB lib directly to write on the share. And the lib we are using is pretty messy, we made a fork and continue to improve it.

@johnhooks We got some delay on the SMB feature, but it will be out for the 4.12

Anyway, the blog post about the 4.11: https://xen-orchestra.com/blog/xen-orchestra-4-11/

@scottalanmiller XMPP feature story is nice: I did a XenServer training session to a customer, and he told me he would love to have this feature? It sounded fun for one of our dev, so he did it pretty quick (2 days later). That's indeed fun to have XO telling you the backup job finished correctly

Next release (4.11) will be awesome!

• Incremental backup
• Cloud Init support
• SMB remote for backup (only NFS until now)
• Improved search bar
• XMPP alert plugin
• A lot of small but useful things
• And a far better support of older XS version (6.1 and 6.2)
• ~40 issues closed

Hope to deliver this Monday or Tuesday at worst

@DustinB3403 That's because a lot of our users are using XS 6.1 or 6.2: they can't boot newer versions of Debian (due to old Pygrub shipped in XS).

Using HVM? Some users don't even have hardware virt extensions for it...

Okay, thanks for the details. Indeed, you moved a lot

@scottalanmiller Where are you based?

Hi there!

Long story short:

• creator of Xen Orchestra project
• doing some talks sometimes (LinuxCon US, FOSDEM...)
• Open source lover (Xen, Linux, BSD)
• Web and NodeJS advocate

If you want a longer version of the story, feel free to ask!

Thanks

Feel free to post suggestion or report issues, that's how we can improve it.

About the best practice: "it depends". It depends of:

• your current geographical distribution of your infrastructure
• your infrastructure size
• your security policy

One site, medium infrastructure (common case): XOA inside your cluster. Use backup feature of XOA for backuping itself on a NFS share (which can be replicated outside) or use DR. This way, even if you lost your whole site, you'll be able to restore it. I mean, if it happens, that's normal to lose XOA itself in the process. With a complete pool offline, having a management system won't be really useful anyway.

Large DCs distributed: backup/DR, tunnels (GRE, VPN or SSH, it doesn't matter)

Very small remote infrastructure: XAPI on the web directly. But use a very strong and random root password (XAPI use root account, not possible to do otherwise).