I'll try and make a cleaner guide later..

First, spin up your ProxmoxVE system. During the install wizard, I left the boot drive as LVM but did change it to XFS instead of ext4. You do not setup secondary drives during the install wizard. Once up, you need to create the ZFS store on each system, named the same, prior to joining the cluster. The replication process wants the ZFS pool to be named the same on both systems and you cannot name it the same (at least in the GUI) if it already exists anywhere in the cluster.
3c9d3871-d8f6-4da0-93fd-22bf8526ef6b-image.png Then from the GUI, go to the disks of system 1.
67ae2a41-d84b-4fbc-9cd0-4dea04cb5465-image.png then click on ZFS and create the storage pool name it, single disk, compression off.
4379c8d3-edf1-4733-95ce-d3bc5f2400e9-image.png wait for it to show normal.
145f1381-2d1e-4215-b29c-30e2227c00d2-image.png then repeat the process on the second system. make sure to use the same name. Now create the cluster and join the second system to the cluster.
e9401472-ad68-433a-b569-5cc14f21552d-image.png You will not see the storage on ZFS storage on system 2 when it first loads up.
0e6e610a-21fd-4317-9f15-336eec787af3-image.png But it does exist if you look.
d5efc711-8126-4e30-955a-9d0deba7db10-image.png To make it available, go to storage under datacenter.
545a0b08-72e0-4912-bf3c-f10ce2527d73-image.png edit the existing "data" and add pve2
d8022847-45ea-46ce-be11-807f01e51449-image.png now it will show up and be available for use.
a68a5b5c-3024-4650-869b-c36065713c87-image.png

Is this perfect? No. but it is how I was able to get it setup to work.

The manual leave out quite a bit of specifics. on how to do things, but goes into detail on the technical of things.

@DustinB3403
I don't doubt it.
There wasn't really any added complexity though. PVE was installed with all the defaults.

You can have replication if you have Starwind Clustering on the hosts (That's how I have some customers). That said, even on those situations I have a DC on the Local Host Hyperv of one of the servers or have a Site to Site VPN with a DC on Azure or AWS as a failsafe.

@phlipelder said in Use Hyper-V to replicate Linux vm file share:

@scottalanmiller said in Use Hyper-V to replicate Linux vm file share:

@phlipelder said in Use Hyper-V to replicate Linux vm file share:

Hyper-V Replica would work in this situation with a few caveats.

There is a 15 second limit on replication cycles. If the VMs are running database/active services this could be a problem.

That would be handled earlier in the process by the backup job. If the backup is good, the replication won't cause an issue. If the backup is bad, the replication can't fix it, of course, but will replicate the bad backup. But the only place that this can be addressed is in the backup step, the replication is of backup files, so not at a point in the process where it matters.

"Garbage in garbage out" never seems to go away. It's been the bane of our existence since the switch to image/block based backups. :S

File backups suffered from this, too. Databases are just hard to back up.

@JaredBusch said in KVM VM Replication:

@scottalanmiller said in KVM VM Replication:

Just using the search is best

Tags.

yeah, having tags on the topics makes them better than pinning.

@mlnews

Thread resurrected !!!

I see, interesting . Regarding Ovirt + GLusterFs my update on this is that did learn glustering and it was easy to perform. I didnt apply it in production or VMs. I did use Ovirt a month ago and it was very slow web ui experience.

I should write a thread about my and Gluster.

@JaredBusch I also didn't mind about zerto at the time because my resellers (asked a couple) offered really high prices - but don't remember the specific amount.

@beta said in SW Port - New Server for virtual host - Sanity Check:

Oh, one thing I was really curious about too, would it make sense to get an extra drive as a hot spare? Normally with OBR10 and spinning HDD, I'd put every spindle into the array, but since SSDs are going to give me plenty of IOPS and capacity, I didn't know if it is a good/bad idea with OBR5.

The rule of "no hot spare ever" for RAID 5 still applies. If you were going to do this, you would do OBR 6. OBR6 can make loads of sense here, but OBR5 + HS does not.

But it is up to you, depends on cost and risk aversion.

@dbeato said in JRNL_WRAP_ERROR (SYSVOL):

@wirestyle22 You can still do the following as well:
http://kpytko.pl/active-directory-domain-services/authoritative-sysvol-restore-frs/
https://blogs.msmvps.com/acefekay/2013/08/28/how-to-recover-a-journal-wrap-error-jrnl_wrap_error-and-a-corrupted-sysvol-from-a-good-dc-what-option-do-i-use-d4-or-d2-whats-the-difference-between-d4-and-d2/

Maybe also move to DFRS instead of FRS, you would only use FRS if it is Server 2003 as part of one of your DCs

Possibly in the future but I have so many other things to focus on

@thwr said in DCs out of sync:

@Dashrender said in DCs out of sync:

@thwr said in DCs out of sync:

No substantial changes have been made during the last couple of weeks. Just a few new users and password changes plus maybe 2 or 3 new machine accounts. Some clients and servers now refuse to authenticate users during login due to the well known "trust could not be established between..." error.

Where you still getting those errors after you powered down the broken DC? I'm guessing not since you moved forward with the install of another DC.

Nope. Only "missing that other DC" errors now, which is fine. I've got some crappy internet connection (free WiFi in the train, next to no 3G/4G signal) here and can't check the current state. but it was fine half an our ago.

OK, reading your OP, it seemed that you were getting those errors after turning off the broken DC, but since you're not - seems like you found a good solution.

@scottalanmiller said in SQL mirroring advise:

@Ambarishrh said in SQL mirroring advise:

@scottalanmiller said in SQL mirroring advise:

@Ambarishrh said in SQL mirroring advise:

@scottalanmiller said in SQL mirroring advise:

@Ambarishrh said in SQL mirroring advise:

@Dashrender said in SQL mirroring advise:

Are the two SQL servers sitting side by side? If not, shared storage and low latency for it's use would be super expensive.

Though I do wonder how their DR plan works if there isn't a cluster for the DB, what purpose does the second server serve? Warm spare?

Yes the servers are side by side, basically just sits there, and when a new site is created on SP side, run the script which mirrors the new DB created on server 1 to server 2. Eventually they were planning to introduce the witness server once our testing is complete and then enable auto failover. The downside here is that someone need to manually run the script for db mirroring of new databases

So the big thing here is that the databases are not mirrored, just the framework (schema) is at creation time. Very different from mirroring or clustering at that aspect level.

Yes, we've told them this won't work and asked them to look at a clustered setup. Since the licenses are already in place and is SQL standard no option for Always-On. I want to know what would be the drawbacks for the clustered setup, as for sure there are some more advantages on Always-ON compared to the clustered setup.

Won't work... for what? What's the end goal?

Won't work: Current stage its 2 separate DB servers and mirroring needs to be done by executing a script whenever there is a new db is created by SP.

End Goal: A fully automated failover setup giving high availability for the SharePoint solution

What they are doing is unrelated to their end goal. How does mirroring database creation help with failover. There isn't even a first step in preparing for a failover here. What is going on is totally something different.

Exactly what i was asking earlier.