So I've done another test and unfortunately I can confirm that this kind of migration leads to data corruption - I've run chkdisk prior to migration, everything went without errors, then tried it after migration and it reported corrupted filesystem indexes again - I needed to reboot the machine and have it fixed.. (windows 2012 R2 again)
any ideas? BR nik On Wed, Jan 13, 2016 at 01:30:28PM +0100, Nikola Ciprich wrote: > Hello Steffen, > > thanks for your reply.. > > > 1. Did you test a migration to non-rbd storage succesfully without this > > bad behavior after migration? > nope, I was onbly testing migration to RBD, but it seemed to be OK. I only > have this one windows VM which seemed to be damaged, but I'm not sure if > it was caused by migration or not.. but it seems to be strange coincidence, > so I'm rather paranoid here.. > > > > > > 2. Did you install and run another vm on your rbd storage? Does this vm > > perform normally? > yes, there are other machines working on this storage without issues.. > also I've migrated other vms using this procedure without issues > > so I'm still uncertain now, whether it's safe or not.. > > BR > > nik > > > > > > > > > Regards > > > > Steffen > > > > > > >>> Nikola Ciprich <nikola.cipr...@linuxbox.cz> schrieb am Mittwoch, 13. > > >>> Januar > > 2016 um 08:29: > > > Hello qemu users, > > > > > > I'd like to ask about nonshared migration.. > > > > > > I have a server with virtual machines running on raw block devices.. > > > I'd like to migrate those to ceph / RBD storage without downtime. > > > > > > I've tested following procedure (I'm using qemu-kvm + libvirt based > > > management) > > > > > > 1) create RBD devices of the same size > > > 2) create new XML domain definition file with storage changed to new RBD > > > devices (vm-new.xml) > > > 3) migrate vm using libvirt: > > > migrate --verbose --xml /tmp/vm-new.xml --copy-storage-all --live vmlbx50 > > > qemu+tcp://lbxphav1a/system > > > > > > this seemed to do the trick, I've tested it for both linux and windows > > > machines. > > > > > > however, one windows 2k12 machine slowed down badly after migration, and > > > after reboot, > > > chkdisk showed lots of corrupted filesystem indexes (i'm not windows > > > guru, > > > so > > > hopefully I'm not confusing this much). After fixing those, everything > > > started > > > working OK again, but I'm now concerned whether this procedure is really > > > safe.. > > > > > > is there enybody who could confirm or comment on this? > > > I'm using qemu-2.2.1 and libvirt 1.2.6 on source machine, > > > qemu-2.3.0 and libvirt 1.2.15 on target box.. > > > > > > thanks a lot in advance! > > > > > > BR > > > > > > nik > > > > > > -- > > > ------------------------------------- > > > Ing. Nikola CIPRICH > > > LinuxBox.cz, s.r.o. > > > 28.rijna 168, 709 00 Ostrava > > > > > > tel.: +420 591 166 214 > > > fax: +420 596 621 273 > > > mobil: +420 777 093 799 > > > www.linuxbox.cz > > > > > > mobil servis: +420 737 238 656 > > > email servis: ser...@linuxbox.cz > > > ------------------------------------- > > > > > > -- > > Klinik-Service Neubrandenburg GmbH > > Allendestr. 30, 17036 Neubrandenburg > > Amtsgericht Neubrandenburg, HRB 2457 > > Geschaeftsfuehrerin: Gudrun Kappich > > > > > > -- > ------------------------------------- > Ing. Nikola CIPRICH > LinuxBox.cz, s.r.o. > 28.rijna 168, 709 00 Ostrava > > tel.: +420 591 166 214 > fax: +420 596 621 273 > mobil: +420 777 093 799 > www.linuxbox.cz > > mobil servis: +420 737 238 656 > email servis: ser...@linuxbox.cz > ------------------------------------- -- ------------------------------------- Ing. Nikola CIPRICH LinuxBox.cz, s.r.o. 28.rijna 168, 709 00 Ostrava tel.: +420 591 166 214 fax: +420 596 621 273 mobil: +420 777 093 799 www.linuxbox.cz mobil servis: +420 737 238 656 email servis: ser...@linuxbox.cz -------------------------------------
pgptMYQPirKmz.pgp
Description: PGP signature
