From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KdNed-00061I-On for qemu-devel@nongnu.org; Wed, 10 Sep 2008 07:14:36 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KdNeb-0005zj-Uu for qemu-devel@nongnu.org; Wed, 10 Sep 2008 07:14:35 -0400 Received: from [199.232.76.173] (port=33143 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KdNeb-0005zV-NS for qemu-devel@nongnu.org; Wed, 10 Sep 2008 07:14:33 -0400 Received: from mx1.redhat.com ([66.187.233.31]:57990) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KdNeb-0006OL-PA for qemu-devel@nongnu.org; Wed, 10 Sep 2008 07:14:33 -0400 Date: Wed, 10 Sep 2008 12:14:29 +0100 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] [PATCH 2/10] Allow the monitor to be suspended during non-blocking op Message-ID: <20080910111429.GK2662@redhat.com> References: <1220989802-13706-1-git-send-email-aliguori@us.ibm.com> <1220989802-13706-3-git-send-email-aliguori@us.ibm.com> <48C76EB1.6040906@qumranet.com> <20080910100520.GE2662@redhat.com> <48C7AB7C.30407@qumranet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48C7AB7C.30407@qumranet.com> Reply-To: "Daniel P. Berrange" , qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Chris Wright , Uri Lublin , Anthony Liguori , qemu-devel@nongnu.org, kvm@vger.kernel.org On Wed, Sep 10, 2008 at 02:11:56PM +0300, Avi Kivity wrote: > Daniel P. Berrange wrote: > > >>This means that migration is no longer transparent. While migration is > >>going on, you can't change the cdrom media, look at cpu registers, or do > >>anything that requires the monitor. > >> > > > >Changing cdrom media while in the middle of migration sounds like a rather > >troubleprone thing todo - you'd need to change the media in both active > >QEMU instances at the same time to be safe. > > Or rather, such state should be part of the migration. There's the > question of whether to transform the path on the target, but "which > media is in the drive" is part of the hardware state. > > (logically we would copy all of the data of all block devices, but > that's not very practical, so we assume shared storage). > > What other commands are unsafe during migration? I exclude host device > assignment which is obviously migration unfriendly. USB + virtio device attach/detach - well at least have the same need as media change - you'd need to propagate the change to the other side in some way. Currently migrate just assumes the management tool/admin has started QEMU on the destinations with the matching hardware config, and for libvirt to use the monitor to add USB /virtio devices at both ends has the race condition/synchronization problem . Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|