BRRABill's Field Report With XenServer
-
@olivier said in BRRABill's Field Report With XenServer:
In most of cases, a continuous delta backup will be few seconds, so if you need to backup often your VM, that's a good idea.
Also, you can monitor the network speed in the stats to see what's going on. You can also show that CPU should be calm on the host why backuping without compression. The SR can be monitored because of the load average chart too.
I was doing that, and why I was confused about compression with export. Sometimes it seems like it is on, sometimes it seems like it is not. I guess it depends on what the source material on the server is.
When I get everything set back up I'll do some testing.
-
Cont. delta backup won't use compression at all.
-
@Dashrender said in BRRABill's Field Report With XenServer:
Nope.. some include some older ones.. but not all.
You can start with the newest and work backwards, refreshing the list of needed updates each time.
Just wanted to double-check to be sure this was the case, as this is what I have been doing.
I usually, actually, start with the 6.5 SP1, then move on to the latest patch, which will make some earlier ones disappear. I just keep moving backwards in time until no updates remain.
-
The reason I ask is because when I do this, XC still shows the "down yellow error" that patches are available, even though they aren't.
I saw online some ways to clear this, but wanted to make sure this was OK behavior before doing so.
-
So I figured out what the issue is.
There is a hotfix that is installed on one of my two servers and not the other.
On Server1, i went hotfix by hotfix, installing them all. On Server 2, I started with SP1, and then went to the oldest and worked backwards.
This leave htofixes installed on one that have been since depreciated.
At least that my hypothesis.
-
you think having a depreciated patch installed was causing the issue? I didn't know you were suppose to remove old patches before installing new ones?
-
You are not supposed to in any normal deployment scenario. I would not expect XS to differ in that.
-
@Dashrender said
you think having a depreciated patch installed was causing the issue? I didn't know you were suppose to remove old patches before installing new ones?
You can't. It's impossible with XS.
I do have a depreciated patch installed. So it is OK, just not needed anymore, hence why starting with SP1 on my newer installation skipped that patch.
-
@JaredBusch said
You are not supposed to in any normal deployment scenario. I would not expect XS to differ in that.
From what I have read, there is no way to uninstall, unlike a Windows update.
-
@BRRABill said in BRRABill's Field Report With XenServer:
@JaredBusch said
You are not supposed to in any normal deployment scenario. I would not expect XS to differ in that.
From what I have read, there is no way to uninstall, unlike a Windows update.
You are completely missing our point.
You are not supposed to uninstall superseded windows updates either.
That is not a normal thought process.
-
@JaredBusch said
You are completely missing our point.
You are not supposed to uninstall superseded windows updates either.
That is not a normal thought process.
Of course. I don't know why you think I thought that or missed "your point".
This would be like if you had an existing Windows server that had a superceded patch on it. Then you buy a new server, and install the new patch that supercedes the previous one, and it keeps griping at you that your servers aren't updated.
I think it's just a weird thing as when I Googled it a lot of people had the same problem with the same patch.
Or it could be totally wrong. But since this is a rolling discussion of my experience with XS, I thought it would be good to post.
-
So your problem is you want to remove what you feel is a bad patch? That was not clear.
As I do not have XS running anywhere right now, and limited testing experience, I cannot help you with uninstalling it.
-
@JaredBusch said
So your problem is you want to remove what you feel is a bad patch? That was not clear.
Yeah, I mean I guess if that was an option, I would do it. But it's not, so I'll deal with the little yellow arrow.
It's not a bad patch. It's a depreciated patch that happened to get installed.
In the future I am just going to use XO to install patches. Part of the learning process.
-
I was going back to the Citrix forums to find the thread I originally saw about not being able to uninstall, and rather having to reinstall XS. To quote to you.
Well, I had seen a possible solution on that thread. (It involved finding the patch on the XS install and deleting it. This leaves it installed but tricks the server into thinking it isn't) Anyway, I decided to try it, and by damn it fixed the issue.
So ... thanks! LOL.
This was the key, if anyone else is reading this in the future and comes across this post.
"From the server that has the patch applied can you see it with xe patch-list ? I'm wondering if you can get the uuid of the patch and go into \var\patch\applied and delete that uuid manually for XS65E016. After that I would restart the toolstack and see if it still shows up as applied. Never tried doing this to make XenServer forget a patch, but there has to be a way." -
@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.
-
@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
