VMDK Preseeding deadline
thank you all in advance for the time that you will give to my topic.
We are investigating on the preseeding option in order to move some “fat” virtual machines.
The article is clear about how it works and how to do it (http://www.zerto.com/myzerto/knowledge-base/copy-vmdk-disks-for-preseeding/) but my question is: for how many days cloned vmdk is still valid.
In other words, with an example: today I clone a virtual machine and store its vmdks. Can I use those vmdks for preseeding a month later or Zerto will avoid the preseeding and start a new, fresh sync over network?
Thank you again
I understand the delta will grove based on the amount of data changed till the clone phase but you confirm that it will never exprire, so at least…. a 30% (the operating system let say) will be still valid. On a 20 tb of data would be a good 6tb less. Correct me if I’m wrong.
Anyway: thank you again for the replay
Shannon can correct me if I’m wrong here, but I don’t think time has anything to do with the ability to use it as a pre-seeded disk. If you can start the process after 1 day, or 10 days, or 30 days, or 60 days, I don’t think it matters. As long as that disk has not had any material changes to its properties (i.e. change in size or type) then you should be able to use an old copy as a seed disk just fine. Certainly the longer the time, the more blocks will have changed on the source, thus your initial comparison check will be longer, but I think you already understand that. I really don’t see why any length of time would preclude you from using it as a seed disk, as long as the disk and vm properties haven’t changed.
usually I say my coworkers to get disks to the recovery site ASAP since we usually don’t have very high speed connections for example right now I am preseeding a 6TB VM which VMDKs are a week old… using 15MB link I see is going to take about 2 days for delta completion… but like you mention here also depends on the amount of changes in the original VMDK since the preseeding for what I see is a matter of vmdk comparisong (like integrity) and send blocks which have changed… Once I had customer whose VM we were not able to replicate, this time the VMDK was almost 2 days old but the rate change for that MV was crazy…. it ended up being a pretty nasty data base configuration which later was corrected by some IT consultants, I remember I mentioned to my customer that according to the write change rate (zerto excel) a 55MB link was needed only for that VM… so something was not working fine