Date: Sat, 28 Apr 2018 14:26:30 +0300 From: Daniel Braniss <danny@cs.huji.ac.il> To: Mark Raynsford <list+org.freebsd.virtualization@io7m.com> Cc: freebsd-virtualization@freebsd.org Subject: Re: Read-only view of a ZFS filesystem inside a bhyve guest? Message-ID: <E3FEEF2F-2AFA-4ED1-8342-A0FEEF1A0EFF@cs.huji.ac.il> In-Reply-To: <20180428113748.72891422@almond.int.arc7.info> References: <20180427174341.03373bc8@almond.int.arc7.info> <FCEED1DB-80FA-4407-9017-9B17F6E155B9@cs.huji.ac.il> <20180428113748.72891422@almond.int.arc7.info>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 28 Apr 2018, at 13:37, Mark Raynsford <list+org.freebsd.virtualization@io7m.com> wrote: > > On 2018-04-28T09:08:42 +0300 > Daniel Braniss <danny@cs.huji.ac.il> wrote: > >> since the clients and the server are sharing the zfs volume, >> I’m doing the following: >> on the server I did: >> zfs create -sV 4G h/root.ro <http://root.ro/>; >> newfs /dev/zvol/h/root.ro <http://root.ro/>; >> mount /dev/zol/h/root.ro <http://root.ro/>; /mnt >> copy a working root image to it. >> umount /mnt >> the clients then mount it as ro, >> the vm conflg file has: >> disk0_type=virtio-blk” >> disk0_name=“/dev/zvol/h/root.ro <http://root.ro/> >> disk0_dev=“custom” >> >> one solution to the fact that the root is read-only is to use unionfs (probably nullfs will do too) >> >> the only problem I have is updating the image. > > Wow, didn't know this was possible. Is this safe? Two essentially > independent operating system instances being able to write to the same > zvol? that’s why it’s mounted rear-only in the client! each client can get another vol for writing, ie /var if you want to have ‘permanent’ changes that will survive reboots. updating on the server is possible, but 1- the changes might not be seen by the client 2- opened files will have issues btw, point 2 is also true for NFS. danny > > -- > Mark Raynsford | http://www.io7m.com >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E3FEEF2F-2AFA-4ED1-8342-A0FEEF1A0EFF>