Re: [DNG] ..a viable basis for Devuan as a hypervisor?, was: libvirt package without X11 and DBus

2021-08-05 Thread Brad Campbell via Dng

On 6/8/21 1:04 am, AP wrote:



On 05.08.2021 12:37, Arnt Karlsen wrote:



..any of you guys wanting to package what you have running?
To me, this sounds like a viable basis for the bare metal
hypervisor idea in the "[DNG] Devuan as a hypervisor?" thread.


I like the idea of this, if the DEVUAN type1 hypervisor can be avaiable as iso 
- I would use it myself, especially in headless configuration - no X11, no 
DBus, no hot plug, no productivity tools in headless variant.
I could then maintain several pre-installed headless guests, e.g. with horde 
webmail, or letsencrypt ssl/postfix/ldap/dove/bind, web hosting, video/audio 
rtsp/hosting/transcoding, or anything else.

Do I understand correctly, that having configuration variant with QEMU /X11/vnc 
is required, since desktop guests configurations will be supported?


Why do you even need/want libvirt? I have several machines which run qemu 
guests just using simple bash scripts to bring them up (and all the bash script 
is there for is to hold the command line parameters). I like libvirt and 
virt-manager for configuring and customising the guests, but at the end of the 
day all that is is a fancy front end to qemu.

#!/bin/bash
PATH=$PATH:/home/brad/bin
qemu -enable-kvm\
 -m 4096\
 -vga std\
 -vnc :1\
 -no-hpet\
 -global VGA.vgamem_mb=32\
 -rtc base=localtime\
 -usbdevice tablet\
 -cpu host,kvm=off\
 -net tap,ifname=tap0,script=/home/brad/bin/wintap \
 -net nic,model=e1000,macaddr=52:54:00:12:34:58 \
 -device ahci,id=ahci_cont \
 -device ide-drive,bus=ahci_cont.0,drive=HDD \
 -drive id=HDD,if=none,file=Win8.Debugger.qcow2,format=qcow2\
 -device nec-usb-xhci,id=xhci\
 -readconfig /home/brad/qemu/docs/config/ich9-ehci-uhci.cfg \
 -serial tcp::9090,server,nowait \
 -cdrom /media/src/isos/GRMWDK_EN_7600_1.ISO \
 -device usb-host,bus=xhci.0,vendorid=0x0403,productid=0x6001 \
 -device usb-host,bus=xhci.0,vendorid=0x05ac,productid=0x1261 \
 -device usb-host,bus=xhci.0,vendorid=0x04d8,productid=0xe11c \
 -device usb-host,bus=xhci.0,vendorid=0x1a86,productid=0x7523 \

If you are stripping the guts out of libvirt, why use it in the first place?

Brad
--
An expert is a person who has found out by his own painful
experience all the mistakes that one can make in a very
narrow field. - Niels Bohr
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [DNG] grub-efi-amd64-signed bug: hardcoded link -> unbootable system

2021-08-05 Thread fsmithred via Dng
On 8/4/21 7:17 AM, Adrian Zaugg wrote:
> Dear list
> 
> Beowulf is hit hard by a problem with hardcoded path in grub-efi-amd64-signed 
> leading to an unbootable system as reported on this list and on dev1galaxy 
> (manual intervention in certain configurations needed to boot). This problem 
> also exists on fresh installs of beowulf, as it seems. Is there some effort 
> under way to fix the problem? 
> 
> Best regards, Adrian.
> 
> 
> Work-around (thanks to fsmithred):
> 
> # apt purge grub-efi-amd64-signed
> ...
> # apt install --reinstall grub-efi-amd64
> ...
> 

Which Beowulf iso did you use? I think we fixed this in the 3.1.1
point-release isos, but you still may hit it on an upgrade.

fsmithred



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [DNG] ..a viable basis for Devuan as a hypervisor?, was: libvirt package without X11 and DBus

2021-08-05 Thread AP



On 05.08.2021 12:37, Arnt Karlsen wrote:



..any of you guys wanting to package what you have running?
To me, this sounds like a viable basis for the bare metal
hypervisor idea in the "[DNG] Devuan as a hypervisor?" thread.

I like the idea of this, if the DEVUAN type1 hypervisor can be avaiable 
as iso - I would use it myself, especially in headless configuration - 
no X11, no DBus, no hot plug, no productivity tools in headless variant.
I could then maintain several pre-installed headless guests, e.g. with 
horde webmail, or letsencrypt ssl/postfix/ldap/dove/bind, web hosting, 
video/audio rtsp/hosting/transcoding, or anything else.


