BRRABill's Field Report With XenServer
-
@DustinB3403 said
@BRRABill Yes it's possible to manually remove a patch from XS by going into the applied folder, but it's very risky to do so.
As @JaredBusch said you're essentially removing a critical system patch that's been superseded by another. A general RoT that I keep seeing about is to never delete anything from the "applied" folder.I'm glad that it worked for you, but I would refrain from doing it. Use XO to apply the patches (I know you said you would). It's elegant enough to not break things.
From what I read, it does not actually remove the patch. Just XC's idea that the patch is installed. It's just a teeny file in that folder, not actual XS files.
There is no way to uninstall a patch.
Someone in the Citrix forums summed it up pretty nicely:
"Now Xencenter doesn't know that this patch was ever installed. Keep in mind that this server has still installed this patch that doesn't exist anymore." -
@DustinB3403 said
I'm glad that it worked for you, but I would refrain from doing it. Use XO to apply the patches (I know you said you would). It's elegant enough to not break things.
I did use XO for the new server, but that doesn't do anything to the fact that the one server in question already HAD the superceded patch on it. If I had done the patches in order from 1 and moving upward, it would not have been an issue. But that isn't what is recommended, nor is it the way XO does it.
I really do wonder if it is some sort of bug with this particular patch. Almost every thread I read about this issue anywhere was regarding this one patch, which is XS65E016.
The Citrix forums also discuss how kludgy the 6.5 hotfix process is, and that is is supposed to be much better in the newer version. (As is the export speed issue.)
-
@BRRABill just to let you know I ran some tests on continuous delta backup with Dundee, got an export speed around 106 MB/s on my gigabit network. The bottleneck was probably my remote store disk.
I don't have the numbers for 6.5 nor made a proper benchmark on the exact same hardware, but I'll do it later.
-
@olivier said
@BRRABill just to let you know I ran some tests on continuous delta backup with Dundee, got an export speed around 106 MB/s on my gigabit network. The bottleneck was probably my remote store disk.
I don't have the numbers for 6.5 nor made a proper benchmark on the exact same hardware, but I'll do it later.
I've been following posts on Dundee online. It seems there are speed caps for some reason. And when you factor in the compression and other things, people were really complaining about the export speed. It also seems wildly inconsistent depending on where you do the export/backup from. But it's clearly something that effects everyone and is very annoying.
Here is a good thread of people trying different things, and at the end, a possible upcoming solution.
http://discussions.citrix.com/topic/237200-vm-importexport-performance/page-8But it's interesting to see that there is a lot of chatter that has already taken place on this things we are just starting to discuss here.
A snippet:
"Some good news: Citrix has taken up my suggestion and is evidently working on implementing into vm-export the same mechanism as used by vdi-export (which uses vhd-tool). I found from my own experiments that this is 2.5 to 5 times faster. They initially report a test where with a VM with a VDI, a current vm-export takes 135 seconds to complete, and with a vdi-export mechanism patch, it takes just 39 seconds (so 3.5x faster). Using a direct copy to export, the VDI took 31 seconds on the same host, so this would make it almost as fast as the native copy speed (that is about 80% of native speed)." -
We are already using XAPI VDI export for our backup
-
@olivier said in BRRABill's Field Report With XenServer:
We are already using XAPI VDI export for our backup
That's because y'all is brilliant.
BTW: awesome job on the updates section as well. I used that for the first time recently, and it does a great job.
The one "issue" I ran into on a fresh install of 6.5 was that it got to SP1, and then wouldn't do anything. Knowing SP1 needed a reboot, I rebooted, and then it carried on as expected. But might be nice to say "hey reboot me" or something.
-
In theory, you could have really installed everything in one click if... if XenServer didn't answered an invalid JSON call after SP1 is installed. Thus, you would need to click again on "update all" button. Nothing we could do before Dundee which have a working JSON stuff.
-
@olivier said in BRRABill's Field Report With XenServer:
In theory, you could have really installed everything in one click if... if XenServer didn't answered an invalid JSON call after SP1 is installed. Thus, you would need to click again on "update all" button. Nothing we could do before Dundee which have a working JSON stuff.
Ah, OK.
Can you perhaps invent a little paper clip that comes up on the bottom of the XO windows that tells you to click that button again?
I AM KIDDING, OF COURSE.
-
handling XS errors in not trivial, but we'll do better in the 5.x branch -
@olivier said
handling XS errors in not trivial, but we'll do better in the 5.x branch Looking forward to seeing it. XO is really a great product.
-
@travisdh1 said
If you make a backup from XenCenter before that, then all you have to do is reinstall and restore the backup at least.
I had a question about this.
If you were to mess up your USB boot stick. I understand you can reinstall XS, and restore the backup. However, you still have to "find" and mount all the VMs, right? And the VM metadata also needs to be backed up as well, right?
I was researching this, and decided to give XS research a break for a few days. But you made me think of this again.
-
@BRRABill said in BRRABill's Field Report With XenServer:
@travisdh1 said
If you make a backup from XenCenter before that, then all you have to do is reinstall and restore the backup at least.
I had a question about this.
If you were to mess up your USB boot stick. I understand you can reinstall XS, and restore the backup. However, you still have to "find" and mount all the VMs, right? And the VM metadata also needs to be backed up as well, right?
I was researching this, and decided to give XS research a break for a few days. But you made me think of this again.
I haven't read the entire thing yet, but found something that looks like good information about this on Daniel's Techblog
-
@travisdh1 said
I haven't read the entire thing yet, but found something that looks like good information about this on Daniel's Techblog
That's what I found as well, and made me think there is a lot more to it than just doing a simple backup from XC. In fact, I'm not really sure what the heck that even gets for you, since it's like 1 step of 20!
-
@BRRABill said in BRRABill's Field Report With XenServer:
@travisdh1 said
I haven't read the entire thing yet, but found something that looks like good information about this on Daniel's Techblog
That's what I found as well, and made me think there is a lot more to it than just doing a simple backup from XC. In fact, I'm not really sure what the heck that even gets for you, since it's like 1 step of 20!
From what it sounds like, when you restore the configuration information in the XenConsole/XO, that should bring the repository information back. Then you can restore the metadata information via the console. I haven't had to try the process myself yet, going togive it a shot after I get some other machines swaped out.
-
Yeah I got a little burned out on XS stuff.
Then some other work stuff came up.
I'll get back to it, too, and let you know if I do it before you get to it.
I wish they would release 7 already. It is supposed to make transferring between non-similar hosts much easier/doable. That would make it easier for me to transfer VMs back and forth. Right now it's a PITA for me and my 1 (new) server shop.
-
Overnight my other XS decided to crash on me.
This is the temp one, so no iDRAC available. The VMs were down, and XC could not contact it.
Came in, it all seemed fine. The VMs said they were running.
I wonder if the network adapter in this machine just lost its mind. Can't think of anything else it could be.
A reboot fixed everything right up.
-
@BRRABill It could be a hardware issue as you mentioned. If rebooting the host addressed the issue, and your management interface was the issue, you'll likely see more issues in the future.
-
@DustinB3403 said
@BRRABill It could be a hardware issue as you mentioned. If rebooting the host addressed the issue, and your management interface was the issue, you'll likely see more issues in the future.
Always an adventure.
Once I am sure the SSD array is stable on the other machine the VM on this temporary machine is getting moved to that server.
-
I was sure my USB boot stick had filled up with logs. But I took a look and it looks fine.
Though FileZilla showing things in bytes threw me off. No coffee yet.
-
@DustinB3403 said
I'm glad that it worked for you, but I would refrain from doing it. Use XO to apply the patches (I know you said you would). It's elegant enough to not break things.
If the server needs a reboot after a patch, is XO elegant enough to handle that as well?
It never seems to need a reboot, and yet when you install through XC it almost always does.
