BRRABill's Field Report With XenServer
-
I said snapshots are used for exporting Running VMs. If your VM is halted, no need to create a snapshot.
-
@olivier said in BRRABill's Field Report With XenServer:
I said snapshots are used for exporting Running VMs. If your VM is halted, no need to create a snapshot.
Ok that makes more sense... so I wonder why his VM when booted on the new imported host acted like it had an improper shutdown?
Could it be related to a different CPU vendor? Why would the NICs be different too? Do the paravirtualized NICs actually show up as the real hardware instead of a virtualized NIC?
-
- No reason come in my mind. Maybe guest/Windows reasons?
- If any hardware change for the guest OS, maybe it's related?
- NIC are different probably because they got a new MAC address (again guest OS behavior)
-
Starting to feel a Hyper-V install in my future.
-
@BRRABill said in BRRABill's Field Report With XenServer:
Starting to feel a Hyper-V install in my future.
I feel a second XS install in mine so I can test these results.
-
The problem here is bad understanding on @BRRABill's part.
He said he did an export/import. I would expect that process to present new hardware. Who would want to export a machine and have it come back up with the same MAC?
If he was doing a migration, that would be different.
-
@JaredBusch said in BRRABill's Field Report With XenServer:
The problem here is bad understanding on @BRRABill's part.
He said he did an export/import. I would expect that process to present new hardware. Who would want to export a machine and have it come back up with the same MAC?
If he was doing a migration, that would be different.
It very well could be, which is why I asked.
On a straight restore, I could see the system seeing the VD as new, since the blocks are all different. But since I exported the VD as-is, I didn't think it would need to run scandisk.
As I said, I was just more curious as to the mechanics of why.
I agree with you on the MAC. I was not thinking that the IP is tied to the adapter. I guess there are so many scenarios, you couldn't copy over the IP.
But in the same token, why would it just grab an IP? That could mess stuff up, too.
Maybe in the future the better thing it to do NO networking, and then fix it before first boot.
Again, this is why I asked the question.
-
@BRRABill said in BRRABill's Field Report With XenServer:
@JaredBusch said in BRRABill's Field Report With XenServer:
The problem here is bad understanding on @BRRABill's part.
He said he did an export/import. I would expect that process to present new hardware. Who would want to export a machine and have it come back up with the same MAC?
If he was doing a migration, that would be different.
It very well could be, which is why I asked.
On a straight restore, I could see the system seeing the VD as new, since the blocks are all different. But since I exported the VD as-is, I didn't think it would need to run scandisk.
As I said, I was just more curious as to the mechanics of why.
I agree with you on the MAC. I was not thinking that the IP is tied to the adapter. I guess there are so many scenarios, you couldn't copy over the IP.
But in the same token, why would it just grab an IP? That could mess stuff up, too.
Maybe in the future the better thing it to do NO networking, and then fix it before first boot.
Again, this is why I asked the question.
Do you even understand what you are saying here?
This is one of the points of virtualization. That it does all of this to make this portable and abstracted.
A restore should never change anything. You are now bringing up a third scenario. Export/Import, Migrate, Backup/Restore. These are all different processes.
-
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.
-
@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.
-
@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.
