From nobody Sat Feb 24 00:46:09 2024 X-Original-To: freebsd-virtualization@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ThSr94Bf5z5BcFg for ; Sat, 24 Feb 2024 00:46:49 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ThSr92SrKz4Sxv for ; Sat, 24 Feb 2024 00:46:49 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x62d.google.com with SMTP id a640c23a62f3a-a42e2944482so20546866b.1 for ; Fri, 23 Feb 2024 16:46:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708735606; x=1709340406; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=QYyDDVjMTmmgos+d8LNfU6bAxFSGNpsxxul4GDOjQJo=; b=KEPQAhCnvrwqmim5GugdpAoN+OVpuWWNydsLkZ6FAXB+TQOIdxEQv2tbFhoRIUhHxb JHhWkj2W5Qi7dZ8ZFIOUzH3fbsAc1/2FsZGmm+mudBPjCZnQJgjdxFixlW9WQ1L8ySiq /crfEUMByPtdXqu/oJRKYerwlzZc717YbkRH0ujJefCNR+7esRTXUf6J69H9rD7UnMn1 qY9T7YqnQ3ef3meLT/ZW+Fcyz6EbA444hRYv3Y/+AgunTDyWbsWjN/FhdGjPMXGYtWUl GxaBPGNLUJQSWlcweDuF4H9XD6NExdDLfll4OPzko6Xk304tEtdYye4XKdsB7kbcvSrA doZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708735606; x=1709340406; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=QYyDDVjMTmmgos+d8LNfU6bAxFSGNpsxxul4GDOjQJo=; b=PycRTCxESUGw0UQmdISkm1dHUAUNm47kvQD5bZEtS1ZfQakX5HMhewBq/he6SQs7R8 YAwIiCvHqpHgZaIuRiXey3ZhzaZm49pNUnSkWrlmFN4OXz1BmL/mlATGUPw4fCmGld6s 686GDJvfiJEjIVm4k1W06Xd/dGZKy4xxMtjrFmN82b4QeAZ2jae3FWjn/zsTs/ha3IUZ 93MJ10IJZGcY9QVIwSg7AhXMWxJhUSoB/ZccRcMN71QGdgqfNjqw9NB1kHQsz5FtQ+uv ExzZCpp6iR9tNlGsszuOEB/uuWpxcatOhnf3jpjwG+RtnIbaJ/o13h0AyhNa+Vp9mXc7 Wohw== X-Gm-Message-State: AOJu0Yw/DdTRnV2SRQQtlW81kACRJlTNdmA+DDuo8GfNr+1feBHuWWLr pf0mtQGd5o/92qYtyUk8ke1pD9S0VHvlBjGVsTTzqP6By0dP0AcrICkmjF2APL8m0gBQ/P9d0m0 W63xJIvQYN5QmD05RJ+BJF4LkBIMAVQbxxNw= X-Google-Smtp-Source: AGHT+IEQlHEcjS/pMVKiaHeojYA0+v6wuw6VVNLTI/md9iILRmH8N64j16ZOdlnh6xjE6mBK3W4yEyhBWgHX6gLMpqk= X-Received: by 2002:a17:906:289b:b0:a3f:d797:42ec with SMTP id o27-20020a170906289b00b00a3fd79742ecmr940937ejd.53.1708735605814; Fri, 23 Feb 2024 16:46:45 -0800 (PST) List-Id: Discussion List-Archive: https://lists.freebsd.org/archives/freebsd-virtualization List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-virtualization@freebsd.org X-BeenThere: freebsd-virtualization@freebsd.org MIME-Version: 1.0 References: <163e57a9-0b61-414c-a8f7-109f5ac90f69@durchholz.org> <4073dc47-528e-493b-a28e-a21aff733225@durchholz.org> In-Reply-To: <4073dc47-528e-493b-a28e-a21aff733225@durchholz.org> From: Mario Marietto Date: Sat, 24 Feb 2024 01:46:09 +0100 Message-ID: Subject: Re: Best way to have a FreeBSD VM for automated testing? To: Jo Durchholz Cc: "freebsd-virtualization@FreeBSD.org" Content-Type: multipart/alternative; boundary="000000000000ccba570612160246" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4ThSr92SrKz4Sxv --000000000000ccba570612160246 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFPM Jo Durchholz wr= ote: > 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=3D2,cores=3D2,threads=3D2 -m 8G -w = -H -A \ > > -s 0,hostbridge \ > > -s > > > 1,virtio-blk,/mnt/zroot2/zroot2/bhyve/img/Linux/Ubuntu2310.img,bootindex= =3D1 \ > > -s 11,hda,play=3D/dev/dsp,rec=3D/dev/dsp \ > > -s 13,virtio-net,tap19 \ > > -s 14,virtio-9p,sharename=3D/ \ > > -s 30,xhci,tablet \ > > -s 31,lpc \ > > -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI_CODE.fd \ > > vm0:19/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=E2=80=AFPM Jo Durchholz > > 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 tes= t > > 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 multipl= e > > 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. > > > --=20 Mario. --000000000000ccba570612160246 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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=E2= =80=AFPM 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=3D2,cores=3D2,threads=3D2 -m 8G -w= -H -A \
> -s 0,hostbridge \
> -s
> 1,virtio-blk,/mnt/zroot2/zroot2/bhyve/img/Linux/Ubuntu2310.img,bootind= ex=3D1 \
> -s 11,hda,play=3D/dev/dsp,rec=3D/dev/dsp \
> -s 13,virtio-net,tap19 \
> -s 14,virtio-9p,sharename=3D/ \
> -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 <= br> 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&#= 39;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=E2=80=AFPM Jo Durchholz <jo@durchholz.org
> <mailto:jo@du= rchholz.org>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Hi all,
>
>=C2=A0 =C2=A0 =C2=A0I'm in repeatable build land, working in Linux = and developing a FreeBSD
>=C2=A0 =C2=A0 =C2=A0appliance.
>
>=C2=A0 =C2=A0 =C2=A0For tests, I need to run a FreeBSD VM, put some Pyt= hon code and test
>=C2=A0 =C2=A0 =C2=A0data into it, run the script, and get the test resu= lts back.
>
>=C2=A0 =C2=A0 =C2=A0Repeatability means: Everything done with the VM ne= eds to be scriptable
>=C2=A0 =C2=A0 =C2=A0(using a GUI for exploring is okay but things have = to translate).
>=C2=A0 =C2=A0 =C2=A0Which in turn means that every setup step for a Fre= eBSD image comes
>=C2=A0 =C2=A0 =C2=A0with
>=C2=A0 =C2=A0 =C2=A0a pretty high coding and maintenance cost.
>
>=C2=A0 =C2=A0 =C2=A0So my question is:
>=C2=A0 =C2=A0 =C2=A0What's the FreeBSD image that has the least num= ber of steps to get the
>=C2=A0 =C2=A0 =C2=A0base system up and running? I suppose it's the = VM-IMAGES section,
>=C2=A0 =C2=A0 =C2=A0but is
>=C2=A0 =C2=A0 =C2=A0this correct?
>
>=C2=A0 =C2=A0 =C2=A0Follow-up question:
>=C2=A0 =C2=A0 =C2=A0The startup time needs to be as fast as possible. S= ub-second would be
>=C2=A0 =C2=A0 =C2=A0great ("don't disrupt the developer's = thought stream").
>=C2=A0 =C2=A0 =C2=A0I see the boot process from a vanilla VM-IMAGES ima= ge takes multiple
>=C2=A0 =C2=A0 =C2=A0seconds; can this be sped up to just a few seconds,= or do I need to run
>=C2=A0 =C2=A0 =C2=A0the setup and create a VM snapshot at which the VM = starts for each
>=C2=A0 =C2=A0 =C2=A0test run?
>
>=C2=A0 =C2=A0 =C2=A0Regards,
>=C2=A0 =C2=A0 =C2=A0Jo
>
>
>
> --
> Mario.




--
Mario.
--000000000000ccba570612160246--