From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KdRpG-0004N9-BJ for qemu-devel@nongnu.org; Wed, 10 Sep 2008 11:41:50 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KdRpE-0004Lx-QI for qemu-devel@nongnu.org; Wed, 10 Sep 2008 11:41:49 -0400 Received: from [199.232.76.173] (port=43252 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KdRpE-0004Lk-A4 for qemu-devel@nongnu.org; Wed, 10 Sep 2008 11:41:48 -0400 Received: from mail-gx0-f19.google.com ([209.85.217.19]:44617) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KdRpD-0006Ov-RG for qemu-devel@nongnu.org; Wed, 10 Sep 2008 11:41:48 -0400 Received: by gxk12 with SMTP id 12so13759882gxk.10 for ; Wed, 10 Sep 2008 08:41:47 -0700 (PDT) Message-ID: <48C7EA86.2020001@codemonkey.ws> Date: Wed, 10 Sep 2008 10:40:54 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 2/10] Allow the monitor to be suspended during non-blocking op 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> <20080910111429.GK2662@redhat.com> <48C7E982.5090109@qumranet.com> In-Reply-To: <48C7E982.5090109@qumranet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: 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 , Anthony Liguori , kvm@vger.kernel.org, qemu-devel@nongnu.org, Uri Lublin Avi Kivity wrote: > Daniel P. Berrange wrote: >>> >>> 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 . >> > > Any hotplug, for that matter. > > The hardware topology should be part of the state; there is no other > way to deal with hotplug. Hotplug can create configurations that are > impossible to recreate using the command line. Yes, I agree. I'd like to introduce a "machine" section that contains nothing but a version id. v1 will simply be a placeholder. If we add new hardware to the machine type, we'll bump to v2. When we merge hot plug support, we need to add actual contents to the save section describing any hot plugged hardware. Regards, Anthony Liguori > In general a hardware device has two parts: a guest visible part and a > host interface part. For networking, that's easily visible (-net nic > and -net tap/user). For block devices, the filename and caching mode > is the host interface while, the interface type and index is the guest > part. > > Migration should transfer the guest part, and the host parts should be > specified from the command line or monitor on the migration target, as > they can change from host to host. >