Re: [Qemu-discuss] Antw: Re: Antw: raw block -> RBD live migration

[Nikola Ciprich]

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 <address@hidden> 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 <address@hidden> 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: address@hidden 
> >> > > -------------------------------------
> >> > 
> >> > 
> >> > -- 
> >> > 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: address@hidden 
> >> -------------------------------------
> > 
> > 
> > 
> > -- 
> > -------------------------------------
> > 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: address@hidden 
> > -------------------------------------
> 
> -- 
> 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: address@hidden
-------------------------------------

pgpJKJvpPA2fQ.pgp
Description: PGP signature