From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: I/O errors after migration - why? Date: Fri, 27 Mar 2009 12:33:26 -0500 Message-ID: <49CD0DE6.50907@codemonkey.ws> References: <49CD0014.5020503@wpkg.org> <49CD0406.3030606@wpkg.org> <49CD0680.6090903@wpkg.org> <49CD0977.9060407@wpkg.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "kvm@vger.kernel.org" To: Tomasz Chmielewski Return-path: Received: from mail-qy0-f118.google.com ([209.85.221.118]:60659 "EHLO mail-qy0-f118.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752186AbZC0Rdb (ORCPT ); Fri, 27 Mar 2009 13:33:31 -0400 Received: by qyk16 with SMTP id 16so2066912qyk.33 for ; Fri, 27 Mar 2009 10:33:29 -0700 (PDT) In-Reply-To: <49CD0977.9060407@wpkg.org> Sender: kvm-owner@vger.kernel.org List-ID: Tomasz Chmielewski wrote: > Tomasz Chmielewski schrieb: >> 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. > > That is interesting (or not?). > > In monitor, after migration, "info block" says: > > scsi0-hd0: type=hd ... > > Before migration, it was: > > virtio0: type=hd ... > > ? > > On both sides the guest was started with the same option (delta > "-incoming..."). Can you give the full command line on both ends and what KVM version it is? Regards, Anthony Liguori