-----Original Message----- From: Miroslav Lachman <000.f...@quip.cz> Sent: 25 January 2021 10:37 To: Matt Churchyard <matt.churchy...@userve.net> Subject: Re: Warm Migration feature for bhyve - review on Phabricator
On 22/01/2021 11:09, Matt Churchyard wrote: [...] > 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 the > most common deployment of bhyve is independent hosts with local ZFS pools as > this is easy/cheap and gives great performance. Most hypervisors only had > "shared storage" migration for a long time but the big ones now also support > transferring disk data live. It would be great to be able to do this out 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 commands > not exiting cleanly though and hanging the process so never made it official. >I don't know much details about your setup and your problems with nc > (netcat) but I guess it is used for zfs send & receive. You can try to use > mbuffer from ports instead of nc: > https://everycity.co.uk/alasdair/2010/07/using-mbuffer-to-speed-up-slow-zfs-send-zfs-receive/ > It will add some dependency on other port but if somebody wants storage > migration with your greate tool vm-bhyve I think it is small price to pay. > (another way is to properly setup SSH and > do not use nc nor mbuffer) Thanks for the reply. Yes, I was using it to send zfs snapshots between hosts. I think I actually have the same issue when doing it by hand. The nc call seems like it hangs once complete but will instantly return to the prompt when pressing enter. As you say, a better solution would be to use ssh. It may even be possible to trigger the receive command directly from the sending host if I get a bit hacky and split off a second background task. I may have another look at it. It worked pretty well all in all even if it did have to stop/start the guest briefly. Matt > Kind regards > Miroslav Lachman _______________________________________________ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
