From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A233B2701BC for ; Wed, 23 Apr 2025 20:53:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745441597; cv=none; b=e54zeXnaF41SwXRmUbJtP+xF01ZcsfIXPf0YqZ1Cdr7XVtp13LA4yjg2h38JhJzeEPfAQYdtJ2Qj8IvOiU+A/54t5DbQA0fIStETLYXitiWTe+Y3XA3MfxWawtjKsf2WFrpd6QLcCu/fE+AetvtM7merryVYm0bRfHkCowGYrzo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745441597; c=relaxed/simple; bh=QO1IB3slBvYKWHVONIuNWwn+KqIp6773j2MjCRXYj/0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=WViwDk08G0J25qiOXHc7D10ilOw3U6DfhXD6pg4QxRvYqrANky0rvafKAN65pcy2kY2wbhFUH6x49u1C5FZMHBMdhdex5vE4CFXkYH38xJ4tPOt6x9OPEYBxvrOiQ/+R1dAtW3f1MKq1XbwxQcWivc4w3bQWwF7lVZZ16+wzFPs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=S7Gi683w; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="S7Gi683w" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6CFA9C4CEE2; Wed, 23 Apr 2025 20:53:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745441597; bh=QO1IB3slBvYKWHVONIuNWwn+KqIp6773j2MjCRXYj/0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=S7Gi683wbxfRm2nUxIYIRZ2/pkXifVcx6dun3UJ00FAwr7Ml9pJIWalHEZ/IESo0a raQqCruXyd+sMF3Cu8zZzqcR1z+SkBrQXmUSeQjZZ3e4sJoW4aXRzLEtTlMh5VlEyc 3LEO46bmy2AWuBsrEG8t/S51epthoBupBkcadW5Qdy+nxvIxhgAmkT//sJCZDQzJo6 1CTtGeTTk/zMv01QSvyWLjgn/7wJKfDXRzZQFmQzx4XB16rhmarwHb3Mls5Q5ZxKrR mdFX/ym09XFM4FWdQC5zKZRS+JK9KDdTVk4ZzT67yweqyu1OO8sVHQRrfjzlihc4t8 ynmBk+5fWcbjQ== Date: Wed, 23 Apr 2025 13:53:16 -0700 From: Luis Chamberlain To: Andreas Hindborg Cc: Chuck Lever , kdevops@lists.linux.dev Subject: Re: guestfs storage paths are confusing Message-ID: References: <7adea286-8981-46cd-9751-a7add11d9e85@oracle.com> <87h62wboj8.fsf@metaspace.dk> <8734dznv6z.fsf@metaspace.dk> Precedence: bulk X-Mailing-List: kdevops@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8734dznv6z.fsf@metaspace.dk> On Wed, Apr 23, 2025 at 08:22:50AM +0000, Andreas Hindborg wrote: > "Luis Chamberlain" writes: > > > On Thu, Apr 10, 2025 at 04:58:59AM +0000, Andreas Hindborg wrote: > >> "Luis Chamberlain" writes: > >> > >> > On Wed, Apr 09, 2025 at 10:55:58AM -0400, Chuck Lever wrote: > >> >> One complaint about kdevops I sometimes hear is the requirement for > >> >> frequent root access on the control host. kdevops is better off reducing > >> >> its privilege footprint, IMHO. > >> > > >> > I agree, I think at this point it its clear that although kdevops has > >> > ways to help with a first bringup, that just scares a larger crowd. And > >> > we can simplify our code if we completley move all those requirements > >> > to an *optional* installation phase, done only once. > >> > >> The real question is, why does kdevops even need root? If you can rely > >> on user space networking with slirp, > > > > By default edora distros use libvirt with user session, debian distros > > use the system session. What do you mean by a slirp exactly? Got a > > config for it? > > Slirp is the user mode network stack you get with `-netdev user,...` > [1]. That seems like its the same thing as what we refer to as user session. Ie, you need qemu:///session to use slirp, instead of the debian default of system session qemu:///system. > I don't think libvirt is fitting for kdevops use case either. You can > just run qemu directly. libvirt makes sense if you want to spin up > virtual machines across a cluster in an enterprise setting. It is made > to be consumed by the next layer of management software in the stack, > not fore direct user interaction. KDevops deployments are not complex > enough to benefit from libvirt. Just because there is a use case for a simple qemu throw away guest does not mean there's no reason for users of kdevops to leverage libvirt. kdevops was built to *scale*. Dozens of guest, not just one or two. Sometimes over 50. In such cases -- those hosts can benefit from uber optimizaitons. Which is why we have hypervisor optimizations we've learned over the years to enable on the host as well, like KSM and zswap. libvirt by default can leverage a lot of CoW mechanisms if you share the same guest. 50 guests * simple qemu without optimal libvirt qemu options to share a base file doesn't scale so well. So yes, we can have a "I am ok to shoot myself on the foot with my own virtualization configuration don't worry" option, it does not negate the goal to also *scale* to about 50 guests even with Nix OS optimally. That's how we scale for CIs. > You can compose the qemu command from ansible based on your kconfig > values. Everything you need is in the qemu manual/wiki. There are plenty > of qemu wrappers to gather inspiration from, such as vm-ctl [2], > virtme-ng [3], run-kernel [4]. I wrote the last one. Until I get to it, patches welcomed :) Luis