Date: Fri, 22 Jan 2021 10:09:59 +0000 From: Matt Churchyard <matt.churchyard@userve.net> To: Elena Mihailescu <elenamihailescu22@gmail.com>, "freebsd-virtualization@freebsd.org" <freebsd-virtualization@freebsd.org> Subject: RE: Warm Migration feature for bhyve - review on Phabricator Message-ID: <e9a65e1ad4e0491083820fbb03d873e8@SERVER.ad.usd-group.com> In-Reply-To: <CAGOCPLhP3i4hPcKHX=RrKFbQiSenjtJrvzTx%2BARnP8=QN%2BzmqQ@mail.gmail.com> References: <CAGOCPLhP3i4hPcKHX=RrKFbQiSenjtJrvzTx%2BARnP8=QN%2BzmqQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Hello, all, > We have recently opened a review on Phabricator for the warm migration co= de for > bhyve [1]. Please take a look and let us know if it is anything we= can improve. > [1] https://reviews.freebsd.org/D28270 > Thank you, > Elena I appreciate that this isn't really related to the current review, and comm= end the work being put into bhyve - it's an invaluable addition to FreeBSD.= I'm just wondering if any thought has been put into the future possibility= for transfer of disk data during migration (i.e. the equivalent of "storag= e vmotion") The current process (from a mile high overview) effectively seems to be the= following - * Start guest on host2 pointing at a shared disk, and halt any execution * use bhyvectl to pause and begin migration on host1 * Start the guest on host2 What would be the feasibility of being able to run a process such as the fo= llowing? Obviously it would likely need to be orchestrated by an external t= ool, but to me it seems the main requirement is really just to be able to p= rovide separate control over the pause and migrate steps on host1 - * send a ZFS snapshot of the running machine to host2 * start the guest in migrate recv mode on host2 * pause the guest on host1 * send a new snapshot * initiate the migration of memory/device data * start guest on host2 Are there any major complications here I'm not aware of other than the requ= irement to pause the guest and kick off the state migration as two separate= calls? Shared storage is great but becomes complex and expensive if you want high = performance and reliability (seeing as the storage quickly becomes a major = single point of failure without enterprise active/active kit). I suspect th= e most common deployment of bhyve is independent hosts with local ZFS pools= as this is easy/cheap and gives great performance. Most hypervisors only h= ad "shared storage" migration for a long time but the big ones now also sup= port transferring disk data live. It would be great to be able to do this o= ut of the gate. I did have a poor mans version of this in vm-bhyve, but obviously relied on= stopping and restarting the guest. I always had problems with the nc comma= nds not exiting cleanly though and hanging the process so never made it off= icial. Regards, Matt _______________________________________________ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/m= ailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscribe@freebs= d.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e9a65e1ad4e0491083820fbb03d873e8>