Do I understand correctly, that having configuration variant with QEMU 
/X11/vnc is required, since desktop guests configurations will be supported?


My setup is headless and lean, pretty plain. There are several things I 
do not have - network and cpu load balancing, cpu numa node affinity, 
back up tooling and strategy and apparmor + logging + safety/firewall. I 
believe that these things are essential part of a toolkit for bare metal 
hypervisor, plus administration scripts or webUI (nginx + lua?) + apt.


The only good thing I have is that my set up is running from packages 
out of box, which should be good for maintainers, i guess.


I more or less familiar with scripting for libvirt and back up, but no 
meta-scripting for installation, packaging and deploying. I can do lua, 
php, perl, nginx, apache, c, make, SQL, JS, HTML, etc.


Cheers,
Andrzej

--
AP

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [DNG] Devuan as a hypervisor?

2021-08-05 Thread Andrzej Peszynski


On 2021-08-02 11:16, hal wrote:
>

> I've been running KVM/QEMU/Virt-Manager on Devuan for many years with 
3-4 VMs and haven't had any issues directly related to Devuan. It's not 
my intent to bash systemd but it's worth mentioning that I've had many 
other issues with Debian based hypervisors over the past few years (50+ 
VMs across several hypervisors) that involve systemd when reviewing logs 
post-mortem. Hypervisors will sometimes not reboot. Even when trying to 
un-stick with Magic SysRq. The console will just show systemd errors 
instead. Likewise, when systems do reboot, sometimes they inexplicably 
stop booting and need to have the power button hit. Another time, 
OpenSSH would not work due to /var/run/sshd missing during boot. Another 
issue involved systemd and a LUKS encrypted partition. Another time was 
missing LVM devices. This happens across systems of varying age so 
hardware issues are kind of ruled out. The issues keep getting more 
frequent and odd as months go by. It's like these systems have regressed 
to what L

> inux was in 1995.
>
> I would strongly suggest running your virtualization on Devuan. The 
simplicity and stability is currently unmatched in my experience.

>

I would like to tell that in my experience the Debian KVM+QEMU+libvirt 
also started to suffer from some misbehaviour then I first time heard 
about systemd. I did not took a challenge and migrated to DEVUAN.


May be worth mentioning, that in my setup I use three virtual disks for 
one guest, which is not well supported by current apparmor 
configuration, so I took a shortcut: I switch the apparmour off 
(disable) during snapshots create/commit for back up script. Sure I 
better learn about the apparmor configuration, but not this time.


Cheers
Andrzej
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [DNG] ..a viable basis for Devuan as a hypervisor?, was: libvirt package without X11 and DBus

2021-08-05 Thread Brad Campbell via Dng
On 5/8/21 6:37 pm, Arnt Karlsen wrote:
> On Thu, 5 Aug 2021 11:13:06 +0800, Brad wrote in message 
> <184151f6-16e3-f59c-1d07-47394f30f...@fnarfbargle.com>:
> 
>> On 5/8/21 4:40 am, AP wrote:
>>> Hi everyone,
>>>
>>> first I thank all DEVUAN people for the pure pleasure of running my
>>> system (since ASCII 2018) without a bloatware.
>>>
>>> This is my first message and I am sorry, that my search did not
>>> give me the answer about:
>>>
>>> maintenance of the libvirt package without X11 and DBus
>>>
>>> Question: is there a way to get the package for libvirt + QEMU/KVM
>>> for headless VMs - when no X, no DBus needed? 
>>
>> You can always compile it yourself. I've just checked and I'm still
>> running a self-compiled v4 on my main box. Certainly in the v5.6.0
>> code I just looked at there's an option to disable dbus.
>>
>>  From memory I stopped upgrading when they migrated away from
>> autoconf and make. The redhat-isms were just making it too hard to
>> build on older stable debian-based systems, so I stuck with V4. These
>> days it'd be easy enough to use the packaged versions I suppose.
>>
>> Brad
> 
> ..any of you guys wanting to package what you have running?
> To me, this sounds like a viable basis for the bare metal 
> hypervisor idea in the "[DNG] Devuan as a hypervisor?" thread.
> 

Nope. I did it because I needed to if I wanted the bits "I needed" from libvirt 
on a Debian version that was pre-jessie.
I still built with dbus, I just had to also build the right version of dbus.

