It creates zvols (block devices) for VMs and datasets (filesystems) for LXCs. You don't want to mount the zvols on the host as mounting a block device twice will corrupt its data. And you won't see it with ls as a zvol isn't a file. Think of it like a LV in case you are familiar with LVM or like a physical partition which ls won't show too.
It creates zvols (block devices) for VMs and datasets (filesystems) for LXCs. You don't want to mount the zvols on the host as mounting a block device twice will corrupt its data. And you won't see it with ls as a zvol isn't a file. Think of it like a LV in case you are familiar with LVM or lik a physical partition which ls won't show too.
thank you. does it depends on the format of the disk that they are stored as zvols?? all my disk are raw. if i would have, for example, a vmware file to import as .qcow2, how is it stored on zfs?
You can't store qcow2 on a "ZFS" type storage as qcow2 are files and zvols got no filesystem so they can't store files. I you want to store VM disks as qcow2 you would need to use a "Directory" type storage (which could point to an mountpoint of an ZFS dataset). Would be better to use qm import to import that qcow2 and convert it into a zvol. Only good reason I could think of why it might be beneficial to use qcow2 on top of ZFS would be in case you want snapshots where you would be able to freely roll back and forth between different restore points.
PS: Dont use qcow2 just to avoid to learn how to properly work with ZFS. Its a good thing that there are no image files. This means you can skip that nested filesystem, another layer of CoW and all that unnecessary overhead these would cause.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.