From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-10626.protonmail.ch (mail-10626.protonmail.ch [79.135.106.26]) (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 8D56626C3B3 for ; Wed, 23 Apr 2025 08:22:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=79.135.106.26 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745396582; cv=none; b=eRXmF8if+VlQqtD63B3Ucnv106L0JRZ+xnmGq4iTqHkJcCjBqUzdgZIOOMofiHJQmBG+yG4g4rmQoB5XTqMcEsP5iwVFO6fMQAJO1f98CK0gWf7Z9+MZLi+boD1ziy1le7m3oJ3qTOBBSmgOab0TvObAwajSvO4qjRb24mO93ic= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745396582; c=relaxed/simple; bh=ZwwdLnOcB2SNi1XErLgmsXDn5FBOcd1xdWPYv5lTq+I=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=TnZ5IRPb3aLJVQ8i98LLQog22NloAk9ly3a5YLZXZu6+EWTwX27t2QDRUTdYJSVhZoYHTcJsZN00oiC5VV4Y8AibU1BAK28btrq0VxIKK3mLK37KOryll3YE2LCgAoLsoMuS2xO1wl5M4h1ID77wAQ5GaQEj8gxZng5pbKEk1L4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=metaspace.dk; spf=pass smtp.mailfrom=metaspace.dk; dkim=pass (2048-bit key) header.d=metaspace.dk header.i=@metaspace.dk header.b=skilQhHu; arc=none smtp.client-ip=79.135.106.26 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=metaspace.dk Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=metaspace.dk Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=metaspace.dk header.i=@metaspace.dk header.b="skilQhHu" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaspace.dk; s=protonmail2; t=1745396574; x=1745655774; bh=vLylt0LunaFBf+yefS2lH63qShvM7dU7zlCnzy/8djo=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=skilQhHuxfXQrQRti79ZZsWjHcJgoSHntgtIGP3HDo6E/GfkDrGQqXbTmKT9uhJVe hsvrhpsJ4j3/fnc0x4wLeOvLy70ayG4jYRBvfWx8MP/LfQUwdboWVZ3gcCUUkECDCn luxqAHLWgaPOZHRhuG9AvoR2e7jL9wdlu9abjjd+oKAj71T2Gby2d1qY71eWuIKj3R fN1NPgllOMp8/lNK2AgVN4jxBGTc7eSb/Eq1oa8TdxGjl3aZaW8jjcy/p6BLrvl/IR nUVgKq/bjhNpGoEELvAg6Ky8hv1WVuOXUCdr69Pn+93AW0c5o/FRLCzwjHSRcUuXJA 1LdsFQvVlLUdg== Date: Wed, 23 Apr 2025 08:22:50 +0000 To: Luis Chamberlain From: Andreas Hindborg Cc: Chuck Lever , kdevops@lists.linux.dev Subject: Re: guestfs storage paths are confusing Message-ID: <8734dznv6z.fsf@metaspace.dk> In-Reply-To: References: <7adea286-8981-46cd-9751-a7add11d9e85@oracle.com> <87h62wboj8.fsf@metaspace.dk> Feedback-ID: 113830118:user:proton X-Pm-Message-ID: a0abfd86a61955478bf046aaefbe138b3bc62646 Precedence: bulk X-Mailing-List: kdevops@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable "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 reduc= ing >> >> 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. An= d >> > 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]. 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. >> nothing in the process of spinning >> up a VM should require root privileges. If the user has access to kvm, >> which is common these days. > > Yeah sure, agreed. Then we just needs docs for what's needed or > an optional installation path. 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. Best regards, Andreas Hindborg [1] https://wiki.qemu.org/Documentation/Networking [2] https://github.com/SamsungDS/vmctl [3] https://github.com/arighi/virtme-ng [4] https://github.com/metaspace/run-kernel