Le 11/12/2018 à 15:51, Konstantin Shalygin a écrit : > >> Currently I plan a migration of a large VM (MS Exchange, 300 Mailboxes >> and 900GB DB) from qcow2 on ext4 (RAID1) to an all-flash Ceph luminous >> cluster (which already holds lot's of images). >> The server has access to both local and cluster-storage, I only need >> to live migrate the storage, not machine. >> >> I have never used live migration as it can cause more issues and the >> VMs that are already migrated, had planned downtime. >> Taking the VM offline and convert/import using qemu-img would take >> some hours but I would like to still serve clients, even if it is >> slower. >> >> The VM is I/O-heavy in terms of the old storage (LSI/Adaptec with >> BBU). There are two HDDs bound as RAID1 which are constantly under 30% >> - 60% load (this goes up to 100% during reboot, updates or login >> prime-time). >> >> What happens when either the local compute node or the ceph cluster >> fails (degraded)? Or network is unavailable? >> Are all writes performed to both locations? Is this fail-safe? Or does >> the VM crash in worst case, which can lead to dirty shutdown for MS-EX >> DBs? >> >> The node currently has 4GB free RAM and 29GB listed as cache / >> available. These numbers need caution because we have "tuned" enabled >> which causes de-deplication on RAM and this host runs about 10 Windows >> VMs. >> During reboots or updates, RAM can get full again. >> >> Maybe I am to cautious about live-storage-migration, maybe I am not. >> >> What are your experiences or advices? >> >> Thank you very much! > > I was read your message two times and still can't figure out what is > your question? > > You need move your block image from some storage to Ceph? No, you > can't do this without downtime because fs consistency. > > You can easy migrate your filesystem via rsync for example, with small > downtime for reboot VM. >
I believe OP is trying to use the storage migration feature of QEMU. I've never tried it and I wouldn't recommend it (probably not very tested and there is a large window for failure). One tactic that can be used assuming OP is using LVM in the VM for storage is to add a Ceph volume to the VM (probably needs a reboot) add the corresponding virtual disk to the VM volume group and then migrate all data from the logical volume(s) to the new disk. LVM is using mirroring internally during the transfer so you get robustness by using it. It can be slow (especially with old kernels) but at least it is safe. I've done a DRBD to Ceph migration with this process 5 years ago. When all logical volumes are moved to the new disk you can remove the old disk from the volume group. Assuming everything is on LVM including the root filesystem, only moving the boot partition will have to be done outside of LVM. Best regards, Lionel
_______________________________________________ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
