any problem to copy a VM from one server to another

[SebastiaNet]

As we have 3 identical hardware servers (x3850-M2) with the same software (ESX v 4.0.1),I was thinking on having a copy of every Virtual Machine on the other machine's disks.

I am thinking to use "TAR" to create a single file (instead of 5-8-10) and then "SCP" to copy the TGZ file to second server.

Do you think that VM will work properly when un-tared on second server, should the first fail ?

Thanks for any ideas. Sebastian.

PD.- I am using VMware Converter to put the VM's on the server(s), but it is a very "manual" job, while the TAR+SCP could be easily "automated" ...

[biokovo]

I think it is better idea to create scheduled tasks and clone your VMs automatically or manual, like yoor wish.

I don't think you can just copy and paste your .vmdk file while VM is running?!

[bggb29]

What is your goal disaster recovery in case you lose a server.

scp will work, but the copy time is slow. In order to tar the server it will have to be shutdown.

You could use the ghettovbs and set your servers up for nfs mount a ext3 volume and copy the servers over in sparse mode.

While they guest is up and running.

[paradox]

It depends on how often you wish for the copy to occur and if it will need to be a manual or automatic process.

If its once every 6 months then VMware Converter is the easy way to do this, it can also be done without any interruption to the source machines. However I would generally recommend stopping key services, e.g. SQL,Exchange etc.

You could even look at the lefthand VSA to hand the mirroring between local disk for you at the block level. There are lots of ways to do it, variables are around RTO (recover time objective), RPO (recover point objective) and the frequency in which you want to replicate with how much interactive effort will affect the cost, reliability and speed of the job.

I hope this helps

Dan

[SebastiaNet]

Thanks for all your answers.

Few comments :

a) yes, our goal is to be protected for the case a server crashes and we still need the VM to run (on second server)

b) we plan to do it let's say once a month

c) I plan to stop the VM's in order to TAR them - there is no problem to do it (once a month) in our environment

d) no problem TAR and SCP is slow - we shall use the whole wwekend to copy 20 VM's (20 GB each) - it takes less than 1 hour each (aprox)

So, I still have my question un-answered :

do you think the Virtual Machine copied this way (TAR+SCP) shall run without problems on second server ?

Thanks a lot for sharing your opinions. Sebastian.

[biokovo]

It deppends on some configuration parametars.

Why don't you just try one of these copied VM?!

[SebastiaNet]

Yes, that is what I am doing right now, but I am having a wide range of small problems,

and I am not sure they are caused by the "copy" operation,

so I wanted to know the opinion in a more gerenal approach.

Thanks for your time and patience. Sebastian.

[paradox]

Couple of points:

A cp (unix command) is not aware of VMFS, so it will interfere with normal I/O's to the VMFS volume. e.g. that why you should use vmkfstools to clone a disk instead of CP. Generally speaking using traditional unix tools rather than the VMware tools will cause performance or configuration problems. I would steer away from this approach (tar, copy) even if it does work. You may find issues down the track with it. Having said that, if you don't have budget for shared storage or tools then your choices are limited.

I gather you don't have vCenter or shard storage which is why you are looking at this approach.

I would still strongly recommend using VMware Converter as its aware of the file systems in question and will create consistent copies. It should also handle the white space. All given from a nice GUI that anybody can operate. You will find that many systems will not need an outage for using this technique. However its a bit harder to automate unless you purchase the enterprise version.

Another way to handle this is to utilize snapshots, you can then do your copy without interruption to the source machines (crash consistent, which most customers are happy to wear considering how often you will actually have to do a recovery). Somebody is already done the hard work to put all this in a script. http://www.vmts.net/vmbk3.htm I suspect this may be more to your liking.

Good Luck and please flick me some points if this helps!

Dan

[SebastiaNet]

Thanks a lot Dan.

I understand SCP is not aware of any VMware operations, but I want to insist that my Virtual Machines are stopped when I am copying them.

just few questions related to your post :

(a) "use vmkfstools to clone a disk" - what improvements does it provide (over SCP), once we are sure the VM's are stopped ?

(b) "budget for shared storage" - we do have a shared storage (DS3400), but still dont have vCenter to move a VM in DS3400 from one server to another.

Do you think this is the best solution : DS-3400 + vCenter ?

(c) VMware Converter : we have 50 VM's and I pretend a mensual backup. I cant do that manually, I hope you agree.

Can you confirm that the "enterprise version" can be automated ?

Thanks again. Sebastian.

[paradox]

