Hello Steffen, > are the virtualisation hosts based on equal hardware (especially cpu)? for the first case I reported, the boxes were identical. For the second try I reported, target machine is a little different, but CPU supports all the features of the source machine.
> > What are the qemu parameters for the disks? Do you use virtio drivers > and caching options? for source machines I had caching disabled, as it's not safe for migration For target ceph-based machines, I have caching enabled in writeback mode, and as well as discard. with offline conversion, everything went fine.. BR nik as for disk buses, it differs, some are IDE, some virtio-blk. > > My default is > > -drive > format=rbd,file=rbd:kvm/awv66_c:id=kvm,media=disk,if=virtio,discard=on,cache=writethrough > > where kvm is the storage pool awv66_c the virtual disk. > > And when you convert die virtual disc with qemu-convert offline all is fine? > > Regards > > Steffen > > >>> Nikola Ciprich <nikola.cipr...@linuxbox.cz> schrieb am Dienstag, 19. > >>> Januar > 2016 um 07:58: > > 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 > > ------------------------------------- > > -- > 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 -------------------------------------
pgpaR4182tPCi.pgp
Description: PGP signature
