BRRABill's Field Report With XenServer
-
@JaredBusch said in BRRABill's Field Report With XenServer:
@DustinB3403 said in BRRABill's Field Report With XenServer:
I can confirm, exporting from XO (or even XenCenter) will create new MAC addresses once the import is done. I was a bit surprised at first and then realized why.
Because you have the VM set to automatically assign the MAC I would assume. I am not familiar enough with XS to know the setting, with Hyper-V and VMWare, this is the same. In the latter two, though, you can optionally specify the MAC if desired and it will not change during all of those processes.
You can do the same in XS.
-
@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.
-
@JaredBusch said
Because you have the VM set to automatically assign the MAC I would assume. I am not familiar enough with XS to know the setting, with Hyper-V and VMWare, this is the same. In the latter two, though, you can optionally specify the MAC if desired and it will not change during all of those processes.
With me being new to the virtualization game, these are the kinds of things I am learning.
Did my sever blow up? No.
Do I want to ask questions to figure out why what happened did? Yes.
I'm not sure how I can be any clearer I am asking questions here because I do not know and would like to learn.
-
@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.?
-
@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.
-
@BRRABill No at least not with how I'm currently configured. All of my VM's will auto generate a new MAC and thus get a new IP from our DHCP server. (On export / import)
But once the import is completed, if you have the VM configured so it doesn't automatically turn on, just copy the MAC address from your old VM, and replace the MAC address of the NIC of the imported VM.
Then it will pull the same IP from your DHCP server.
XC will alert you about the same MAC being used, but so long as you keep the other VM off you'll be fine.
-
@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.
-
@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.
