> - Rsyncing the VMs while they are running leaves them in an
> inconsistent state. This state may or may not be worse than a simple
> crash situation. One way I have been getting around this is by
> creating a snapshot of the VM before performing the rsync, and when
> bringing up the copy after a crash, revert to the snapshot. That will
> at least give you consistent filesystem and memory state, but could
> cause issues with network connections. I usually reboot the VM
> cleanly after reverting to the snapshot.
The problem with doing snapshot is, the data reverts to whatever it
was at the point of the snapshot. The client can accept waiting for
3~4 hrs for their servers to be fixed every now and then. It's a mess
of several servers ranging from almost 10yrs old we inherited from
their past vendors.
Which is why they would readily accept even 1hr of downtime for a VM
image to be transferred. But they will not accept the need to redo
work. Even if they are willing, it isn't possible because of the
server generated number sequences that would already be used by their
clients but would not likely match the new numbers after a restore to
an older snapshot.
> Rsync will not transfer the entire file when transferring over the
> network. It scans the whole thing and only sends changes. If you
> have --progress enabled it will appear to go through the whole file,
> but you will see the "speedup" go much higher than a regular transfer.
> However, sometimes this process can take more time than doing a full
> copy on a local network. Rsync is meant to conserve bandwidth, not
> necessarily time. Also, I suggest the you use a GB network if you
> have the option. If not you could directly link the network ports on
> 2 servers and copy straight from 1 to the other.
They already have GB switches so not a problem if rsync works
incrementally on images as well.
At the same time, I do have reservations about such a hack so I'm also
exploring the other possibility of implementing a 2 machine Lustre
cluster and run all images from that storage cluster instead. That
would take an extra machine but still more viable than the 2x option
and much faster to get back up.
> If you are looking at VMware Server for this, here are some tips:
> - For best performance, search around for "vmware tmpfs". It will
> dramatically increase the performance of the VMs at the expense of
> some memory.
Thanks for the tip.
> - VMware Server seems like it's EOL, even though vmware hasn't
> specifically said so yet
> - There is a bug in VMware with CentOS that causes guests to slowly
> use more CPU until the whole machine is bogged down. This can be
> fixed by restarting or suspend/resume each VM
It explains a puzzling seemingly random freeze up we get with a
particular test system. I guess the random part was because we do
sus/restart the machine every now and then so it didn't always bog
down to the point we'd notice.
Thanks again for the responses :)
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
