From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 29B3FC7EE43 for ; Mon, 12 Jun 2023 19:56:23 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q8ndn-0006w5-9j; Mon, 12 Jun 2023 15:55:51 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q8ndZ-0006s9-AD for qemu-devel@nongnu.org; Mon, 12 Jun 2023 15:55:43 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q8ndV-0002aB-Ub for qemu-devel@nongnu.org; Mon, 12 Jun 2023 15:55:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1686599732; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=n4j0wyWg13B9F3SP2Ggfa4RVJQXhooE2MVh+v70BjFo=; b=D4iF8w5DwxugkAb7zYqOHiPjeDhcWL1QVEHzdfOf7PMsZgoDHMxRA4mz6CBTOYz86BZt8H jffLo1jfHpCfA6mr7BybJ5ucmRUt7W7X2jXODLXtTwGlV1oQuVnYN3lbDW+Acgf7b0vDUz hdMtlZkgWbnTMMBFMXY2Xm1Y+SxYLtI= Received: from mail-qt1-f200.google.com (mail-qt1-f200.google.com [209.85.160.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-198-Ae9mSUeAONO4pBbI1LCpVQ-1; Mon, 12 Jun 2023 15:55:29 -0400 X-MC-Unique: Ae9mSUeAONO4pBbI1LCpVQ-1 Received: by mail-qt1-f200.google.com with SMTP id d75a77b69052e-3f9e7a1caf2so6443151cf.0 for ; Mon, 12 Jun 2023 12:55:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686599729; x=1689191729; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=n4j0wyWg13B9F3SP2Ggfa4RVJQXhooE2MVh+v70BjFo=; b=fnRRoi5Fz8Ndk2KHvViBfRcOg/aWpQbgFnKHyyTLQLRq13KkcQPjrSESEp0nqgi3qv B0WnKEi0MKd5F5fLRTLuikltfcYmXb58LKZez/pcoTsSbQMaGuGaEzZQoecNTGx/uruz JgKpfGpnneWdFS0WUudSu6MC5NsedGB0iBrHGdlcvHjMY8XwlUDZPpp3KeAskNjMjNdQ R9nBOfIchUDPAtdI9J/bUfnWLKr8tm8/T9MZbkfTO5kydkZ3WD/mH5yGBeHOBEToI0+x BemzjkuETudHO5YIPgHAshuDqIk+PmdzFjFK7/80cITAP4CQyzXLRQLFry+X+ZekQ6iy GeTw== X-Gm-Message-State: AC+VfDwHPUQ6eSBnJ+PUIDg60Gv86EVUU1ll0vzhyIG0TiqOtILpmx4O dZIbSShqPTzEK8uE4hXNs/8ceeRUwKtDhnTFY8Om1DlnWB7LYgQehEU2/tv5qA7aTbk0yDyP8dK rx1fP8eMNs/vIYYU= X-Received: by 2002:a05:622a:1a25:b0:3f6:b493:8ee4 with SMTP id f37-20020a05622a1a2500b003f6b4938ee4mr13421405qtb.0.1686599728999; Mon, 12 Jun 2023 12:55:28 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5SFFfwpKVLwLZzEFCA0MQ9QFkP6IaGlgtFVmEzNCkHc7BSpRkhaKYp4LDf38z5YtDUpXaoRA== X-Received: by 2002:a05:622a:1a25:b0:3f6:b493:8ee4 with SMTP id f37-20020a05622a1a2500b003f6b4938ee4mr13421398qtb.0.1686599728749; Mon, 12 Jun 2023 12:55:28 -0700 (PDT) Received: from x1n (cpe5c7695f3aee0-cm5c7695f3aede.cpe.net.cable.rogers.com. [99.254.144.39]) by smtp.gmail.com with ESMTPSA id z16-20020ac87cb0000000b003e69c51cf53sm3643970qtv.72.2023.06.12.12.55.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Jun 2023 12:55:28 -0700 (PDT) Date: Mon, 12 Jun 2023 15:55:26 -0400 From: Peter Xu To: Steven Sistare Cc: qemu-devel@nongnu.org, Juan Quintela , "Daniel P. Berrange" , Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= Subject: Re: [PATCH V2] migration: file URI Message-ID: References: <1686163139-256654-1-git-send-email-steven.sistare@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Received-SPF: pass client-ip=170.10.133.124; envelope-from=peterx@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org On Mon, Jun 12, 2023 at 03:39:34PM -0400, Steven Sistare wrote: > On 6/12/2023 2:44 PM, Peter Xu wrote: > > Hi, Steve, > > > > On Wed, Jun 07, 2023 at 11:38:59AM -0700, Steve Sistare wrote: > >> Extend the migration URI to support file:. This can be used for > >> any migration scenario that does not require a reverse path. It can be used > >> as an alternative to 'exec:cat > file' in minimized containers that do not > >> contain /bin/sh, and it is easier to use than the fd: URI. It can > >> be used in HMP commands, and as a qemu command-line parameter. > > > > I have similar question on the fixed-ram work, > > Sorry, what is the "fixed-ram work"? https://lore.kernel.org/all/20230330180336.2791-1-farosas@suse.de It has similar requirement to migrate to a file, though slightly different use case. > > > on whether we should assume > > the vm stopped before doing so. Again, it leaves us space for > > optimizations on top without breaking anyone. > > I do not assume the vm is stopped. The migration code will stop the vm > in migration_iteration_finish. > > > The other thing is considering a very busy guest, migration may not even > > converge for "file:" URI (the same to other URIs) but I think that doesn't > > make much sense to not converge for a "file:" URI. The user might be very > > confused too. > > The file URI is mainly intended for the case where guest ram is backed by shared memory > and preserved in place, in which case writes are not tracked and convergence is not an > issue. If not shared memory, the user should be advised to stop the machine first. > I should document these notes in qemu-options and/or migration.json. My question was whether we should treat "file:" differently from most of other URIs. It makes the URI slightly tricky for sure, but it also does make sense to me because "file:" implies more than the rest URIs, where we're sure about the consequence of the migration (vm stops), in that case keeping vm live makes it less performant, and also weird. It doesn't need to be special in memory type being shared, e.g. what if there's a device that contains a lot of data to migrate in the future? Assuming "shared memory will always migrate very fast" may not hold true. Do you think it makes more sense to just always stop VM when migrating to file URI? Then if someone tries to restart the VM or cancel the migration, we always do both (cancel migration, then start VM). -- Peter Xu