BRRABill's Field Report With XenServer

tiagom

The hex link refers to the commit.

Issue #1338 was fixed in commit bd70bd2.

olivier

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

BRRABill

@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.

olivier

I don't get what you don't get about this ^^

BRRABill

@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?

BRRABill

@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.

BRRABill

@olivier

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.

Danp

@BRRABill With such an important update, I would apply it via XC, manually shutdown the VMs, then reboot the hosts.

olivier

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.

Danp

@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).

BRRABill

@olivier said

told ya: after-apply-guidance="restartHost" (so nothing special about suspended VMs)

They seemed pretty adamant in their writeup.

olivier

Via which view exactly? Keep me posted about logs

Danp

@olivier From the Pool > Patches tab; there's a button "Install pool patches"

olivier

@Danp Thanks. If you have any log, feel free to share

DustinB3403

Are metadata backups really required when you're performing backups using XO? You still have the option for guest level backups as well.

BRRABill

@DustinB3403 said in BRRABill's Field Report With XenServer:

Are metadata backups really required when you're performing backups using XO? You still have the option for guest level backups as well.

Well, if your boot disk goes belly up, you can restore them pretty simply with the VM metadata backup.

That's what I just did. A fresh install.

If you didn't have that, you'd have to manually map them, or restore them all from backup.

Unless I am missing your point?

olivier

@DustinB3403 I'm not sure to understand the question. First, which backup type are you talking?

BRRABill

@olivier said in BRRABill's Field Report With XenServer:

@DustinB3403 I'm not sure to understand the question. First, which backup type are you talking?

I think he was asking if you are backing up your VMs through XO, do you really need the metadata.

And if that IS the question, I think I answered why.

DustinB3403

I guess I don't see the value in this, as I read the use cases of "When migrating a set of Virtual Machines (VMs) from one XenServer host or pool to another, it is necessary to back up and then restore the Virtual Machine Metadata."

Which I've been able to do this with XO, without issue. If the host goes belly up, wouldn't you be reinstalling from scratch and just importing?

olivier

VM metadata means: VM name, description, number of virtual interfaces, disks etc. Everything except the disk content.

So when we are doing VM backup, we are actually export both disk content and VM metadata.

Otherwise, it would be just a bunch of disks with their UUID, which is a bit useless when you need to restore (unless you can memorize every VM configuration and disk placement with their respective UUID. In this case, please answer the question on the meaning on life and everything).