BRRABill's Field Report With XenServer
-
@BRRABill said in BRRABill's Field Report With XenServer:
@travisdh1 said in BRRABill's Field Report With XenServer:
@BRRABill said in BRRABill's Field Report With XenServer:
@olivier said in BRRABill's Field Report With XenServer:
Basic backup with tag "test", compression enabled, never report any failure or success by email, retention of 2. Saving on "remote10". All of this on vm XO hosted on xenserver-MAIN.
How did you know compression was enabled?
Just guessing that "with compression"
That was the name of my job.
"test with compression"
Ah, 2nd guess, compress:
-
@travisdh1 said
Ah, 2nd guess, compress:
Both the jobs with and without compression both say "compress:"
I'm wondering if it was supposed to say
"compress:yes"
or something.Which is why I am wondering if it is a bug.
-
Sounds likely that something is wrong there.
-
@scottalanmiller said in BRRABill's Field Report With XenServer:
Sounds likely that something is wrong there.
I can't tell if I am reporting things that have already been fixed, or not.
This has nothing to do with me. It's my inexperience with GitHub.
These are the two responses I received.
Closed #1338 via bd70bd2.
Closed #1339 via #1347.Does the top one mean it was a new fix? And the bottom one mean they were aware already?
-
Closed means the issue is "finished": without extra comment or specific tag (like duplicate, invalid or won't fix), it means that's solved.
You can follow links to see what fixed the issue (in the "via #1347" or the commit hash).
TL;DR: issues fixed. Will be released in the "next wagon".
-
@olivier said in BRRABill's Field Report With XenServer:
Closed means the issue is "finished": without extra comment or specific tag (like duplicate, invalid or won't fix), it means that's solved.
You can follow links to see what fixed the issue (in the "via #1347" or the commit hash).
TL;DR: issues fixed. Will be released in the "next wagon".
Right, but I was "afraid" of posting stuff you already knew about.
So "via 1347" means there was already an issue similar, and the fix was the same?
What does the hex link mean?
Thanks for another day of education!
-
The hex link refers to the commit.
Issue #1338 was fixed in commit bd70bd2.
-
Clicking on those link won't destroy the universe: go click and see where are you going
One send you to a Pull Request (PR), a piece of code written by someone and send "sent for review". Julien (lead dev) checked the diff (code modified) and then merged it in the
next-release
branch.The other link directly to a commit fixing the issue
edit: a PR can embed multiple commits
-
@olivier said in BRRABill's Field Report With XenServer:
Clicking on those link won't destroy the universe: go click and see where are you going
I did click and still didn't get it.
I am sloooooooooooooooowwwwwwwwwwwwwwwwwwwwwwwwww.
-
I don't get what you don't get about this ^^
-
@olivier ... did you see the comment about regarding
compression:
being the same for both jobs?
How did you know I had compression enabled, other than it was in my tag?
-
@olivier said in BRRABill's Field Report With XenServer:
I don't get what you don't get about this ^^
Did you miss the part where I said I was slow?
Somewhere @scottalanmiller is shaking his head in agreement.
So #1347 and the hex are not others already reporting it. They are the code snippets to fix it.
I'm just trying not to make extra work for you guys. But am happy to report things if they are real issues.
-
How does XO deal with hotfixes such as this one, where there are specific steps/rules that must be followed before applying?
http://support.citrix.com/article/CTX214305
Mainly:
"In contrast to other XenServer updates, it is important to avoid suspending VMs when applying this hotfix."Or does XO not even suspend anything. I know it's pretty durn smart.
-
@BRRABill With such an important update, I would apply it via XC, manually shutdown the VMs, then reboot the hosts.
-
Nah, no problem to apply it. This is a special one, but even if you already triggered the issue (in a kind of special way, I know I spent a week helping a client), it won't change anything. Tested and applied/verified on 20 different hosts and 2 with the actual issue. No problem.
Let's see in more details:
- we fetch here the update list: http://updates.xensource.com/XenServer/updates.xml
- told ya:
after-apply-guidance="restartHost"
(so nothing special about suspended VMs) - but
guidance-mandatory="true"
-> this is a new field since XS 7. I hope they won't ask for it for nothing. We'll find a way to get this into the patching process (probably asking for restarting after updating completely the host)
So doesn't change to apply with XC or XO if you follow the guidance (manually in XO so far).
edit: remember to think an update like a Linux update. Not a windows update. Thanks.
-
@olivier Applied XS70E006 and XS70E005 yesterday via XO's Install Pool Patches option. I had to run it twice, once for each host in the pool. No errors AFAIK (I'll have to go back and check the logs).
-
@olivier said
- told ya:
after-apply-guidance="restartHost"
(so nothing special about suspended VMs)
They seemed pretty adamant in their writeup.
- told ya:
-
Via which view exactly? Keep me posted about logs
-
@olivier From the Pool > Patches tab; there's a button "Install pool patches"
-
@Danp Thanks. If you have any log, feel free to share