From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tomasz Chmielewski Subject: Re: I/O errors after migration - why? Date: Fri, 27 Mar 2009 18:01:52 +0100 Message-ID: <49CD0680.6090903@wpkg.org> References: <49CD0014.5020503@wpkg.org> <49CD0406.3030606@wpkg.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit To: "kvm@vger.kernel.org" Return-path: Received: from mx03.syneticon.net ([78.111.66.105]:41896 "EHLO mx03.syneticon.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753567AbZC0RB6 (ORCPT ); Fri, 27 Mar 2009 13:01:58 -0400 Received: from localhost (filter1.syneticon.net [192.168.113.83]) by mx03.syneticon.net (Postfix) with ESMTP id F25AC36145 for ; Fri, 27 Mar 2009 18:01:54 +0100 (CET) Received: from mx03.syneticon.net ([192.168.113.84]) by localhost (mx03.syneticon.net [192.168.113.83]) (amavisd-new, port 10025) with ESMTP id 44FKs5uKM1Eo for ; Fri, 27 Mar 2009 18:01:53 +0100 (CET) Received: from [192.168.10.145] (koln-4db41662.pool.einsundeins.de [77.180.22.98]) by mx03.syneticon.net (Postfix) with ESMTPSA for ; Fri, 27 Mar 2009 18:01:53 +0100 (CET) In-Reply-To: <49CD0406.3030606@wpkg.org> Sender: kvm-owner@vger.kernel.org List-ID: Tomasz Chmielewski schrieb: > Tomasz Chmielewski schrieb: >> I'm trying to perform live migration by following the instructions on >> http://www.linux-kvm.org/page/Migration. >> Unfortunately, it doesn't work very well - guest is migrated, but >> looses access to its disk. >> >> On the destination host, I'm starting the guest with exactly the same >> options as on the source host, with "-incoming tcp:0:4444". >> On the source host, I start the migration with "migrate -d tcp:B:4444". >> >> Both hosts use the same iSCSI device and can access it. >> >> Looks like the destination host can't really access the iSCSI device >> after all? No - after I reboot the guest (echo b > >> /proc/sysrq-trigger), it boots just fine from its disk. Also lsof on >> the host shows that the kvm process accesses the correct /dev/sdX device. > > Similar symptoms with virtio_blk (i.e., when guest is booted off a live > CD and tries to access the disk after migration). > > The only difference between SCSI and virtio_blk is that SCSI signals > errors and aborts, and virtio_blk waits forever and doesn't give a clue. I get this kernel BUG when I remove virtio_blk after migration (virtio block device was not mounted or used during migration). ------------[ cut here ]------------ kernel BUG at drivers/virtio/virtio.c:140! invalid opcode: 0000 [#1] SMP Modules linked in: virtio_blk(-) ipv6 video output ac battery button e1000 ppdev parport_pc i2c_piix4 i2c_core btrfs libcrc32c raid10 raid456 async_xor async_memcpy async_tx xor raid1 raid0 dm_snapshot dm_mirror dm_log dm_mod sbp2 ohci1394 ieee1394 sl811_hcd ohci_hcd uhci_hcd usb_storage ehci_hcd osst sym53c8xx atp870u hptiop ses enclosure aic79xx aic7xxx aic94xx ppa raid_class sym53c500_cs qlogic_cs qlogicfas408 aacraid imm parport mvsas libsas 3w_xxxx initio gdth arcmsr stex tmscsim dc395x iscsi_tcp 3w_9xxx a100u2w BusLogic sr_mod cdrom libsrp libiscsi st ch scsi_transport_srp scsi_transport_spi qla4xxx scsi_transport_iscsi qla2xxx lpfc scsi_transport_fc scsi_transport_sas qla1280 megaraid_sas megaraid ata_piix pdc_adma ahci sata_vsc sata_via sata_uli sata_sx4 sata_svw sata_sis sata_sil sata_sil24 sata_qstor sata_promise sata_nv sata_mv sata_inic162x scsi_wait_scan pata_via pata_triflex pata_sl82c105 pata_sis pata_sil680 pata_serverworks pata_sch pata_pdc202xx_old pata_pdc2 027x pata_pcmcia pata_opti pata_optidma pata_oldpiix pata_ns87415 pata_ns87410 pata_ninja32 pata_netcell pata_mpiix pata_marvell pata_jmicron pata_it821x pata_it8213 pata_hpt3x3 pata_hpt3x2n pata_hpt37x pata_hpt366 pata_efar pata_cypress pata_cs5530 pata_cs5520 pata_cmd64x pata_cmd640 pata_atiixp pata_artop pata_amd pata_ali pata_acpi libata Pid: 6496, comm: rmmod Not tainted (2.6.27.19-std117 #1) EIP: 0060:[] EFLAGS: 00010286 CPU: 0 EIP is at virtio_dev_remove+0x21/0x36 EAX: 000000ff EBX: d8a15c00 ECX: c132653c EDX: 0000c092 ESI: d9dcfd44 EDI: d9dcfd44 EBP: d757cef8 ESP: d757cef4 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Process rmmod (pid: 6496, ti=d757c000 task=d63998e0 task.ti=d757c000) Stack: d8a15c04 d757cf08 c07068f5 d8a15c04 d8a15cc0 d757cf1c c0706c7b d9dcfd44 00000000 c09c2cf0 d757cf30 c0705f64 00000000 d9dcfd44 00000880 d757cf40 c0706ce9 d9dcfe00 00000000 d757cf48 c077a00a d757cf50 d9dcf674 d757cfb0 Call Trace: [] ? __device_release_driver+0x5b/0x78 [] ? driver_detach+0x72/0x97 [] ? bus_remove_driver+0x63/0x7f [] ? driver_unregister+0x2a/0x2e [] ? unregister_virtio_driver+0x8/0xa [] ? cleanup_module+0x1c/0x1e [virtio_blk] [] ? sys_delete_module+0x182/0x1d0 [] ? up_read+0x8/0xa [] ? do_page_fault+0x36e/0x672 [] ? syscall_call+0x7/0xb ======================= Code: 94 c0 51 e8 0b 80 f2 ff c9 c3 55 89 e5 53 8d 58 fc 8b 93 d4 00 00 00 89 d8 ff 52 40 8b 93 40 01 00 00 89 d8 ff 52 08 84 c0 74 04 <0f> 0b eb fe 89 d8 ba 01 00 00 00 e8 f2 fe ff ff 31 c0 5b 5d c3 EIP: [] virtio_dev_remove+0x21/0x36 SS:ESP 0068:d757cef4 ---[ end trace 1d9e100e68f9d27e ]--- -- Tomasz Chmielewski http://wpkg.org