BRRABill's Field Report With XenServer
-
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
-
Are metadata backups really required when you're performing backups using XO? You still have the option for guest level backups as well.
-
@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?
-
@DustinB3403 I'm not sure to understand the question. First, which backup type are you talking?
-
@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.
-
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?
-
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).
-
@olivier said in BRRABill's Field Report With XenServer:
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).
And that is exactly why XO is such an amazing tool. I don't have to backup this thing, that thing, and the kitchen sink. It's all there in one awesome package.
-
@olivier said in BRRABill's Field Report With XenServer:
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).
I just did this today on my test machine.
I did a metadata backup. Ripped out the boot disk, and reinstalled XS on a fresh boot disk. Reintroduced the SR, and restored the metadata. Worked like a charm.
It threw up one error about not being able to find one, but I think that might have been the metadata VDI itself. Stupid me didn't write down the error.
-
@olivier said in BRRABill's Field Report With XenServer:
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).
But you should take a metadata backup separately, too, no?
Let's say your boot device (cough USB cough) decides to die and you don't have a backup.
It's so much faster to reinstall XS and restore the metadata than restore all the VMs through XO, right?
Though of course the XO is also important to protect from loss of the VM itself.
