VMware Cloud Community
8c2gon
Contributor
Contributor
Jump to solution

Backup VM with physical RDM - how did you get around it?

Hi All. Can I just first say that this is a fantastic forum full of very helpful questions, and any issues I have come across I have usually been able to solve them by trucking through it - Thank you all.

I know that it is not possible to take snapshots of a VM that has physical RDM. I currenlt have 2 VM's that have these mapping and I need advise on how I can get a backup of the .vmdk for the OS only. I am currently getting my normal backup of the NT4 servers using backupexec, but this is no good for my DR scenario. I have looked at esxranger and the likes and would work fantastic if it wasn't for the RDM not allowing snapshots. Can anyone lese who is having similar issues tell me how they got around it?

One way that i can see is to setup a samba share on the ESX and a cron job to shutdown the machine do a copy to my nas and then runt he tape backup on that again and power up the machine. I don't really want to do this though for obvious reasons!

you are also probebly wondering why i don't just converst the RDM to virtual - well both machines are running very old oracle databases on NT4, and I understand vurtualising databases of any sort is now receommended - maybe i'm wrong?

Any help greatly appreciated

0 Kudos
1 Solution

Accepted Solutions
oschistad
Enthusiast
Enthusiast
Jump to solution

Obviously you should monitor these servers for any bottlenecking, but I suspect that the primary reason why the developers argued for the physical compatibility mode is simply out of caution and not due to any factual knowledge of a problem.

I recently had the opportunity to perform some real-world benchmarks comparing physical to virtual servers, and the three forms of virtual storage offered in VMware. In these tests, I discovered two interesting facts which apply to this scenario:

1: When moving the same LUN from a physical to a virtual server, you lose less than 20% even for small and heavily random activity, whereas for sequential access there was no measurable difference at all.

2: The difference between physical and virtual compatibility never exceeded 5%.

Furthermore, a RDM is just a metafile. You can delete it and recreate it without losing any data - the metadata is transient and is only used by the ESX host itself, and not the VM. This means that you can create a Virtual RDM and hook it up to your VM, and if ever you want to change you can delete it (or keep it for that matter - it's just metadata in a file system) and create a new RDM in physical compatibility. What you cannot do is to do this on the fly - your server would need to be powered off during operation.

View solution in original post

0 Kudos
11 Replies
oschistad
Enthusiast
Enthusiast
Jump to solution

The most obvious solution to your problem is to eliminate the physical RDM, either by converting it to virtual compatibility mode or by moving your data into a VMDK file on VMFS. The latter is probably not an option, but Virtual compatibility mode RDMs are safe to use and are almost identical to physical in terms of performance.

The only scenarios where physical compatibility is required is where you need SCSI-commands to transfer all the way to your actual storage system - such as when clustering physical to virtual servers, or when running SAN management software from within a VM.

gogogo5
Hot Shot
Hot Shot
Jump to solution

I would try to focus on upgrading your NT 4.0 OS to Windows 2003 (if possible). Easier said than done I know but a). NT4.0 is not supported anymore and b). imaging software such as Symantec's Backup Exec System Recovery only supports Windows 2000 or higher. Then you could use this method to take system level backups which can then be pumped through VMware Converter to convert the image to a VM ready for DR.

0 Kudos
8c2gon
Contributor
Contributor
Jump to solution

This does seem to be the only option that I could find, however I had checked with the developers of the bespoke applications held on these servers and they have advised against the virtualisation of the RAW data - that is what had put me off the idea. It is a heaveyily used application that will hopefully not be around forever but preformance is very important.

0 Kudos
8c2gon
Contributor
Contributor
Jump to solution

Updating the server to 2003 would definitly be ideal, However ther is no chance of updating this software! it's besoke and the cost of updating it (ie rewriting it!) is absolutly insane and management have refused to pay for it (with just cause)! So it's my job to keep it running. This is why i virtualised it to begin with , to keep it running away from the old hardware it was sitting on - it wasn't the most sturdy of hardware!

0 Kudos
gogogo5
Hot Shot
Hot Shot
Jump to solution

but have you told management that NT4.0 is no longer supported which means no security patches are going be released? Kinda defeats the purposes of any patch management solution you may have running only to have x number of NT4.0 servers vulnerable and potentially adding risk to your internal network.

0 Kudos
8c2gon
Contributor
Contributor
Jump to solution

Sorry oschistad, just one thing I thought of after the replied - Do you if it is possible to "roll back" if I do the Virtual option for the RDM if it is running dog slow?

(silly questions)

Does it do anything to the data on the LUN? and does it take long?

0 Kudos
8c2gon
Contributor
Contributor
Jump to solution

I only have two NT4 machines and it's these two. The idea around it is that they don't plan to use these applications forever, they are sourcing new applications - so they don't want to pay hundreds of thousands for the upgrade of these systems. However they are going to have to be stable until this happens which could well be 12months.

0 Kudos
gogogo5
Hot Shot
Hot Shot
Jump to solution

in that case, a solution that does support NT 4.0 would be Platespin's PowerConvert. So for the year you will be supporting the 2 NT 4.0 servers you could buy a 2 license conversion for v2v (yes, thats virtual-to-virtual) DR and use that. Certainly cheaper than upgrading and you can run this within a VM too.

http://www.platespin.com/Solutions/DisasterRecoveryWithImages.aspx

Good luck!

8c2gon
Contributor
Contributor
Jump to solution

Certainly looks interesting - haven't heard of this before - I have a license for esx p2v alright, but not this. I'll research this for the moment and keep oschistad's suggestion close too if I can get a second opinion on virtualising DB's

0 Kudos
oschistad
Enthusiast
Enthusiast
Jump to solution

Obviously you should monitor these servers for any bottlenecking, but I suspect that the primary reason why the developers argued for the physical compatibility mode is simply out of caution and not due to any factual knowledge of a problem.

I recently had the opportunity to perform some real-world benchmarks comparing physical to virtual servers, and the three forms of virtual storage offered in VMware. In these tests, I discovered two interesting facts which apply to this scenario:

1: When moving the same LUN from a physical to a virtual server, you lose less than 20% even for small and heavily random activity, whereas for sequential access there was no measurable difference at all.

2: The difference between physical and virtual compatibility never exceeded 5%.

Furthermore, a RDM is just a metafile. You can delete it and recreate it without losing any data - the metadata is transient and is only used by the ESX host itself, and not the VM. This means that you can create a Virtual RDM and hook it up to your VM, and if ever you want to change you can delete it (or keep it for that matter - it's just metadata in a file system) and create a new RDM in physical compatibility. What you cannot do is to do this on the fly - your server would need to be powered off during operation.

0 Kudos
8c2gon
Contributor
Contributor
Jump to solution

So just to clairify if I go ahead with this, any there are issues, I can roll back easily??

0 Kudos