BRRABill's Field Report With XenServer
-
@DustinB3403 said in BRRABill's Field Report With XenServer:
I don't have any major slowness booting my system. It might be your hardware, that is causing the issue. Startup checks etc.
It's the same hardware as before.
I really think it's just the incredible slowness of USB vs. SSD.
-
@BRRABill said in BRRABill's Field Report With XenServer:
@DustinB3403 said in BRRABill's Field Report With XenServer:
I don't have any major slowness booting my system. It might be your hardware, that is causing the issue. Startup checks etc.
It's the same hardware as before.
I really think it's just the incredible slowness of USB vs. SSD.
It could also be USB2 vs USB3. USB3 is almost as fast as a hard drive on my home computer. USB2 crawls big time.
-
@dafyre said
It could also be USB2 vs USB3. USB3 is almost as fast as a hard drive on my home computer. USB2 crawls big time.
Yeah USB2 sucks, and it's the only option on this brand new server.
I actually discussed that with @scottalanmiller offline, and his take was ... you should never be using USB on a server anyway. (I had questioned why in the world they wouldn't have used USB3.)
I promised him I'd never send him a picture of my server room.
-
I do have a USB 3.0 drive attached for a quick fix. Trying to get that moved to a 2 drive Buffalo NAS device.
-
As for the never with USB, that's to short sited.. sadly there are still vendors who use USB keys to keep software licensed (mitel does). I ended up buying a device that is USB on one side and ethernet on the other. then install driver on VM virtualizing the USB device.
-
Question:
I migrated my VM from one XS to another. When the new VM came up, it ran a check disk, and then the networking was off.
If this is an export/import, why should any of that happened?
-
@BRRABill said in BRRABill's Field Report With XenServer:
Question:
I migrated my VM from one XS to another. When the new VM came up, it ran a check disk, and then the networking was off.
If this is an export/import, why should any of that happened?
Well the disk was copied while it was running, so when you boot the disk on the new host, that system sees it's boot as if it crashed/shutdown improperly. As for the networking, I'm guess it's because the system is set to boot up while the original is still running. Disabling the network prevents the same server on two devices at once. It's not a real V-Motion solution as you used it.
-
@BRRABill said in BRRABill's Field Report With XenServer:
Question:
I migrated my VM from one XS to another. When the new VM came up, it ran a check disk, and then the networking was off.
If this is an export/import, why should any of that happened?
What OS?
-
@Dashrender said in BRRABill's Field Report With XenServer:
@BRRABill said in BRRABill's Field Report With XenServer:
Question:
I migrated my VM from one XS to another. When the new VM came up, it ran a check disk, and then the networking was off.
If this is an export/import, why should any of that happened?
Well the disk was copied while it was running, so when you boot the disk on the new host, that system sees it's boot as if it crashed/shutdown improperly. As for the networking, I'm guess it's because the system is set to boot up while the original is still running. Disabling the network prevents the same server on two devices at once. It's not a real V-Motion solution as you used it.
I like when someone answer better on XO than I would!
That's indeed 100% correct:
- you probably made a copy (not a migrate because it seems you had to boot it)
- make a copy of a running VM relies on a snapshot
- booting an exact copy with the same IP setting explains why the network didn't came up (OS tried to start it but seen a conflict)
-
@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)
