From: Andreas Hindborg <nmi@metaspace.dk>
To: Luis Chamberlain <mcgrof@kernel.org>
Cc: Chuck Lever <chuck.lever@oracle.com>, kdevops@lists.linux.dev
Subject: Re: guestfs storage paths are confusing
Date: Wed, 23 Apr 2025 08:22:50 +0000 [thread overview]
Message-ID: <8734dznv6z.fsf@metaspace.dk> (raw)
In-Reply-To: <aAiC4-x80f3GCD-0@bombadil.infradead.org>
"Luis Chamberlain" <mcgrof@kernel.org> writes:
> On Thu, Apr 10, 2025 at 04:58:59AM +0000, Andreas Hindborg wrote:
>> "Luis Chamberlain" <mcgrof@kernel.org> 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].
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
next prev parent reply other threads:[~2025-04-23 8:22 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-08 19:17 guestfs storage paths are confusing Chuck Lever
2025-04-08 19:29 ` Luis Chamberlain
2025-04-09 14:55 ` Chuck Lever
2025-04-09 18:10 ` Luis Chamberlain
2025-04-09 18:36 ` Chuck Lever
2025-04-09 23:46 ` Luis Chamberlain
2025-04-10 4:58 ` Andreas Hindborg
2025-04-23 6:04 ` Luis Chamberlain
2025-04-23 8:22 ` Andreas Hindborg [this message]
2025-04-23 20:53 ` Luis Chamberlain
2025-04-25 7:30 ` Andreas Hindborg
2025-04-25 21:31 ` Luis Chamberlain
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8734dznv6z.fsf@metaspace.dk \
--to=nmi@metaspace.dk \
--cc=chuck.lever@oracle.com \
--cc=kdevops@lists.linux.dev \
--cc=mcgrof@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox