what are the best practices to do before virtualizing a physical DC ?
-
The article is so poorly written that it actually conflicts with itself. I feel like the author was a non-technical person doing an intro and then copy pasta for the body from someone who doesn't know virtualization or understand it.
Many of the guidelines are correct or are correct given assumptions that might be wrong. Two our downright crazy - never keep a physical DC (seriously, never, and this conflicts with the intro where he states the same) and don't use pass through disks or raw disks.
Things like don't let it be imaged are just general data base rules that apply to any database. AD uses a database, so database rules apply.
-
@scottalanmiller said:
The article is so poorly written that it actually conflicts with itself. I feel like the author was a non-technical person doing an intro and then copy pasta for the body from someone who doesn't know virtualization or understand it.
Many of the guidelines are correct or are correct given assumptions that might be wrong. Two our downright crazy - never keep a physical DC (seriously, never, and this conflicts with the intro where he states the same) and don't use pass through disks or raw disks.
Things like don't let it be imaged are just general data base rules that apply to any database. AD uses a database, so database rules apply.
Why not use raw disks?
-
@johnhooks said:
Why not use raw disks?
- No benefits to it. It's based off of one of those weird "SMBisms" that don't exist in the enterprise space where people are bizarrely trying to tweak one odd mechanism for performance that doesn't matter at all while overlooking all of the important stuff.
- It bypasses the encapsulation of the virtualization process taking away features for no reason.
-
@scottalanmiller said:
@johnhooks said:
Why not use raw disks?
- No benefits to it. It's based off of one of those weird "SMBisms" that don't exist in the enterprise space where people are bizarrely trying to tweak one odd mechanism for performance that doesn't matter at all while overlooking all of the important stuff.
- It bypasses the encapsulation of the virtualization process taking away features for no reason.
I don't really use them, I use LVMs anyway. Just curious. So qcow2 is what you recommend for an actual file?
-
For what platform?
-
@scottalanmiller said:
For what platform?
Ah I didn't read the article. Is raw on hyper-v different from raw on KVM or xen?
-
Same idea, bypassing the encapsulation of the file system to write directly to a block device not provided by the HV.
-
@scottalanmiller said:
Same idea, bypassing the encapsulation of the file system to write directly to a block device not provided by the HV.
Ok. So is LVM use a bad idea then?
-
I would not use it, we used to do that a decade ago when we had to do extreme tuning because the technology was very nascent. Today, only in extreme cases would I be willing to consider that.
-
Which formats do you recommend?
-
Generaly qcow2 for KVM.
-
@JaredBusch said:
There are only two reasons to P2V a DC.
- You have another workload on the box like file shares or something.
- See 1.
Even if you have no more licensing, spin up a new VM running Server 2008 R2, activate with your existing key, join it to the domain and then promote it to be a DC. Take the FSMO roles and then demote the old one and remove it.
i think i have that reason to P2V my DC, because this physical server actually play 3 roles :
- Domain conroller
- File Server
- SQL Server
so i think i have a reason to P2V it ??
-
@JaredBusch said:
Even if you have no more licensing, spin up a new VM running Server 2008 R2, activate with your existing key.
do you mean i have to retrieve my current physical key and use the same key in my new VM (because windows server 2008 R2 entreprise edition include 1 Physical and 2 VM) ??
-
@scottalanmiller said:
Things like don't let it be imaged are just general data base rules that apply to any database. AD uses a database, so database rules apply.
do you mean that all server that has DB on it, it is not recommended to P2V it ??
i'm confused, because almost all server has DB like DC and SQL, oracle ...... -
@IT-ADMIN said:
@JaredBusch said:
There are only two reasons to P2V a DC.
- You have another workload on the box like file shares or something.
- See 1.
Even if you have no more licensing, spin up a new VM running Server 2008 R2, activate with your existing key, join it to the domain and then promote it to be a DC. Take the FSMO roles and then demote the old one and remove it.
i think i have that reason to P2V my DC, because this physical server actually play 3 roles :
- Domain conroller
- File Server
- SQL Server
so i think i have a reason to P2V it ??
Even so, If you can, you should create a new VM, don't P2V unless you have no other options. You're still running Windows Server 2008, If you have the 2012 R2 licenses for that server, you should definitely convert.
-
@IT-ADMIN said:
i think i have that reason to P2V my DC, because this physical server actually play 3 roles :
- Domain conroller
- File Server
- SQL Server
so i think i have a reason to P2V it ??
You have have to P2V. And both DCs and SQL Server should not be P2V'd. File servers can be easily moved otherwise.
-
@IT-ADMIN said:
@scottalanmiller said:
Things like don't let it be imaged are just general data base rules that apply to any database. AD uses a database, so database rules apply.
do you mean that all server that has DB on it, it is not recommended to P2V it ??
i'm confused, because almost all server has DB like DC and SQL, oracle ......Correct. Databases should not be P2V'd unless you can shut the databases down during the move.
-
How goes your project?
