Re: Status of NetBSD virtualization roadmap - support jails like features?
Hi Greg, Am 15.04.2022 um 14:24 schrieb Greg Troxel: However, this week I read a post on Reddit[2] that was a bit disturbing to me. Meaningfully, it proclaims that the main development platform for nvmm is now DragonflyBSD rather than NetBSD. It also claims that the implementation in NetBSD is now "stale and broken". Comparing the timestamps of the last commits in the repositories [3] and [4], the last activities are only three months apart. The nature and extent of the respective changes is difficult for me to evaluate. Is anyone here deeper into this and can say what the general state of nvmm in NetBSD is? 1) nvmm seems to work well in netbsd (I haven't run it yet) and there has been bug fixing. 2) code flows between BSDs a lot, in many directions. 3) You could run diff to see what's different and why. 4) The language in the reddit post does not sound particularly constructive. Someone with knowledge of improved code in DragonFly (I don't know if that's true or not) could send a message here or teech-kern pointing it out and suggesting we update, rather than being dismissive on reddit. Or file PRs and list them; technical criticism is fair. Probably after your message (which I view as helpful) someone(tm) will look at the diff. But if you are inclined to do that and post some comments, that's probably useful. Thank you very much for your points. I will indeed do the diff asap out of interest, although I can't promise that anything can be derived from it - I'm not a kernel developer, let alone know anything about virtualization beyond the administrator level ;-) But from a roadmap point of view, I see it as a good sign that nvmm gets bug fixes and is described quite comprehensively in the NetBSD guide. Many greetings Matthias
daily CVS update output
Updating src tree: P src/crypto/external/bsd/openssh/dist/PROTOCOL P src/crypto/external/bsd/openssh/dist/auth-rhosts.c P src/crypto/external/bsd/openssh/dist/auth2-pubkey.c P src/crypto/external/bsd/openssh/dist/channels.c P src/crypto/external/bsd/openssh/dist/channels.h P src/crypto/external/bsd/openssh/dist/misc.c P src/crypto/external/bsd/openssh/dist/monitor.c P src/crypto/external/bsd/openssh/dist/myproposal.h P src/crypto/external/bsd/openssh/dist/scp.1 P src/crypto/external/bsd/openssh/dist/scp.c P src/crypto/external/bsd/openssh/dist/servconf.c P src/crypto/external/bsd/openssh/dist/servconf.h P src/crypto/external/bsd/openssh/dist/sftp-client.c P src/crypto/external/bsd/openssh/dist/sftp-client.h P src/crypto/external/bsd/openssh/dist/sftp-glob.c P src/crypto/external/bsd/openssh/dist/sftp-server.c P src/crypto/external/bsd/openssh/dist/sftp.1 P src/crypto/external/bsd/openssh/dist/sftp.c P src/crypto/external/bsd/openssh/dist/ssh-agent.1 P src/crypto/external/bsd/openssh/dist/ssh-keygen.c P src/crypto/external/bsd/openssh/dist/ssh-keysign.8 P src/crypto/external/bsd/openssh/dist/ssh.1 P src/crypto/external/bsd/openssh/dist/ssh.c P src/crypto/external/bsd/openssh/dist/ssh_config.5 P src/crypto/external/bsd/openssh/dist/sshd.8 P src/crypto/external/bsd/openssh/dist/sshd.c P src/crypto/external/bsd/openssh/dist/sshd_config.5 P src/crypto/external/bsd/openssh/dist/sshsig.c P src/crypto/external/bsd/openssh/dist/version.h P src/crypto/external/bsd/openssh/dist/xmalloc.c P src/crypto/external/bsd/openssh/lib/shlib_version P src/crypto/external/bsd/openssl/lib/libcrypto/Makefile P src/distrib/sets/lists/base/shl.mi P src/distrib/sets/lists/debug/shl.mi P src/doc/3RDPARTY P src/doc/CHANGES P src/share/man/man5/boot.cfg.5 P src/sys/arch/x86/isa/isa_machdep.c P src/tests/usr.bin/xlint/lint1/d_constant_conv2.c U src/tests/usr.bin/xlint/lint1/d_constant_conv2.exp P src/tests/usr.bin/xlint/lint1/d_type_conv1.c U src/tests/usr.bin/xlint/lint1/d_type_conv1.exp P src/tests/usr.bin/xlint/lint1/d_type_conv2.c U src/tests/usr.bin/xlint/lint1/d_type_conv2.exp P src/tests/usr.bin/xlint/lint1/d_type_conv3.c U src/tests/usr.bin/xlint/lint1/d_type_conv3.exp P src/tests/usr.bin/xlint/lint1/expr_fold.c P src/tests/usr.bin/xlint/lint1/expr_fold.exp P src/tests/usr.bin/xlint/lint1/msg_259.c P src/tests/usr.bin/xlint/lint1/msg_259_ilp32.c P src/usr.bin/make/Makefile.boot P src/usr.bin/make/cond.c P src/usr.bin/make/meta.c P src/usr.bin/make/targ.c P src/usr.bin/make/unit-tests/check-expect.lua P src/usr.bin/make/unit-tests/deptgt-silent-jobs.mk P src/usr.bin/make/unit-tests/opt-debug-cond.mk P src/usr.bin/make/unit-tests/varname-dot-suffixes.mk P src/usr.bin/xlint/lint1/tree.c P src/usr.bin/xlint/xlint/lint.1 P src/usr.bin/xlint/xlint/xlint.c Updating xsrc tree: Killing core files: Updating tar files: src/top-level: collecting... replacing... done src/bin: collecting... replacing... done src/common: collecting... replacing... done src/compat: collecting... replacing... done src/crypto: collecting... replacing... done src/dist: collecting... replacing... done src/distrib: collecting... replacing... done src/doc: collecting... replacing... done src/etc: collecting... replacing... done src/external: collecting... replacing... done src/extsrc: collecting... replacing... done src/games: collecting... replacing... done src/include: collecting... replacing... done src/lib: collecting... replacing... done src/libexec: collecting... replacing... done src/regress: collecting... replacing... done src/rescue: collecting... replacing... done src/sbin: collecting... replacing... done src/share: collecting... replacing... done src/sys: collecting... replacing... done src/tests: collecting... replacing... done src/tools: collecting... replacing... done src/usr.bin: collecting... replacing... done src/usr.sbin: collecting... replacing... done src/config: collecting... replacing... done src: collecting... replacing... done xsrc/top-level: collecting... replacing... done xsrc/external: collecting... replacing... done xsrc/local: collecting... replacing... done xsrc: collecting... replacing... done Updating release-8 src tree (netbsd-8): Updating release-8 xsrc tree (netbsd-8): Updating release-8 tar files: src/top-level: collecting... replacing... done src/bin: collecting... replacing... done src/common: collecting... replacing... done src/compat: collecting... replacing... done src/crypto: collecting... replacing... done src/dist: collecting... replacing... done src/distrib: collecting... replacing... done src/doc: collecting... replacing... done src/etc: collecting... replacing... done src/external: collecting... replacing... done src/extsrc: collecting... replacing... done src/games: collecting... replacing... done src/include: collecting... replacing... done src/lib: collecting... replacing... done src/libexec: collecting... replacing... done src/regress: collecting... replacing... done src/rescue: collecting...
Re: Status of NetBSD virtualization roadmap - support jails like features?
On Fri, Apr 15, 2022 at 07:36:15AM +0200, Matthias Petermann wrote: > However, this week I read a post on Reddit[2] that was a bit disturbing to > me. Meaningfully, it proclaims that the main development platform for nvmm > is now DragonflyBSD rather than NetBSD. It also claims that the > implementation in NetBSD is now "stale and broken". As you can find in the comments on the Reddit post, what actually happened is that a certain person left here in a huff. > Regardless, I still think it wouldn't hurt if NetBSD could implement some > sort of jail. In general I agree, but it's not clear what and how much, and really the first thing that needs to be done is a general reform of kauth and that obstructs everything else :-| -- David A. Holland dholl...@netbsd.org
Re: error upgrading packages on current / pkg database
On Fri, Apr 15, 2022 at 01:42:55PM -0400, Greg Troxel wrote: > That can work too, but either way all the cross-package data linkage may > not be quite right. ...at which point which you do "pkg-admin rebuild-tree" :-) -- David A. Holland dholl...@netbsd.org
Re: Status of NetBSD virtualization roadmap - support jails like features?
At Fri, 15 Apr 2022 07:36:15 +0200, Matthias Petermann wrote: Subject: Status of NetBSD virtualization roadmap - support jails like features? > > My motivation: I am looking for a particularly high performance > virtualization solution on NetBSD. Especially disk and network IO > plays a role for me. In my experience nothing beats I/O performance of Xen with LVM in the dom0 and the best/fastest storage available for the dom0, especially now there's SMP support for dom0. That's anecdotal though -- I haven't done any real comparisons. I just know that NFS in domUs is a lot slower than using LVMs via xbd(4), no matter where/how-fast the NFS server is! If I'm not too far out of touch I think there's still a wee bit more SMP support needed in the networking code to make it possible for dom0 to also give the best network throughput, but it's really not horrible as-is. In theory NVMM with QEMU and virtio(4) should be about the same I would guess, with potential for some improvement in some micro-benchmarks, but for production use the maturity and completeness of the provisioning support offered by Xen still seems far superior to me. > Regardless, I still think it wouldn't hurt > if NetBSD could implement some sort of > jail. I'm not convinced "jails" (at least in the FreeBSD form I'm most familiar with) actually buy much without also increasing complexity and/or introducing limitations on both the provisioning and the "virtual" side. With a full virtualisation as in Xen the added complexity is very well partitioned between the provisioning side and the VMs, and there are almost no limitations inside the VMs (assuming you are virtualising something that fits well into a virtualised environment, i.e. with no special direct hardware access needs) -- everything looks and feels and is managed almost as if it is running on bare hardware and so the management of the VM is exactly as if it were running on separate hardware; except of course some aspects are actually easier to manage, such as provisioning direct console access and control. There's really nothing new to learn other than how to spin up a new domU (and possibly how to use LVM effectively). However FreeBSD-style jails do offer their own form of flexibility that seems to be worth having available, and it would be nice for jails to be available on NetBSD as well. The impact inside the OS (kernel and userland) is quite high though, and is itself a form of complexity nightmare all its own, though perhaps not so horrible as Linux "cgroups" and some other related Linux kernel namespaces are. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms pgpX4KZZetx9T.pgp Description: OpenPGP Digital Signature
Re: error upgrading packages on current / pkg database
Mike Pumford writes: > On 15/04/2022 17:19, Riccardo Mottola wrote: >> Hello, >> >> I did a full system upgrade (running now ) and then got current pkgsrc. >> >> Now I try to run pkg_rolling-replace -uv ; it compiled for days, then stops. >> >> disc# pkg_admin check >> ...pkg_admin: can't open >> /usr/pkg/pkgdb/glib2-2.70.2nb1/+CONTENTS: No such file or directory >> > Hmm. Thats interesting. I've seen that happen on one of my 9.2-STABLE > systems when doing a pkgin upgrade. Although in my case it was librsvg > that got clobbered. > > Instead of the correct pkgdb data the folder existed but contained a > random core file. The core file wasn't from any pkg tool. > I ended up with: > /usr/pkg/pkgdb/librsvg-2.52.6/gdk-pixbuf-query.core > > Which isn't even a tool I use its just something pulled in as a > dependendency. Interesting data point. I should have said as 2A: when you find a directory with broken contents, just rm -rf it, and that will get rid of the record of installation without removing the files. Then "pkg_add glib2" and perhaps "pkg_admin set automatic=yes glib2" if you want it that way, and then rerun check and rebuild-tree > you have it around so you can extract them into the folder and then > use pkg_admin to put things back together. That's what I did to sort > myself out :) > > Something like: > > tar zxf glib-2.70.2nb1.tgz +* That can work too, but either way all the cross-package data linkage may not be quite rie ght. signature.asc Description: PGP signature
Re: error upgrading packages on current / pkg database
On 15/04/2022 17:19, Riccardo Mottola wrote: Hello, I did a full system upgrade (running now ) and then got current pkgsrc. Now I try to run pkg_rolling-replace -uv ; it compiled for days, then stops. disc# pkg_admin check ...pkg_admin: can't open /usr/pkg/pkgdb/glib2-2.70.2nb1/+CONTENTS: No such file or directory Hmm. Thats interesting. I've seen that happen on one of my 9.2-STABLE systems when doing a pkgin upgrade. Although in my case it was librsvg that got clobbered. Instead of the correct pkgdb data the folder existed but contained a random core file. The core file wasn't from any pkg tool. I ended up with: /usr/pkg/pkgdb/librsvg-2.52.6/gdk-pixbuf-query.core Which isn't even a tool I use its just something pulled in as a dependendency. disc# pkg_admin rebuild pkg_admin: glib2-2.70.2nb1: can't open `+CONTENTS' disc# pkg_admin rebuild-tree pkg_admin: Cannot read +CONTENTS of package glib2-2.70.2nb1 I don't know what else to try to fix. The files in that folder are container within the pkg .tar.gz file if you have it around so you can extract them into the folder and then use pkg_admin to put things back together. That's what I did to sort myself out :) Something like: tar zxf glib-2.70.2nb1.tgz +* Mike
Re: error upgrading packages on current / pkg database
Riccardo Mottola writes: > disc# pkg_admin check > ...pkg_admin: can't open > /usr/pkg/pkgdb/glib2-2.70.2nb1/+CONTENTS: No such file or directory > > disc# pkg_admin rebuild > pkg_admin: glib2-2.70.2nb1: can't open `+CONTENTS' > > disc# pkg_admin rebuild-tree > pkg_admin: Cannot read +CONTENTS of package glib2-2.70.2nb1 1) Understand how pkgdb works cd /usr/pkg/pkgdb look around at the contents 2) look at glib2 specifically ls -ld glib2-* for d in glib2-*; do echo DIR $d ls -l $d done 3) Figure out how to write 'pkg_admin fsck' which will detect/fix automatically signature.asc Description: PGP signature
error upgrading packages on current / pkg database
Hello, I did a full system upgrade (running now ) and then got current pkgsrc. Now I try to run pkg_rolling-replace -uv ; it compiled for days, then stops. disc# pkg_admin check ...pkg_admin: can't open /usr/pkg/pkgdb/glib2-2.70.2nb1/+CONTENTS: No such file or directory disc# pkg_admin rebuild pkg_admin: glib2-2.70.2nb1: can't open `+CONTENTS' disc# pkg_admin rebuild-tree pkg_admin: Cannot read +CONTENTS of package glib2-2.70.2nb1 I don't know what else to try to fix. Riccardo
Re: Status of NetBSD virtualization roadmap - support jails like features?
However, this week I read a post on Reddit[2] that was a bit disturbing to me. Meaningfully, it proclaims that the main development platform for nvmm is now DragonflyBSD rather than NetBSD. It also claims that the implementation in NetBSD is now "stale and broken". Comparing the timestamps of the last commits in the repositories [3] and [4], the last activities are only three months apart. The nature and extent of the respective changes is difficult for me to evaluate. Is anyone here deeper into this and can say what the general state of nvmm in NetBSD is? 1) nvmm seems to work well in netbsd (I haven't run it yet) and there has been bug fixing. 2) code flows between BSDs a lot, in many directions. 3) You could run diff to see what's different and why. 4) The language in the reddit post does not sound particularly constructive. Someone with knowledge of improved code in DragonFly (I don't know if that's true or not) could send a message here or teech-kern pointing it out and suggesting we update, rather than being dismissive on reddit. Or file PRs and list them; technical criticism is fair. Probably after your message (which I view as helpful) someone(tm) will look at the diff. But if you are inclined to do that and post some comments, that's probably useful. signature.asc Description: PGP signature
