From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with UTF8SMTPS id 0AB96799C8 for ; Wed, 5 May 2021 11:23:07 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with UTF8SMTP id E9F1312BF5 for ; Wed, 5 May 2021 11:22:36 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with UTF8SMTPS id 7CA4112BE7 for ; Wed, 5 May 2021 11:22:36 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with UTF8SMTP id 4992E45A92 for ; Wed, 5 May 2021 11:22:36 +0200 (CEST) Message-ID: <9a7572b0-1d7b-56b3-7daf-3667a7d85cdc@proxmox.com> Date: Wed, 5 May 2021 11:22:35 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:89.0) Gecko/20100101 Thunderbird/89.0 Content-Language: en-US To: pve-devel@lists.proxmox.com References: <1618496842.5t56y2jruz.astroid@nora.none> From: Dominik Csapak In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.016 Adjusted score from AWL reputation of From: address KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -0.001 Looks like a legit reply (A) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pve-devel] [RFC qemu-server++ 0/22] remote migration X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2021 09:23:07 -0000 On 5/5/21 08:02, aderumier@odiso.com wrote: > Hi Moula, > > local device migration is not related to this remote migration serie, > but maybe some improvement could be done. > > I'm think about usb device, where we could have the same device on > multiple hosts. (like a security dongle for example). > > I think for usb we should be able to detach/migrate/rettach. (it should > work for stateless device, but not a usb drive for example) > > Maybe for local nic pci passthroug too. > > But for gpu I'm really not sure it's possible, if you have some data in > the local gpu memory, I don't see how it's possible to get it working. > > Do you known an hypervisor with this kind of gpu migration > implementation ? > afaik, this is being worked on in qemu/kvm but needs hardware support, i.e. you can dump the internal state of a supported pci device, and migrate it to the target will probably still take a while until normal (non big datacenter) customers can use this...