a) if any VM's are running then there will be an increased impact on disk performance by not using vmware tools. This is because VMFS I/O is managed by the VMKernel and is aware of the best way to lay writes down and pick data up off the disk. The key point I try and make to customers is that ESX is NOT a linux system. ESX should not be managed by unix admins as they tend to try and manage the system in the unix way when its not a unix system. ESX 4 as an example has the SC running in a VM itself. ESX servers run a VMkernel, the SC just exists to provide a management interface. In future versions (e.g. i machines) the SC is removed.

Its important to remember that the entire infrastructure is built around a model in which the VM's can have image based backups taken while the machines are running. but I know you want them off so i'll leave that there.

b) if your using shared storage you can run the VM's directly off the storage. There is no need for vCenter to do this. Then you don't need to copy machines, just add them on the host you want to run them on (5 second job). vCenter will give you cloning and cluster based features, but shared storage is a basic feature of ESX.

Please award some point if you find this of use!

[SebastiaNet]

Thanks, Dan - your answer is very positive.

Just in case you didn't see my 3rd-question .... I will repeat it :

You say "However its a bit harder to automate unless you purchase the enterprise version"

Question : Can you confirm that the "enterprise version" can be automated ?

I mean "is specifically prepared to be automated", has specific facilities for doing it ....

Or you just mean "the enterprise version is EASIER to automate" .... ?

Cheers. Sebastian.

[benp23]

VCB has worked extremely well for us monthly by just running vcbmounter out of scheduled tasks on a proxy vm and sending the VCB image of the vm to a network share. The command we run is as follows: "C:\Program Files\VMware\VMware Consolidated Backup Framework\vcbMounter.exe" -h FQDNofvcenterserver -u user -p password -a ipaddr:IPofvm -r z:\networkshare -t fullvm -m nbd -L6. Have you tried VCB?

Regards,

benp23

[SebastiaNet]

No, Ben, I have not tried VCB - in fact I have no idea of what is it ...

Can you provide a URL, or a pointer to some documentation ?

Thanks a lot.

[sim0]

I have read several indications that the best way to do this (if you do not have access to VCB) is to shutdown the VM and export it as a virtual appliance. The virtual appliance can then be imported into another host.

The main benefits of this method are:

1. The VMDK is copied but is the size of the data on the disk rather than the allocated size of the VMDK. Smaller copies!

2. Apparently if you just copy the VMDK it can cause perfomance issues when it is put back into production as the VMDK disk is no longer "aligned". This method negates that issue. I am still researching exactly what is meant by "aligned".

We have started doing this in order to have a baseline backup of all our server VMs, I have not yet tried importing the virtual appliances into a second host as we currently run a single ESXi instance.

HTH

[benp23]

Sure, it's very easy to set up. Here's a link to the documentation:

http://www.vmware.com/support/pubs/vcb_pubs.html

benp23

[tik2]

From what I've read, cloning the disk with `vmkfstools -i` after unarchiving a tarballed VM eliminates fragmentation issues that might've occurred during the SCP (source: http://itknowledgeexchange.techtarget.com/virtualization-pro/temporarily-moving-vms-off-an-esx-host/.... Granted the article is almost a year old by now, shouldn't the same hold true for ESX4?

Until I'm able to implement vCenter Server, I'm currently running the same full-VM backup that SebastiaNet is talking about - powering down the guest every month and tar'ing/scp'ing its contents to a secondary ESX host. There don't seem to be any problems restoring the VM to a different host during the occasional DR drill...

[SebastiaNet]

Thanks, mr SIM. Just 2 small items :

a) "export it as a virtual appliance" means "to use VMware Convert" ?

b) shall you find any documentation on that "alignement", could you share it, please ?

Have a Nice 2010 !

[SebastiaNet]

Thanks, mr Tik - it is good to know the road I am following is not so bad .... jejeje

I think the fragmentation problem arises when you SCP a VMDK file .... but not when you copy a TGZ file.

Anyway, I shall have a loook at that "vmkfstools -i" command ....

Have a Nice 2010 !

[sim0]

>> a) export it as a virtual appliance" means "to use VMware Convert" ?

In the vSphere Client: File>Export>Export OVF Template.

>>b) shall you find any documentation on that "alignement", could you share it, please ?

No Problem.

Happy 2010 yourself.

[SebastiaNet]

Guau ! That "OVF Template" feature was also unknown to me ... Is it another was to have a backup ???

Reading the "Help" :

+ + +

+ + +