BRRABill's Field Report With XenServer
-
When you copy/export a VM, does it also copy removable storage you have attached?
-
@BRRABill said
When you copy/export a VM, does it also copy removable storage you have attached?
Well, I figured this one out for myself. Yes, yes it does.
I have my Tandberg drive hooked up to this one VM I am trying to copy. I kept wondering why it needed so much space to copy. Then I removed the Tandberg from the list of VDs, and voila, the space needed was way down.
So that's kind of wierd. Does it convert the removable into permanent in the copy?
-
@BRRABill I doubt that it converts it from removable to "internal" but it would have to create the backup with everything as attached.
Otherwise what good is it?
-
@DustinB3403 said in BRRABill's Field Report With XenServer:
@BRRABill I doubt that it converts it from removable to "internal" but it would have to create the backup with everything as attached.
Otherwise what good is it?
But it is an attached USB drive. How could the copy access that?
-
That I'm not certain of, likely what is happening is the USB and connections are being recorded for recovery purposes.
How it gets "restored" and saved I have no idea.
How are you passing USB to your guests?
-
@DustinB3403 said
How are you passing USB to your guests?
I go to attach, and the removable USB drive is there.
I wonder if it was a straight USB drive if it would show up. (The Tandberg actually uses removable disks, so I'm not sure if it considers that differently.)
-
-
@DustinB3403 said in BRRABill's Field Report With XenServer:
That I'm not certain of, likely what is happening is the USB and connections are being recorded for recovery purposes.
How it gets "restored" and saved I have no idea.
Might be a good question for @olivier to answer, if he knows. (Which he probably does!)
-
Today, I redid my test server to boot from USB.
Everything went well.
Except now everything is SO SLOOOOOOOOOOOOOOOOOOOWWWWWWWWWWWWWWWWW.
Booting takes so much longer. It's been installing SP1 for what seems like forever at this point.
I guess I got spoiled by the SSD.
The good new is: how often will I ever have to reboot, or install updates, right, RIGHT?
-
I don't have any major slowness booting my system. It might be your hardware, that is causing the issue. Startup checks etc.
Rebooting still has to occur regularly.
-
@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?)
