Re: Best way to have a FreeBSD VM for automated testing?

I forgot to say that I want to create a different FreeBSD flavour that will
have a lot of virtual machines already embedded and ready to work and that
work transparently.

On Fri, Feb 23, 2024 at 10:37 PM Jo Durchholz <jo@durchholz.org> wrote:

> On 23.02.24 19:41, Mario Marietto wrote:
> > To speed up the booting of a bhyve VM I'm using this method :
> >
> > nohup /usr/sbin/bhyve -S -c sockets=2,cores=2,threads=2 -m 8G -w -H -A \
> > -s 0,hostbridge \
> > -s
> >
> 1,virtio-blk,/mnt/zroot2/zroot2/bhyve/img/Linux/Ubuntu2310.img,bootindex=1 \
> > -s 11,hda,play=/dev/dsp,rec=/dev/dsp \
> > -s 13,virtio-net,tap19 \
> > -s 14,virtio-9p,sharename=/ \
> > -s 30,xhci,tablet \
> > -s 31,lpc \
> > -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI_CODE.fd \
> > vm0:19</dev/null >/dev/null 2>&1 &
> > if test -f nohup.out; then rm -r nohup.out
> > fi
>
> Hmmm... my knee-jerk reaction was that bhyve runs on FreeBSD and I want
> to use a Linux host, but to my surprise, yeah you can run byhve on Linux.
>
> However, it's an additional layer, which means more potential failure
> modes, and it requires extra configuration on the system level which
> means it's another small entry barrier for new contributors.
>
> So... no bhyve for me.
> (Note that this does not mean that there's no merit in the approach!
> Just that it does not fit my project's priorities.)
>
> Do you know how to translate all these bhyve options to a KVM or Vagrant
> incantation? I know too little about either to be confident in what I'd
> produce.
> Maybe a short explanation of each parameter would help? Why is it there,
> what problem does it solve, that kind of information, just to get me
> started so I can focus on those options that are actually relevant to
> the applicance I'm trying to set up.
>
> > I've installed a ssh server within the vm and I connect to it from
> > FreeBSD using ssh -Y user@IP ; it's faster. But the project is not
> > completed. I want to install VirGL to have the graphic acceleration
> > without using the real GPU of the host inside the VM.
>
> Heh. Yet another rabbit hole. Good luck with that!
> I have to say I'm lucky that my project is just a web server so I don't
> need that.
>
> Anyway: Thanks for the info! Knowing what you're doing tells everybody a
> lot about what's routine and what isn't, and that's valuable.
>
> Regards,
> Jo
>
> > On Fri, Feb 23, 2024 at 8:17 PM Jo Durchholz <jo@durchholz.org
> > <mailto:jo@durchholz.org>> wrote:
> >
> >     Hi all,
> >
> >     I'm in repeatable build land, working in Linux and developing a
> FreeBSD
> >     appliance.
> >
> >     For tests, I need to run a FreeBSD VM, put some Python code and test
> >     data into it, run the script, and get the test results back.
> >
> >     Repeatability means: Everything done with the VM needs to be
> scriptable
> >     (using a GUI for exploring is okay but things have to translate).
> >     Which in turn means that every setup step for a FreeBSD image comes
> >     with
> >     a pretty high coding and maintenance cost.
> >
> >     So my question is:
> >     What's the FreeBSD image that has the least number of steps to get
> the
> >     base system up and running? I suppose it's the VM-IMAGES section,
> >     but is
> >     this correct?
> >
> >     Follow-up question:
> >     The startup time needs to be as fast as possible. Sub-second would be
> >     great ("don't disrupt the developer's thought stream").
> >     I see the boot process from a vanilla VM-IMAGES image takes multiple
> >     seconds; can this be sped up to just a few seconds, or do I need to
> run
> >     the setup and create a VM snapshot at which the VM starts for each
> >     test run?
> >
> >     Regards,
> >     Jo
> >
> >
> >
> > --
> > Mario.
>
>
>

-- 
Mario.