BRRABill's Field Report With XenServer
-
@DustinB3403 said
That's a great way to explain the export and import process. You're pulling the disk out of your VM, and putting it into a new VM. So of course the guest will detect new hardware.
I guess another "error" I made in thinking was that all XS servers look like the same hardware to XS VMs.
-
@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".
-
@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.
-
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.
-
@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.
-
@olivier said in BRRABill's Field Report With XenServer:
@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.
Backup/Restore, should by default not change anything. That is the purpose of the process.
If you want to create a test restore, then you should be intelligently checking off the options needed to restore without networking, etc.
-
@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?
When I set up this VM, I created a new VM, and just restored from a backup. It took a lot less time than this export/import process. And a LOT less time than the copy process.
The one thing that was different this time was after the restore, my sector-level backup freaked, and basically re-ran the entire backup. Understood because the underlying storage hardware had changed. With the export, this did not happen, though it did freak a little and redo about 10% of the sectors.
That was something I assumed would happen because the storage system had not changed. It was the same (virtual) drive. (And why I wondered why Checkdisk ran.)
That's what I thought would happen across the board for everything, I guess. I what I thought the advantages of export were.
-
@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.
-
@olivier said
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.
Oh yeah, that would help.
I use Datto, which basically just uses Shadowprotect, which is a sector-level backup program.
I set up a new VM in XS, and did a bare-metal restore to it from the a previous backup of my physical server. Worked like a charm.
-
@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
-
@olivier said in BRRABill's Field Report With XenServer:
@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
Does export from XC definitely use compression? That is the one thing I think we were still debating in the other thread.
-
I'm not an expert in XenCenter, AFAIK there is a checkbox to compress or not when exporting.
-
@olivier said in BRRABill's Field Report With XenServer:
@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!)
That was something else I figured had to be happening, that is reads the entire disk.
Which, if you have a lot of empty space for whatever reason, adds a lot of extra time.
There is an instance it would be nice to be able to shrink the VD, then do the copy/export. Maybe a pipe dream!
-
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.
-
@olivier said in BRRABill's Field Report With XenServer:
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.
The reason I chose XC export instead of XO backup was because in my test VM (a Server 2012 core install) it took around 5 minutes to export, and 12 minutes to backup. I figured the backup would more than double the time I needed to accomplish my task.
But in the other thread (on performance) you said that backup should be quicker.
Any thought on why I saw opposite results? Was the sample too small? I'd be glad to do another test.
-
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
-
@olivier said in BRRABill's Field Report With XenServer:
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
WHY DO I KEEP DOING THAT?
I set up a one-time backup of the VM through XO.
The backup went to a Windows share. The same share I used for the export location.
-
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
-
@olivier said in BRRABill's Field Report With XenServer:
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
Normal backup, just a one-time backup. (Mainly for the purpose of importing to another XS.) I disabled compression.
OK, I will continue to test things and report back.
-
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.
