Burned by Eschewing Best Practices
-
@DustinB3403 said in Burned by Eschewing Best Practices:
@scottalanmiller He's a SSD expert, or just claiming to be?
DOn't know but he's in every discussion on it.
-
Hrm.. would be good to have a few conversations with him regarding Micrsoft SSD.
Is he over here at ML? I'm tired of posting there.
-
@DustinB3403 said in Burned by Eschewing Best Practices:
Hrm.. would be good to have a few conversations with him regarding Micrsoft SSD.
Is he over here at ML? I'm tired of posting there.
Do we really want such "experts" over here? Part of what I love about ML is the lack of those people.
-
@RojoLoco said in Burned by Eschewing Best Practices:
@DustinB3403 said in Burned by Eschewing Best Practices:
Hrm.. would be good to have a few conversations with him regarding Micrsoft SSD.
Is he over here at ML? I'm tired of posting there.
Do we really want such "experts" over here? Part of what I love about ML is the lack of those people.
Fair point, but at least it would provide some insight into the Microsoft SSD design / setup / functionality without any of us putting our systems or labs at risk.
-
@DustinB3403 said in Burned by Eschewing Best Practices:
@RojoLoco said in Burned by Eschewing Best Practices:
@DustinB3403 said in Burned by Eschewing Best Practices:
Hrm.. would be good to have a few conversations with him regarding Micrsoft SSD.
Is he over here at ML? I'm tired of posting there.
Do we really want such "experts" over here? Part of what I love about ML is the lack of those people.
Fair point, but at least it would provide some insight into the Microsoft SSD design / setup / functionality without any of us putting our systems or labs at risk.
That's true, assuming he knows what he's talking about.
-
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.
-
@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
