@Dashrender haha I know you love trees, we'll probably create a dedicated view for this. But the new concept will be more centered on the filter/search thing in the home view, see https://xen-orchestra.com/blog/dev-report-2-on-xen-orchestra-5-0/

Hi!

Thanks for the hint, will do

handling XS errors in not trivial, but we'll do better in the 5.x branch

In theory, you could have really installed everything in one click if... if XenServer didn't answered an invalid JSON call after SP1 is installed. Thus, you would need to click again on "update all" button. Nothing we could do before Dundee which have a working JSON stuff.

We are already using XAPI VDI export for our backup

@BRRABill just to let you know I ran some tests on continuous delta backup with Dundee, got an export speed around 106 MB/s on my gigabit network. The bottleneck was probably my remote store disk.

I don't have the numbers for 6.5 nor made a proper benchmark on the exact same hardware, but I'll do it later.

Cont. delta backup won't use compression at all.

To finish, ideally we should be able to select which disk to backup with XO (e.g: you have a big data disk which is already saved with rsync or whatever). This is already possible in the XO backend, but we have to work on the UI.

Also a major difference between a backup tool on the guest: XO won't restore inside the VM. It will create a new VM (with the full file) then apply diff (if necessary).

The downside is "restore" time is higher. On the other hand, you could have lost your whole XenServer and having a brand new server, XO restore will still work.

To be able to rollback quickly, there is a solution, called snapshots.

In general, in IT operations, we use both:

• snapshots are very handy when you want to make a modification and rollback if anything goes wrong. It's also cool to schedule them every night in case
• but snapshots ARE NOT BACKUP. That's why cont. delta is perfect here: fast to create and your are protected, even in a catastrophic situation. If you lost your VDI chain/XenServer/whatever, a snapshot won't help at all.

But combining them is great. Restoration time of a catastrophic failure is not often a concern.

In most of cases, a continuous delta backup will be few seconds, so if you need to backup often your VM, that's a good idea.

Also, you can monitor the network speed in the stats to see what's going on. You can also show that CPU should be calm on the host why backuping without compression. The SR can be monitored because of the load average chart too.

But what kind of backup? Normal backup or Continuous Delta backup? If normal backup, did you deactivate the compression or not?

Also, exporting in your Windows share from XO as a backup could produce different result than using XS from your computer (not the same network path).

That's a lof of unknown

Again, I can't guess which kind of backup did you used, on which kind of storage, on which kind of network etc...

edit: it's like you told me, "my car is slow", without telling which car, on which road and in which situation

IIRC, XenServer skip the 0's without compression (I'm not sure but I remember some stuff about the pipe needed to pass it to GZIP which need to handle the read differently than exporting directly). Anyway, continuous delta backup won't suffer of this because exporting the diff only.

I'm not an expert in XenCenter, AFAIK there is a checkbox to compress or not when exporting.

@BRRABill using a guest agent will be faster than a "copy" on hypervisor level (for the record, it uses compression and read the whole disk!)

Remember than a "copy" is a high level feature provided by XO, using streaming export from one server to VM import on the other side. With GZIP compression on XenServer. You bet it's slower than working on guest level!

If you want to compare backup speed, using continuous delta backup could be interesting: after the initial backup (which is not compressed), XO will only export delta (the diff written between the new backup and the previous one). And forever, because we (XO) will merge block of the oldest delta in the full (initial) backup. So no more full export after the first one.

So it's more comparable to your sector-level backup program (it uses the diff of the VHD format). The main difference is you don't need to install any program in your VM to have it working

@BRRABill said in BRRABill's Field Report With XenServer:

@DustinB3403 said in BRRABill's Field Report With XenServer:

@BRRABill Not an error, just a misunderstanding.

The first time I tested the export and import function I thought the same thing, but soon realized that it has to create new "hardware".

Well, this was my first time, so I don't feel so bad.

So, what is the advantage (if any) of exporting/importing a VM versus just restoring a backup to a new VM?

I have no idea with what and how did you backup this VM at the first place. You need to give more context to be sure we are speaking about the same thing.

@JaredBusch said in BRRABill's Field Report With XenServer:

@DustinB3403 said in BRRABill's Field Report With XenServer:

@BRRABill Not an error, just a misunderstanding.

The first time I tested the export and import function I thought the same thing, but soon realized that it has to create new "hardware".

Right because it is export/import. Live migration and Backup/Restore should not.

Live migration is moving things, so you have to preserve it.

Backup/restore is a more complicated question: what about restoring a VM just to check if its OK without rewriting your current VM? (something you could do by mistake). I think this is a correct default behavior.

The goal of virtualization is to provide a kind of "abstraction" layer: you won't have to install new drivers by importing a VM from a host to another (or migrating a VM in live).

But exporting something, then importing it is not "replacing", it's creating a new VM. It's not a restore operation, it adds new stuff.

You can import manually and tells to preserve stuff, but that's a bad idea. E.g, if you preserve the UUID of the exported VM without removing the previous one, it will be fun. And if by default the MAC will be restored, you'll also have a lot of fun if you forget to de activate it.

That's why you need to differentiate clearly a host and its guests. Guest OS (the content of the VM), will behave "like a physical" machine in your previous physical world.

Exporting a VM and importing it elsewhere, is "like" (roughly) put the hard drive from one physical server to another one. Your system will detect new interfaces with new MAC addresses.

"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.