VMware Cloud Community
jjohnsonclt
Contributor
Contributor

difference in vmdk files/moving data from ntfs lun to vmfs lun

We are in the process of virtualizing several servers from one data center to another. We have several servers that are accessing a shared SAN storage at the existing facility. We have to migrate this data off the shared SAN and bring it over to our own SAN.

Our plan is to virtualize the data partition to a temporary LUN on the SAN and then do a fiber to fiber copy on a server with Fiber HBAs. This LUN will be formatted in NTFS. We will then transport that server to the new datacenter and attach it to our fiber network and get the LUN viewed by ESX.

I believe (correct me if I am wrong) that ESX can view an NTFS lun directly. Our plan would be to copy the vmdk files from the NTFS lun to the VMFS LUN.

The question is this:

Is the format of a VMDK file while converting to a standard VMware image the same as a vmdk file created by ESX. Can you for instance run Vmware converter on the OS partition and import it directly into ESX and then simply add the virtual disk in the properties of the VM.

Will ESX read that vmdk file without having to do anything else to it?

What we are trying to avoid here is having the massive 500 gb partitions going through Ethernet and if we run the vmware converter for these to import it back into esx it will be going through IP and therefore going through Ethernet. We need to be able to get this vmdk file into ESX through a fibre connection.

Reply
0 Kudos
5 Replies
JoJoGabor
Expert
Expert

I assume you are converting from VMware Server to VMware ESX? How are your VMware Server disks configured? These will either be in VMDK format or may be a RAM LUN mapping formatted with NTFS (I'm not sure if VMware Server supports this)

If the data volumes truly are a Raw Data Mapping (RDM) then why not just keep it in RDM format, replicate using your Storage replication, then Just P2V the system volumes into ESX vmdk format and map an RDM thorugh the VM?

Reply
0 Kudos
RParker
Immortal
Immortal

Our plan is to virtualize the data partition to a temporary LUN on the SAN and then do a fiber to fiber copy on a server with Fiber HBAs. This LUN will be formatted in NTFS. We will then transport that server to the new datacenter and attach it to our fiber network and get the LUN viewed by ESX.

I believe (correct me if I am wrong) that ESX can view an NTFS lun directly

NO ESX cannot access NTFS. LUNS must be VMFS only.ESX can access a LUN, and it can be presented AS a RAW format, but that's a pass through, and since it's RAW the VM has direct access via the ESX server, but ESX cannot use this to put VM's on directly. And RAW means RAW, no NTFS, VMFS or otherwise, there is no Format on it, that's what you do inside the VM with the guest you install.

Reply
0 Kudos
jjohnsonclt
Contributor
Contributor

Thanks for the reply.

We have physical servers that we are converting, but we dont want to convert directly to ESX over the wire (100 mb link between the data centers) for mass amount of data.

So when converting the data volume, we would have to choose a standard vmware image file instead of ESX.

I want to be able to get these vmdk files directly into the vmfs stores through fibre and not have to go through the import process if possible because that would go through ethernet.

Reply
0 Kudos
RParker
Immortal
Immortal

So when converting the data volume, we would have to choose a standard vmware image file instead of ESX.

It looks like you have to go the Ethernet route. I don't see any alternative. A LUN still can be done via Fiber, but as the format is different you can't use it as is, so if you do the Fiber to Fiber copy, you would have to use something else to move it off NTFS LUN onto VMFS LUN which is done over Ethernet.

Reply
0 Kudos
JoJoGabor
Expert
Expert

If your existing physical servers are SAN attached for the data drives (eg 😧 and E:) and you can replicate those 😧 and E: LUNS to your new SAN, you dont need to convert those, you just convert the C: drive into a VMDK them present the replicated volumes as an RDM.

Reply
0 Kudos