From owner-freebsd-virtualization@freebsd.org Mon Mar 25 15:47:53 2019 Return-Path: Delivered-To: freebsd-virtualization@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C218215436F3 for ; Mon, 25 Mar 2019 15:47:53 +0000 (UTC) (envelope-from frank2@fjl.co.uk) Received: from bs1.fjl.org.uk (bs1.fjl.org.uk [84.45.41.196]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "bs1.fjl.org.uk", Issuer "bs1.fjl.org.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D445671C5B for ; Mon, 25 Mar 2019 15:47:48 +0000 (UTC) (envelope-from frank2@fjl.co.uk) Received: from roundcube.fjl.org.uk (localhost [127.0.0.1]) by bs1.fjl.org.uk (8.14.4/8.14.4) with ESMTP id x2PFlWg7067001 for ; Mon, 25 Mar 2019 15:47:36 GMT (envelope-from frank2@fjl.co.uk) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 25 Mar 2019 15:47:31 +0000 From: Frank Leonhardt To: freebsd-virtualization@freebsd.org Subject: Re: freebsd guest on azure Organization: FJL Microsystems In-Reply-To: <20190323185724.GA71155@rpi3.zyxst.net> References: <20190323125414.GA43521@rpi3.zyxst.net> <610D9FF5-891C-4657-BA2A-1E38D41AFF35@fjl.co.uk> <20190323185724.GA71155@rpi3.zyxst.net> Message-ID: <01e80839d622f46ad7250471608febc7@roundcube.fjl.org.uk> X-Sender: frank2@fjl.co.uk User-Agent: Roundcube Webmail/0.9.2 X-Rspamd-Queue-Id: D445671C5B X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of frank2@fjl.co.uk designates 84.45.41.196 as permitted sender) smtp.mailfrom=frank2@fjl.co.uk X-Spamd-Result: default: False [-1.42 / 15.00]; R_SPF_ALLOW(-0.20)[+ip4:84.45.41.196]; TO_DN_NONE(0.00)[]; HAS_ORG_HEADER(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[196.41.45.84.list.dnswl.org : 127.0.6.2]; MX_GOOD(-0.01)[bs1.fjl.org.uk]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:25577, ipnet:84.45.0.0/17, country:GB]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.52)[-0.520,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.91)[-0.909,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-virtualization@freebsd.org]; DMARC_NA(0.00)[fjl.co.uk]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-0.02)[country: GB(-0.09)]; NEURAL_SPAM_SHORT(0.54)[0.539,0]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 15:47:54 -0000 On 2019-03-23 18:57, tech-lists wrote: > On Sat, Mar 23, 2019 at 09:31:17PM +0800, Frank Leonhardt wrote: > >> As to your question, what I've done is run a ZFS pool and simply send >> a snapshot. > > That's a good idea. I presumed I'd be stuck just with UFS. My most > favoured way of doing this is having a zfs-vol backed vm on a freebsd > host but it's not my choice. > >> I can't remember now if I made it boot from ZFS as I prefer to boot >> from UFS > > this is me. I like to boot off something fast and simple. > >> and use ZFS for the rest. But I think I did this with Azure exactly >> because I wanted to copy the disk around. It was early last year so >> you can't quite me on it. >> >> If you're not sure about sending datasets on ZFS then ask. > > Yes please how are you invoking sending a dataset in this context? For > example, are you using compression for the data stream? If so, what > sort? Is there anything else pertinent to the azure context when using > zfs send? I have a nagging feeling that Azure insisted on its version of FreeBSD and did not install from a normal CD image. But even if this was the case, it could be different now. If it did I would have attached another vdisk for the zpool, but it means you can't transfer the OS partition. However, I don't want to do this anyway... Now I run everything in a jail, which means that the OS partition contains nothing but the base OS. I just move the jail to another host and run it there. This is also a great way of getting several VMs whilst only paying for one. So I'm only moving the dataset with the jail on it. Your friend here is the "zfs send" command. For obvious reasons (on a running system) you need to take and send a snapshot. The send command serializes the dataset and sends it to stdout (but not if it's a tty, as that would be silly). zfs recv does the opposite. You can copy datasets with something like zfs send z/test@today | zfs recv junk/foo if you want to send it to another host, use ssh. To be precise: zfs send z/test@today | ssh anotherhost zfs recv junk/foo One annoying feature was that data used to be decompressed and re-compressed on a send. You could then pipe it through compress if you wanted to save WAN bandwidth. However, since 11.2 (and 12.0) a --compressed option has appeared, which leaves the data in the state it was stored. This relies on the zpool on the other end supporting the same compression method, so I've not used this in anger yet. Using lz4 compression is normally no-brainer. Regards, Frank.