BRRABill's Field Report With XenServer
-
@JaredBusch said in BRRABill's Field Report With XenServer:
@coliver said in BRRABill's Field Report With XenServer:
@BRRABill said in BRRABill's Field Report With XenServer:
@DustinB3403 said
@JaredBusch By default on import the device settings for the NIC's are configured to Auto generate a new MAC address.
This way you can avoid duplicates and all of those problems. But you can manually assign the MAC to what it "was" once the import is completed.
And in that scenario, to the new VM, it would have been seen as the same "adapter"? Thus keeping the same static IP address and DNS settings, etc.?
Not necessarily.
It would yes, unless some odd XS thing makes it not be. I have never had this problem with Hyper-V or VMWare when the MAC was specified.
It is normal to get a new adapter when the MAC is dynamic.
I've never had that happen with XS or Hyper-V. If I am importing/exporting a VM and get a new MAC address I need to configure it again, or change the MAC address of the physical adapter in Linux. In VMWare I haven't had to do this yet so not sure.
-
My error here was thinking the IP address was tied to the server, and not the adapter/MAC.
You have to remember, as hard as it is to believe, I'm moving over from the physical world of a small SOHO. So, one physical server with one physical adapter. None of this auto-generated MAC mumbo-jumbo.
(Yes I know physical servers can have more than one adapter.)
-
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.
-
@olivier said in BRRABill's Field Report With XenServer:
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.
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.
-
@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
