Burned by Eschewing Best Practices
-
@DustinB3403 said in Burned by Eschewing Best Practices:
OP was working in a Hyper-V cluster and needed to migrate his VM's over to the other node. The transfer failed for one VM, and the VM is lost.
Didn't take a backup prior to beginning work.
Also he's in an IPOD.
-
@DustinB3403 said in Burned by Eschewing Best Practices:
OP was working in a Hyper-V cluster and needed to migrate his VM's over to the other node. The transfer failed for one VM, and the VM is lost.
Didn't take a backup prior to beginning work.
I've even seen big Wall St. firms make that mistake
-
@DustinB3403 said in Burned by Eschewing Best Practices:
OP was working in a Hyper-V cluster and needed to migrate his VM's over to the other node. The transfer failed for one VM, and the VM is lost.
Didn't take a backup prior to beginning work.
Why should the VM be lost? It will be copied and when every bit is over at the new place, it gets deleted on the original location. Maybe it's just not registered anymore on both hosts?
-
@thwr said in Burned by Eschewing Best Practices:
@DustinB3403 said in Burned by Eschewing Best Practices:
OP was working in a Hyper-V cluster and needed to migrate his VM's over to the other node. The transfer failed for one VM, and the VM is lost.
Didn't take a backup prior to beginning work.
Why should the VM be lost? It will be copied and when every bit is over at the new place, it gets deleted on the original location. Maybe it's just not registered anymore on both hosts?
That is very odd as there should be shared storage via the iPOD, so nothing was ever "moved".
-
@scottalanmiller said in Burned by Eschewing Best Practices:
@thwr said in Burned by Eschewing Best Practices:
@DustinB3403 said in Burned by Eschewing Best Practices:
OP was working in a Hyper-V cluster and needed to migrate his VM's over to the other node. The transfer failed for one VM, and the VM is lost.
Didn't take a backup prior to beginning work.
Why should the VM be lost? It will be copied and when every bit is over at the new place, it gets deleted on the original location. Maybe it's just not registered anymore on both hosts?
That is very odd as there should be shared storage via the iPOD, so nothing was ever "moved".
Even the metadata would have stayed put in this case.
-
@coliver said in Burned by Eschewing Best Practices:
@scottalanmiller said in Burned by Eschewing Best Practices:
@thwr said in Burned by Eschewing Best Practices:
@DustinB3403 said in Burned by Eschewing Best Practices:
OP was working in a Hyper-V cluster and needed to migrate his VM's over to the other node. The transfer failed for one VM, and the VM is lost.
Didn't take a backup prior to beginning work.
Why should the VM be lost? It will be copied and when every bit is over at the new place, it gets deleted on the original location. Maybe it's just not registered anymore on both hosts?
That is very odd as there should be shared storage via the iPOD, so nothing was ever "moved".
Even the metadata would have stayed put in this case.
Yeah, should have.
-
It seems I heard about a bug in Hyper-V under certain circumstances this would happen... I can't remember where I heard it from though.
-
@dafyre said in Burned by Eschewing Best Practices:
It seems I heard about a bug in Hyper-V under certain circumstances this would happen... I can't remember where I heard it from though.
Ouch, that is one scary bug. People get WAY too callous about vmotioning servers. They treat it like a guaranteed safe operation. But in reality it's like a RAID 5 resilver... the chances of failure are still pretty high.
-
@scottalanmiller Yeah. I've done a number of live migrations, and have seen random failures, but never actually completely lost a VM like that.
-
@dafyre said in Burned by Eschewing Best Practices:
@scottalanmiller Yeah. I've done a number of live migrations, and have seen random failures, but never actually completely lost a VM like that.
True, this is even more dramatic than I have seen before.
-
I'm sure this has been discussed before, but don't store user passwords, don't request them, don't mandate users tell them, and don't set them to something and never allow them to be changed.
If as a domain administrator you need to get into a user profile to "have access" use your administrative credentials.
-
@DustinB3403 said in Burned by Eschewing Best Practices:
I'm sure this has been discussed before, but don't store user passwords, don't request them, don't mandate users tell them, and don't set them to something and never allow them to be changed.
If as a domain administrator you need to get into a user profile to "have access" use your administrative credentials.
That thread makes me think that after all is said and done, bad management + spineless IT guy = they will keep on having that master list of passwords.
-
@RojoLoco Yeah I figure as much, which this will just open a "he said she said" issue if something with legal ramifications occurs.
-
Um... why is this a question again? Decision: To stay physical or move to vitual
-
I had a client that maintained a password list for every employee once. I showed the boss how this was completely unnecessary, she didn't change.
-
That question reminds me of a post yesterday or so about a PCI auditor claiming to need that same info... WTF?
-
@DustinB3403 said in Burned by Eschewing Best Practices:
Um... why is this a question again? Decision: To stay physical or move to vitual
Posts like that make me think SW makes their staff create puppet accounts to post such nonsense so they will have something to feature, because apparently they have been scrambling for feature worthy posts lately.
-
I like the first line of the post... "I didn't find much searching..." I call BS... lol
-
@brianlittlejohn said in Burned by Eschewing Best Practices:
I like the first line of the post... "I didn't find much searching..." I call BS... lol
LOL. There is a lot of that.
-
@brianlittlejohn said in Burned by Eschewing Best Practices:
I like the first line of the post... "I didn't find much searching..." I call BS... lol
If they only tried the search available on the site rather than a Google site search, I might not outright laugh at them, only on the inside.