If I was starting from scratch now, I'd install Devuan Beowulf and apt-get 
install libvirt. I don't get hung up on dependencies and I'm too lazy to want 
to expunge dbus just because I don't understand it and I'm paranoid (I do and 
I'm not). I'm still running my self-compiled libvirt because I've progressively 
upgraded from Debian Wheezy (which is what I compiled it on) to Devuan 
Jessie->Ascii->Beowulf and it hasn't broken. Because it hasn't broken, I 
haven't fixed it. It still lives (with all its dependencies) in 
/usr/local/libvirt.

Brad
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


[DNG] ..another viable basis idea for Devuan as a hypervisor?, was: Announce: FlyingTux project

2021-08-05 Thread Arnt Karlsen
On Fri, 30 Jul 2021 14:49:32 +0200, metux IT consult wrote in message 
:

> Hello folks,
> 
> 
> maybe a bit offtopic, 

..I disagree. ;o)

> but allow me to announce the FlyingTux project:

..welcome onboard DNG. :o)

> It's an build/runtime infrastructure for running desktop and mobile
> applications in containers and build an entirely container-based
> mobile OS based on it.

..I like the https://www.qubes-os.org/ approach, but not 
their use of systemd nor of rpm.  
Do we do something similar here?

> The primary motivation is my long frustration about the monstreaus and
> practically unmaintainable Android, which also still lacks lots of
> common management abilities we know from the GNU/Linux world.

.."wonder why Google designed it that way." ;oD

> In some ways, FT can be seen as an conceptional combination of
> containers (docker, k8s, etc) and apps (android, etc). One major
> difference is that also the app images are based on some defined
> distro base (for start, just alpine, others to follow later) and the
> images are created on the host, based on host specific settings like
> hw setups (eg. automatically deploys the right mesa drivers). In
> future steps some packages of the app distro base (called 'osbase#
> here) will be replaced or customized, in order to provide better
> integration with the ecosystem and strip unneeded stuff.

..which means an early step will be trim down the basic (net-install?)
images we have, as far down as possible, and build app, vm etc images 
upon those stripped down base images.  
I guess we also want a bare bare metal hypervisor of some sort. ;o)

> Another key difference is moving common functionality (eg. various
> data sources, communication protocols, ...) out of the individual
> apps into generic services - and the binding between individual apps
> and actual services instances can be customized by the user (e.g. one
> can bind some apps to fake gps instead of the real one, separate
> address books or user directories, etc, etc).
> 
> Here's a more detailed description:
> 
> https://github.com/metux/flyingtux/blob/master/README

..this means we can set up e.g. chromium in throw-away-after-use
containers?  Or stick new stuff with lib conflicts in containers?
Etc? 

> Note that for now its very experimental and fast changing. Don't
> expect anything field-ready yet. But it's already good enought to
> isolate some common desktop apps like gimp, chrome, etc.

..I see no .deb package?  Pretty soon we'll need debug packages 
to shake out bugs.

-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


[DNG] ..a viable basis for Devuan as a hypervisor?, was: libvirt package without X11 and DBus

2021-08-05 Thread Arnt Karlsen
On Thu, 5 Aug 2021 11:13:06 +0800, Brad wrote in message 
<184151f6-16e3-f59c-1d07-47394f30f...@fnarfbargle.com>:

> On 5/8/21 4:40 am, AP wrote:
> > Hi everyone,
> > 
> > first I thank all DEVUAN people for the pure pleasure of running my
> > system (since ASCII 2018) without a bloatware.
> > 
> > This is my first message and I am sorry, that my search did not
> > give me the answer about:
> > 
> > maintenance of the libvirt package without X11 and DBus
> > 
> > Question: is there a way to get the package for libvirt + QEMU/KVM
> > for headless VMs - when no X, no DBus needed? 
> 
> You can always compile it yourself. I've just checked and I'm still
> running a self-compiled v4 on my main box. Certainly in the v5.6.0
> code I just looked at there's an option to disable dbus.
> 
>  From memory I stopped upgrading when they migrated away from
> autoconf and make. The redhat-isms were just making it too hard to
> build on older stable debian-based systems, so I stuck with V4. These
> days it'd be easy enough to use the packaged versions I suppose.
> 
> Brad

..any of you guys wanting to package what you have running?
To me, this sounds like a viable basis for the bare metal 
hypervisor idea in the "[DNG] Devuan as a hypervisor?" thread.

-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng