Veeam Seeding issue.

[zongchan]

Hey All,

Been trying to call Veeam support this morning but it keeps going to Tim Lardners Voice MAIL!
Also open a support ticket yesterday and they emailed me a reference to these forums which was not particularly helpful, so I thought I'd put the issue to you guys.

Ok I got a woozie.

I replicated client VM's to a temporaray full esx 4 box and then moved it to the offsite location.
Vmotioned the replica machines to the end target full esx 4 box.
Moved the VM's into the VeeamBackup folder.
Renamed all the folders to the original vmname(123) and copied the left over vrb and vbk files.
This process was followed so we could transport VM's in thin format and also end up at target host in thin format.

Changed the job and started wan replication, with success.

To find out doing a test restore that it hadn't actually updated the vmname.vmdk it has created a new smaller one.
The original seed vmdk was vmname_replica.vmdk which I probably should of renamed during the seed process.

Now I have vmname_replica.vmdk (Unmodified since seed) and a new small vmname.vmdk.(Getting updated at every replicate job)

So it looks like veeam has written new changes to a new file instead of the original vmdk cause of the correct name.

Is there a way I can reset the VEEAM job and discard replicates I did after the seed, so I can rename the vmname_replica.vmdk and start if I just seeded the job.

Or is there a way I can manually update the vmname_replica.vmdk with the small vmname.vmdk and then end up with a merged/up to date vmname.vmdk?

Or delete the vmname.vmdk, rename vmname_replica.vmdk and replay the vrb and vbk to get the original vmdk up to date ?

Any help would be appreciated

Thanks,

Zong

[Vitaliy S.]

Hello Zong,

I don't think that merging two vmdk files or re-applying VBK and VRB files is possible. You need to re-seed your VM in order to be on the safe side. By the way have enhanced our seeding engine in v6, and this would allow you to avoid such issues with the next release.

Thank you.

[zongchan]

Thanx Vitaliy,
Support got back to me and also confirmed that there was no way to fix this issue and I had to reseed.

This time I'll connect an NFS store directly to the temp esx server and use rsync, excluding vmdk's, to copy the whole VeeamBackup folder to this new datastore. Then manually copy, using vmkfstools, the left over vmdk's to their respective folders.

Z

[zongchan]

OK using this new seeding process for mirroring the VeeamBackup folder did not work.

I used rsync to copy the whole folder excluding *.vmdk and then manually cloned each vmdk in thin format using vmkfstools.

Reconfigured the job succesfully to the offsite full ESX and it is moving the whole size of the VM again.

Has anyone done a seeding process with thin provisioned disks successfully?
I have a site that has overly provisioned disks and not able to leave it in THICK format.

Thanks,

Zong.

[Bunce]

Has anyone done a seeding process with thin provisioned disks successfully?

I seem to remember Tom posting a method for doing this some time ago. Haven't been able to find the post as yet though..

Anton might be able to shed some light on it?

[Vitaliy S.]

I haven't found that post either, but as far as I remember it should be something like this:

1. perform replication job to a removable storage locally
2. move this storage to offsite location and then mount it to a new destination host
3. on doing that, just change replication job destination and that's it.

By the way, how do you determine that your previous method didn't work? Was there any error? Have you noticed any VRB files created on the target datastore?

Thanks.

[JZTOR]

Hi all,
I am having the same problem. I need to setup replication for 10 VMs – all thin 2 TB total with allocated space (flat) 7 TB. It has to be done in a week. WAN replication speed is up to 4 GB per hour.
The seeding to flat is painful and I will need much more storage on the DR site.
Did someone try this?
1. Option 1
- Replicate locally
- Copy (not vmotion) entire folder to the removable drive
- On DR site copy from drive to the datastore
- Retarget the replication job
2. Option2
- Seed to flat file locally
- Move file to DR site and establish replication
- Convert VM on DR site using VMware Converter from Thick to Thin?
- Continue replication

Thank you for your help!
Joseph

[Vitaliy S.]

Hello Joseph,

The first option should work, actually it is exactly what I've written above. Please note your removable drive should be VMFS formatted, as thin provisioned disks is VMFS-specific feature, and such disks simply cannot be stored in thin form on "regular" file systems like NTFS or ext3, which are unaware about thin provisioning.

Thanks.

[Gostev]

Just a quick note, v6 supports seeding thin disks as thin (because of entirely new seeding approach). Thanks.

[JZTOR]

Thank you, Vitaliy & Anton. It will be a great feature. At this moment I am using the cheap iomega device as iSCSI storage and replicating big VMs on production site. For small VMs I am creating direct replication jobs. Next week we will move this device to DR site, copy folders to the DR SAN and try to re-establish the replication jobs. I will update this thread with a result after done.

Regards

[JZTOR]

Hi All,

I am working on a procedure above and when I am moving data - VM folders from the temporary VMFS datastore to the DR storage, VMware converting my thin VMs to flat. Here are two problems; first – I need now much more space and the second - one VM (file server) has provisioned size 1.1 TB that exceeding size of storage LUNs/VMFS datastores on DR site.
Question. Is it any way to save the “thin” during the copying procedure?

Thank you very much guys for all your advices/ideas.

Cheers.

[Vitaliy S.]

Have you tried copying these files via FastSCP (copy/paste) which is built-in to Veeam B&R product?

[Gostev]

This won't help Vitaly, as FastSCP had never supported thin disks... guess the only real option here is to wait for v6.

[JZTOR]

Just a brief update.
The procedure with replication to local VMFS storage and copy entire folders to DR site was working for me. For the file server 1.1 TB the 2 TB LUN/VMSF datastore (8M block size) was created on DR VMware cluster. After I updated target for replication job to new datastore, the system was able successfully finish old replication job and save the changes in VM folder on DR site. Please note that source datastore has 4 MB block size.
Best.

[smile_dav]

[merged]

Hi,

We are currently trying to replicate thin provisioned VMs from site A to site B.
As the link between the sites are slow, we chose to replicate the source to a removable HDD first, then copy the files into the datastore at site B. This however, seems to cause the VMs to lose the thin provisioned property.
Is this normal? Could we keep the thin provisioning? If not, is there any work-arounds?

Another issue we are experiencing is the _working.vmdk file size is equal to the .vmdk size. Is this just a bug on the datastore browser?

Your help is much appreciated!
Thanks!

[Vitaliy S.]

Another issue we are experiencing is the _working.vmdk file size is equal to the .vmdk size. Is this just a bug on the datastore browser?

To know the details about *working.vmdk, please check out this thread: Replication question