-
- Novice
- Posts: 9
- Liked: never
- Joined: Feb 15, 2011 8:19 pm
- Full Name: Germano Silva
- Contact:
Initial Replication Question
Hi,
We're trying out VEEAM to replicate some of our most critical VM's to an off-site location and even though we were successfull doing it with small windows VM's we are having some serious issues acomplishing the same results with a large Linux (600 GB) VM, so let me try to explain what we are seeing.
This is a VM that has seven disks ranging in size from 20GB to 200GB and each disk is on a separate LUN. We were finally able to perform an initial replication this weekend, even though it took alomost 36 hours, but in the end the replication job was not able to remove the snapshots and now I;m faced with the task of trying to cleanup after the replication job. I know I can remove snapshots but what botehrs me is that I have several VMDK and CTK-VMDK files in places where they don't belong. For some reason, and mayybe this is jus tthe way it is, replication created a copy of each VMDK and CTK-VMDK on the same volume where the VMX file resides even though only one VMDK existed, all of the other VMDK files were copies of VMDK files from the other LUN's. I haven't seen teh timestamp date on all of these fiels change, so that' a sign that they are not being used and that I can probably safely remove them, but I'm waiting a little longer to make sure.
My question is the following:
Is that the way VEEAM performs replication by creating copies of VMDK's on the same LUNas the VMX file?
If that's the case, we need to make sure we have plenty of space available on this LUN since my assumption was to make sure we have enough space available on each LUN where each VMDK file resides.
Thanks
Germano
We're trying out VEEAM to replicate some of our most critical VM's to an off-site location and even though we were successfull doing it with small windows VM's we are having some serious issues acomplishing the same results with a large Linux (600 GB) VM, so let me try to explain what we are seeing.
This is a VM that has seven disks ranging in size from 20GB to 200GB and each disk is on a separate LUN. We were finally able to perform an initial replication this weekend, even though it took alomost 36 hours, but in the end the replication job was not able to remove the snapshots and now I;m faced with the task of trying to cleanup after the replication job. I know I can remove snapshots but what botehrs me is that I have several VMDK and CTK-VMDK files in places where they don't belong. For some reason, and mayybe this is jus tthe way it is, replication created a copy of each VMDK and CTK-VMDK on the same volume where the VMX file resides even though only one VMDK existed, all of the other VMDK files were copies of VMDK files from the other LUN's. I haven't seen teh timestamp date on all of these fiels change, so that' a sign that they are not being used and that I can probably safely remove them, but I'm waiting a little longer to make sure.
My question is the following:
Is that the way VEEAM performs replication by creating copies of VMDK's on the same LUNas the VMX file?
If that's the case, we need to make sure we have plenty of space available on this LUN since my assumption was to make sure we have enough space available on each LUN where each VMDK file resides.
Thanks
Germano
-
- Chief Product Officer
- Posts: 31814
- Liked: 7302 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Initial Replication Question
Hi Germano, yes this is how it works currently. Thanks.
-
- Novice
- Posts: 9
- Liked: never
- Joined: Feb 15, 2011 8:19 pm
- Full Name: Germano Silva
- Contact:
Re: Initial Replication Question
I also assume that if the replication job had been successfull in removing the snapshots, it would also have removed all of the VMDK's, which now look like are orphaned files.
The only thing that bothers me is that VI is showing me the wrong info as gar as VMDK file locations for each VMDK when I look at the VM settings. It thinks all VMDK's are on the same LUN as the VMX file, which is not right.
The only thing that bothers me is that VI is showing me the wrong info as gar as VMDK file locations for each VMDK when I look at the VM settings. It thinks all VMDK's are on the same LUN as the VMX file, which is not right.
-
- Chief Product Officer
- Posts: 31814
- Liked: 7302 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Initial Replication Question
I cannot make any sense of this statement. Could you re-iterate please?gsilva wrote:I also assume that if the replication job had been successfull in removing the snapshots, it would also have removed all of the VMDK's, which now look like are orphaned files.
Why not right? Replica VM will indeed have all VMDK files located on the same LUN, as you correctly stated earlier.gsilva wrote:The only thing that bothers me is that VI is showing me the wrong info as gar as VMDK file locations for each VMDK when I look at the VM settings. It thinks all VMDK's are on the same LUN as the VMX file, which is not right.
-
- Novice
- Posts: 9
- Liked: never
- Joined: Feb 15, 2011 8:19 pm
- Full Name: Germano Silva
- Contact:
Re: Initial Replication Question
Let me try to clarify. Let's say I have a VM with three disks as follow:
VMX FIle on LUN_01
Disk 1 on LUN_01
Disk 2 on LUN_02
Disk 3 on LUN_03
When I look at the VM setting in VI everything looks as shown above and I have a VMDK file on each of the three LUN's but once I perform the initial replication with VEEAM, three more VMDK files are created on LUN_01 and when I now look at the VM settings in VI, it now looks as follow:
VMX FIle on LUN_01
Disk 1 on LUN_01
Disk 2 on LUN_01
Disk 3 on LUN_01
Which clearly is not the case. Maybe this is becasue the replication job failed to remove the snapshots and as such never had a chance to clear after itself, but now I have a VM with three disks and six VMDK files. As I said before, teh new VMDK files created on LUN_01 have not been touched since replication ended, so I think they are orphaned files that can be safely removed, but that's what I'm trying to determine. Can they be safely removed since they were created by the VEEAM replication.
Hope that clarifies it a bit more.
VMX FIle on LUN_01
Disk 1 on LUN_01
Disk 2 on LUN_02
Disk 3 on LUN_03
When I look at the VM setting in VI everything looks as shown above and I have a VMDK file on each of the three LUN's but once I perform the initial replication with VEEAM, three more VMDK files are created on LUN_01 and when I now look at the VM settings in VI, it now looks as follow:
VMX FIle on LUN_01
Disk 1 on LUN_01
Disk 2 on LUN_01
Disk 3 on LUN_01
Which clearly is not the case. Maybe this is becasue the replication job failed to remove the snapshots and as such never had a chance to clear after itself, but now I have a VM with three disks and six VMDK files. As I said before, teh new VMDK files created on LUN_01 have not been touched since replication ended, so I think they are orphaned files that can be safely removed, but that's what I'm trying to determine. Can they be safely removed since they were created by the VEEAM replication.
Hope that clarifies it a bit more.
-
- VP, Product Management
- Posts: 27377
- Liked: 2800 times
- Joined: Mar 30, 2009 9:13 am
- Full Name: Vitaliy Safarov
- Contact:
Re: Initial Replication Question
Germano,
Yes, that is an expected behaviour for VMware. When you create a snapshot, all your virtual disks change their source datastore to a datastore that hosts VM's VMX file, moreover all your disks are automatically marked as Thick disks.
If you have a replication job that failed to remove snapshot files, you should be following these instructions to remove them:
http://kb.vmware.com/kb/1012383
http://kb.vmware.com/kb/1007849
Thank you!
Yes, that is an expected behaviour for VMware. When you create a snapshot, all your virtual disks change their source datastore to a datastore that hosts VM's VMX file, moreover all your disks are automatically marked as Thick disks.
If you have a replication job that failed to remove snapshot files, you should be following these instructions to remove them:
http://kb.vmware.com/kb/1012383
http://kb.vmware.com/kb/1007849
Thank you!
Who is online
Users browsing this forum: Bing [Bot] and 60 guests