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.
_______________________________________________
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"
