BRRABill's Field Report With XenServer
-
@olivier said in BRRABill's Field Report With XenServer:
XO will try to force migrate, but from a recent to an older CPU, the result is half of the time a kernel panic (older to recent CPU is less problematic, you'll keep using existing instruction from the old CPU without exploding in flight, contrary to trying a recent CPU instruction which doesn't exist on an older CPU)
I do understand this. Is the expectation that one would ever only try to live migration from and to nearly identical hardware? (or at minimum the same CPU?)
-
@Dashrender Citrix always explain that pools should have homogeneous CPUs/hardware
-
@olivier gave me this link
http://support.citrix.com/article/CTX127059 -
To circle back and answer some questions...
- It was a Server 2003 VM.
- I did a full shutdown and export/import.
- I was expecting it to just come right back up, because the disk should have been the same. Same with the networking.
- The VM had a static IP address. When I tried to assign this address to the adapter it was given, it said there was a hidden adapter with the same IP. I understand why that happens, but again since it was a full shutdown and copy, I didn't think those things would happen.
Not a huge deal, just trying to learn more.
-
@BRRABill said in BRRABill's Field Report With XenServer:
To circle back and answer some questions...
- It was a Server 2003 VM.
- I did a full shutdown and export/import.
- I was expecting it to just come right back up, because the disk should have been the same. Same with the networking.
- The VM had a static IP address. When I tried to assign this address to the adapter it was given, it said there was a hidden adapter with the same IP. I understand why that happens, but again since it was a full shutdown and copy, I didn't think those things would happen.
Not a huge deal, just trying to learn more.
wait.. something happened... you didn't get the same hardware profile on the new machine, hence the hidden adapter. What caused that?
So you shutdown the VM, then did an export to a file, then imported that file on the new server and started it?
-
@Dashrender said
So you shutdown the VM, then did an export to a file, then imported that file on the new server and started it?
Correct.
The only thing I can think of is that the machine I exported from has more NICs activated.
But that still doesn't explain the checkdisk, unless that is totally normally. I was just ASSUMING (I know, I know) it would just boot up.
-
huh, Well @olivier did say that exports are based on snapshots, though I don't know why a snapshot would be needed on a non running VM.
-
@Dashrender said in BRRABill's Field Report With XenServer:
huh, Well @olivier did say that exports are based on snapshots, though I don't know why a snapshot would be needed on a non running VM.
Right, that makes no sense.
-
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.
