KDE, Pulseaudio and Browsers – make the LADSPA equalizer the default sink

During these days of Covid-19, home-office and lock-downs browsers and other Internet streaming tools as VLC become important personal gates to the world. When streaming videos or songs a user, of course, wants to hear some sound. No problem with Linux - Alsa helped you already decades ago. But things used to become a bit complicated if you wanted to direct the output of multiple sound-sources through a global equalizer of your Linux desktop environment (in my case preferably KDE). An equalizer may help to compensate deficits of cheap speakers or hearing problems of elderly persons as me. Well, if you found a global desktop equalizer at all. With KDE, no chance - it always was a strange policy of the KDE-people to assume that an equalizer is none of their responsibilities. So, a standard Linux user depended on application specific equalizers - which at least many Linux sound and video players offered. But what about browsers?

This is, where "Pulseaudio" and the related "Ladspa" based equalizer really were of help to a common user. As a matter of fact, I have never been a real friend of "Pulseaudio" [PA]; you can find some critical posts regarding PA in this blog. However, I gladly admit that Pulseaudio and its control interfaces have become substantially better with the years. At some point in the past PA started to work reasonably well even with multi-channel soundcards. It is now also much better integrated with KDE's "Phonon" system than some years ago. Today, you can define e.g. a central volume control without destroying the relative volume ratios of different output channels of a sound card. And: We have a well integrated equalizer as a desktop-wide, global tool to improve the sound quality. So, why a post about it?

A problem with (automatically) changing streams and an assignment to a default sink

A problem with KDE and Pulseaudio in the past was the following: Only some applications (as e.g. "Clementine) " gave/give the user a chance to specify a sink of the sound environment to which the sound output of the application is transferred for further processing.

A sound sink is a kind of sound module which accepts a sound stream as input, processes it and may send an output to other processing modules or an amplifier. On KDE you may find some available sinks for your sound card or cards under "system-settings >> Multimedia". An important sink in our present context is the PA equalizer. See https://doc.qt.io/archives/qt-4.8/phonon-overview.html for the inclusion of media objects and sinks into a sound flow model ("graphs") for KDE.

However, a lot of applications as e.g. browsers do not offer any settings to modify the primary sound sink. Instead they address a "default sink" of the system. What the "default sink" was, was either non-transparent to the user, or some related settings within your KDE desktop were just ignored, or you had to dive deep into the unhandy Alsa and the PA-configuration options. This led to major inconveniences for normal users:

When a new sound stream was activated a default sound sink was chosen by many applications which often did not correspond to the preferred one - namely the equalizer.

This problem could only partially be overcome by using "pavucontrol", a PA-tool to control volume settings on channels and sinks in the system. "pavucontrol"actually allowed and allows the user to assign sinks to running applications and their sound streams. However, when the application switched from one stream to another - e.g. automatically in a media-player with a list of songs or on the web (youtube changing videos) - then the newly selected stream fell back to the default sink. Driving the user nuts ....

Setting of the default sink for the KDE desktop

I use Opensuse Leap 15.1/2 with KDE as my main working environment (besides Debian and Kali with Gnome 🙂 ). By chance I recently found something which did not work for me in previous installations. In KDE we have a specific sound system - "Phonon" - which allows the user to organize the priority of "devices" (sinks) for certain kinds of applications. In my case you see the settings for "music" applications:

You see that I have 2 sound cards available - but to make things simpler I deactivated one of them for this blog post. The first device listed is the PA's LADSPA equalizer:

It got the highest priority for music streams - more precisely for applications which follow the Qt/Phonon-API-rules when playing music streams. But, what about browsers (FF, Chromium, Opera, ...), what about applications designed for Gnome and GTK3? You often can direct them to use PA, but what does PA respect as a default sink in a KDE environment with Phonon?

Well the simple "trick" which I found working recently is to set the priorities for all audio in KDE's Phonon-settings:

Then we get the following PA-settings (install and start the pulseaudio-manager application "paman"):

This is what we need! And this setting is (now) respected by browsers and other applications that seek a default sink.

So: KDE, Pulseaudio and Phonon settings actually give a common KDE user the chance to direct all sound through the Ladspa equalizer as a default sink.

If your media-player offers its own equalizer you can of course combine both equalizers.

By the way: Common volume control

In the above picture on Phonon settings the sink "Simultaneous output to ..." directs multiple sound sources to one or multiple sound devices. As we direct all sound through the equalizer first, we give the "Simultaneous output ..."-device second priority.

We can use it for a common volume control in KDE's Kmix: If you right-click on the Kmix symbol or open it you get an option to choose the main output channel :

Now, this setting assigns the desktop's global volume control to this sink - which leaves all other volume settings, e.g. for the relative volumes of the sound-card channels, untouched:

You may find that this settings is transported to the sound control keys of a keyboard with a media control bar (e.g. on a Cherry keyboard).

Conclusion

With the help of KDE's system-settings and Pulseaudio we can direct the output of all audio applications through a desktop wide equalizer, which we define by Phonon settings as a default sink. This is simply done by giving PA's LADSPA equalizer the highest priority for all audio. You do not need to dive into PA configuration depths or the command line for changing PA's device and sink graphs for sound flows.
The "Simultaneous output ...." device (or sink) allows for a global volume control which respects other volume settings controlled e.g. via PA's "pavucontrol".

Linux SSD partition alignment – problems with external USB-to-SATA controllers – I

When you try to find a solution for one problem suddenly another problem appears - and you find yourself confronted with something you never worried about before. For my article series on full laptop encryption with Opensuse Leap 15 I wanted to prepare a new SSD on my Linux desktop. This SSD should later on become the main disk of the laptop. I used an external disk box with an USB-to-SATA-controller from JMicron to attach the disk to the USB-3 bus of my desktop system. And stumbled across a really strange partitioning scheme YaST's "partitioner" set up on my SSD during installation.

For a SSD you normally expect Linux to choose a so called "1 MiB-alignment". Among other things this alignment leads to a minimum offset of the first partition of 2048 logical sectors/blocks with 512 byte. The math is 2048 * 512 = 1024 * 1024 = 1 (MiB) = 256 * 4096. This sector start address is well suited for so called AF disks with native 4k support, but also for disks with conventional 512 byte physical blocks. Note that 1024 * 1024 can be divided by both 512 and 4096 without remainder.

From previous experience with SSDs attached to SATA-III controllers on a Linux system I would have said: Any partition on a SSD shows a logical start block number which is a multiple of 2048 on a Linux system. And I would have bet that this were true for the size of a partition number expressed in block numbers, too. I had never questioned this before ... In addition there are many articles on the Internet that tell users not to worry about alignment because all Linux tools today handle alignment correctly.

However, in my test situation I got something very different - and consequently some (!) Linux partitioning tools on the laptop later complained about misalignment. This worried me. Googling lead me to the following unanswered question at
https://superuser.com/questions/1291467/trouble-figuring-out-optimal-alignment-of-multiple-partitions-on-a-931-5-gib-ext,
which describes more or less my problem.

I have tried to figure out what was/is behind these "misalignment" problem - and the result shocked me a bit. It triggers questions about manufacturers of disk controllers and the way Linux handles disk property information. In addition I had a brief look at performance for an aligned and an unaligned partition. The results again puzzled me. I find it difficult to get a consistent picture out of my findings for partition alignment on SSDs at different controllers. Write me a mail if you know better ...

Anyway, I hope this article, which digs into areas of Linux which are a bit offside standard usage, finds the interest of some other Linux fans, too ....

I shall use the words "blocks" (OS perspective) and "sectors" (atomic disk unit) on the level of partitioning interchangeably - which is not quite correct semantically. But you find this mix of wording also in disk tools :-).

The problem

I used an external box for my SSD which contained a JMicron USB-to-SATA controller. When my SSD - a Samsung 850 Pro - was attached to my Linux desktop via an external USB interface, the physical sector size was reported to be 4096 bytes by lsblk, by parted and fdisk. This stood a bit in contrast to other reports for this SSD type on the Internet; but SSD technology changes so often; I did not make me suspicious. I added a BIOS boot partition and several other partitions to the disk first with YaST's Partitioner. The start sector of the first partition was chosen by YaST to be 65535.

mytux:~ # fdisk -l /dev/sdh 
Disk /dev/sdh: 477 GiB, 512110190592 bytes, 1000215216 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 33553920 bytes
Disklabel type: gpt
Disk identifier: ....

Device         Start       End   Sectors  Size Type
/dev/sdh1      65535    131069     65535   32M BIOS boot
/dev/sdh2     131070   1376234   1245165  608M EFI System
/dev/sdh3    1376235  37027274  35651040  17GM Linux swap
...

OK, I had noticed before that some present partitioning tools choose a 32 MiB offset for the first partition these days. However, the number 65535 is NOT a multiple of 2048 and thus gives 31,99951171875 MiB. An offset of 65536 logical blocks would, however, fit exactly to 32 MiB.
Also all other partitions on the external SSD were "aligned" (?) to start sector numbers which were multiples of 65535.
Addendum 05.12.2018: I retested this with the tool parted - without defining a special alignment type, i.e. using defaults. Same result.

65535 is compatible with a physical block size of 512 bytes, but NOT 4096 bytes. Interestingly, 65535 also fits an erase block size of 1536 MiB, which a lot of people assume to be used by Samsung for its SSDs. Wherever these people got this information from ... see e.g. https://www.phoronix.com/forums/forum/hardware/general-hardware/1030306-samsung-970-evo-nvme-ssd-benchmarks-on-ubuntu-linux.

But: I checked against partition boundaries on another Linux system with the same type of SSD directly attached to the internal (Intel) SATA controller. There the alignment fitted exactly the theory of boundaries as multiples of 1 MiB (=> multiples of 2048 logical blocks as start sector numbers). I also checked for systems with other internal SSDs. 1 MiB alignment ...

Then I built the disk into my laptop and attached it directly to the SATA interface there - and got a plain "1 MiB"-alignment (both for YaST's Partitioner and parted with defaults).

mylux:~ # fdisk -l /dev/sda 
Disk /dev/sda: 477 GiB, 512110190592 bytes, 1000215216 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: ....

Device         Start       End   Sectors  Size Type
/dev/sda1      2048      67583     65536   32M BIOS boot
...

If one had added more partitions the pattern would have repeated itself: With the SSD on the SATA controller the start sector numbers became multiples of 2048; on the external JMicron USB-to-Sata-controller bus the start sector numbers became multiples of 65535.

Where did this discrepancy come from?

Weiterlesen

Mounten eines vmdk-Laufwerks im Linux Host – III – qemu-nbd, loop-devices, kpartx

In dieser Artikelserie beschäftigen wir uns damit, wie man von einer Linux-Umgebung aus direkt auf Partitionen von vmdk-Disk-Images zugreifen kann. In den letzten beiden Artikeln

Mounten eines vmdk Laufwerks im Linux Host – I – vmware-mount
Mounten eines vmdk-Laufwerks im Linux Host – II – Einschub, Spezifikation, Begriffe

hatten wir zunächst das Kommando "vmware-mount" betrachtet. "vmware-mount" kann Partitionen in Snapshots eines "sparse and growing vmdk-Images" direkt auf Zielverzeichnisse eines Linux-Baums mounten. Wir hatten dabei gesehen, dass zwischenzeitlich ein sog. "flat"-File angelegt wird. Die Rechtesetzung beim Mounten hatte uns noch nicht besonders gefallen. Da vmdk-Format unterschiedliche und komplexe Varianten von bedarfsgerecht wachsenden Images und Snapshots erlaubt, hatten wir im zweiten Artikel ein paar Seitenblicke auf die Spezifikation geworfen, um die Vielzahl von vmdk-Dateien zu einem Disk-Image und die zugehörige Nomenklatur besser zu verstehen. Nun wollen wir ein erstes natives Linux-Tools betrachten.

Da "vmdk" mit Virtualisierung zu tun hat, ist es kein Wunder, dass die beste Unterstützung für dieses Format unter Linux aus dem QEMU-Bereich - und damit von Red Hat und aufgekauften Firmen - kommt. Eines der Tools, auf die dabei inzwischen Verlass ist, gibt es schon sehr lange (seit etwa 2010): qemu-nbd.

nbd steht dabei für Network Block Device; Ziel des nbd-Toolsets war es, virtuelle Speichermedien auch über Server - also über Netz - für qemu-basierte virtuelle Maschinen auf Client-Systemen (z.B. Linux-Workstations) bereitzustellen. Schön beschrieben sind die Grundlagen aus den Anfangszeiten etwa hier :
Qemu-Buch zu Network Block Devices
https://de.wikipedia.org/wiki/Network_Block_Device

nbd kann aber natürlich auch lokal - also auf der eigenen Linux-Workstation - zur Erstellung eines Block-Devices auf Basis eines vmdk-Disk-Images eingesetzt werden. Das Kernelmodul "nbd" und das zugehörige CLI-Kommando "qemu-nbd" erweisen sich dabei als fähig, auch Snapshots des neuesten vmdk-Formats in der Version 6 richtig zu verarbeiten. Für die weitere Verwertung unter Linux werden - bei richtiger Parametrierung - ein oder mehrere ein Block-Devices erzeugt, die wir z.T. direkt mounten können.

Sicherheit und das direkte Mounten von virtuellen Disks/Filesystemen auf Linux-Hosts

Vorab ein paar mahnende Worte: vmdk, qcow2, etc. sind für virtuelle Maschinen gedacht. Gerade bei virtualisierten Windows-Maschinen, aber auch sonst, sollte man vorsichtig sein, wenn man nicht genau weiß, in welchem Zustand sich die Filesysteme des Images befinden. Ein manipuliertes Filesystem und/oder mit Malware behafteter Inhalt kann nach einem Mounten auch auf einem Linux-Host erheblichen Schaden anrichten. Leute, die etwas anderes glauben, erliegen einer Illusion.

Ich plädiere deshalb dafür, Experimente oder auch forensische Aktivitäten mit Partitionen aus vmdk-Images immer in einem virtuellen KVM-Linux-Gastsystem eines KVM-Hostes auszuführen. Das Gastsystem kann man hinreichend gut vom eigentlichen Virtualisierungs-Host isolieren. Die Performance ist auf aktuellen und SSD-basierten Systemen hinreichend gut, um auch mit großen vmdk-Images bequem hantieren zu können.

Wenn ich nachfolgend vom "Host" spreche, meine ich also immer das Linux-System, auf dem man mit dem vmdk-Image "forensisch" operiert - und nicht die virtuelle Maschine, die das Image normalerweise direkt nutzt und auch nicht den Virtualisierungshost. Ich meine vielmehr einen speziellen KVM-Linux-Gast, von dem aus man auf das Image zugreift. Die zu untersuchenden vmdk-Dateien kann man auf einem solchen Gast z.B. über SSHFS bereitstellen - oder sie bei hinreichendem Platz einfach per scp in das Gast-Filesystem hineinkopieren.

Man lese zu den Gefahren etwa:
A reminder why you should never mount guest disk images on the host OS von D.P. Berrange

Zudem gilt immer:
Mehrfache Mounts mit ggf. konkurrierenden schreibenden Zugriffen sind unbedingt zu vermeiden! Operiert man mit dem Image entgegen meinem Ratschlag direkt auf dem Virtualisierungshost, so muss das virtualisierte Gastsystem, das das Image normalerweise nutzt, abgeschaltet sein. Oder: Man mountet zur Sicherheit in einem "read only"-Modus.

Notwendige Pakete für qemu-nbd

Wer sich unter Linux - in meinem Fall Opensuse Leap - mit qemu und KVM auseinandersetzt, hat die notwendigen Pakete mit ziemlicher Sicherheit bereits installiert. Erforderlich ist das Paket "qemu-tools" (unter Debian-Derivaten "qemu-utils"). Abhängigkeiten werden durch YaST (oder apt-get) aufgelöst. Unter Opensuse Leap ist das Paket bereits im Standard-Update-Repository enthalten; alternativ kann man auf das Virtualization Repository zurückgreifen.

Unterstützte vmdk-Formate

qemu-nbd greift intern auf die Fähigkeiten von "qemu-img" zurück. Die Seite en.wikibooks.org-wiki-QEMU-Images informiert darüber, welche vmdk-Formate (neben vielen anderen Formaten) qemu-img in einer aktuellen Version (≥ 2.9) unterstützt:

vmdk:
VMware 3 & 4, or 6 image format, for exchanging images with that product

Das Interessante ist, dass qemu-nbd die vorgegebenen vmdk-Dateien zu Snapshots und zur vmdk-Base-Disk nach außen - also in Richtung Linux-User - zu einem Block-Device zusammenführt. qemu-nbd legt also einen Block-Layer über die komplexe vmdk-Adressierungsstruktur. Die Hauptarbeit leistet dabei ein Kernelmodul.

Dreisatz zur Anwendung von qemu-nbd

Drei Schritte sind notwendig, um zu dem gewünschten Block-Devices und darin enthaltenen Filesysteme zu mounten.

Schritt 1 - Kernel-Modul laden:
Zunächst muss das "nbd"-Kernel-Modul geladen werden. Die Seite "kernel.org-Documentation-zu-nb erläutert die möglichen Parameter. Dieselbe Info liefert natürlich auch "modinfo":

mytux:~ # modinfo nbd
filename:       /lib/modules/4.4.120-45-default/kernel/drivers/block/nbd.ko
license:        GPL
description:    Network Block Device
srcversion:     6F062B770FED9DC58072736
depends:        
retpoline:      Y
intree:         Y
vermagic:       4.4.120-45-default SMP mod_unload modversions 
signer:         openSUSE Secure Boot Signkey
sig_key:        03:32:FA:9C:BF:0D:88:BF:21:92:4B:0D:E8:2A:09:A5:4D:5D:EF:C8
sig_hashalgo:   sha256
parm:           nbds_max:number of network block devices to initialize (default: 16) (int)
parm:           max_part:number of partitions per device (default: 0) (int)

In meinem Testfall erwarte ich maximal 4 (NTFS/FAT-) Partitionen pro vmdk-Device, also:

mytux:/etc # modprobe nbd max-part=4
mytux:/etc # 

Schritt 2 - nbd-Device wählen und mit dem Disk-Image verknüpfen:
Defaultmäßig hält Linux 15 potentielle nbd-Devices unter dem Verzeichnis "/dev" vor. Nun muss ein solches "nbd"-Block-Device natürlich noch mit einem Disk-Image verbunden werden. Wurde das Device "/dev/nbdx" - alos z.B. "/dev/nbd0" - noch nicht anderweitig benutzt, können wir es mit einem Disk-Image mittels der "-c" (= --connect) Option des Kommandos "<strong>qemu-nbd</strong>" zusammenführen.

Vorher müssen wir ein geeignetes Image wählen. Leser meines letzten Artikels wissen, dass auf meinem (selbst virtualisierten) Linux-System ein Testverzeichnis mit Dateien eines Win7-Gastes einer VMware-Umgebung existiert. Das Verzeichnis beinhaltet u.a. den zweiten Snapshot eines growable, sparse vmdk-Disk-Images zu einer Disk "Win7_x64_ssdx". Um es noch komplizierter zu machen, befinden sich die ursprüngliche Deskriptor-Datei und die zugehörigen Extent-Dateien (inkl. der ursprünglichen Basis-Datei) in einem anderen Verzeichnis "/vmw/Win7".

Das Verzeichnis "/vmw/Win7Test/" beinhaltet dagegen die Delta-Dateien (Deskriptor und Extents):

mytux:/vmwssd_w7prod/Win7_x64 # la | grep ssdx
-rw------- 1 myself  users    1507328 Mar 28 20:26 Win7_x64_ssdx-000001-s001.vmdk
-rw------- 1 myself  users      65536 Mar 28 19:54 Win7_x64_ssdx-000001-s002.vmdk
-rw------- 1 myself  users        370 Mar 28 20:24 Win7_x64_ssdx-000001.vmdk
-rw------- 1 myself  users     851968 Mar 29 10:38 Win7_x64_ssdx-000002-s001.vmdk
-rw------- 1 myself  users      65536 Mar 28 20:26 Win7_x64_ssdx-000002-s002.vmdk
-rw------- 1 myself  users      10240 Mar 29 10:37 Win7_x64_ssdx-000002.vmdk

Die Verlinkung zu den Ursprungsdateien unter "/vmw/Win7"

mytux:/vmwssd_w7prod/Win7_x64 # la /vmw/Win7/ | grep ssdx
-rw-------  1 myself  users 2344157184 Mar 28 19:53 Win7_x64_ssdx-s001.vmdk
-rw-------  1 myself  users     131072 Mar 27 19:37 Win7_x64_ssdx-s002.vmdk
-rw-------  1 myself  users        511 Mar 28 19:51 Win7_x64_ssdx.vmdk

ist, wie wir aus dem vorhergehenden Artikel wissen, natürlich über Verweise in den Deskriptor-Dateien Win7_x64_ssdx-000002.vmdk und Win7_x64_ssdx-000001.vmdk der Snapshots festgelegt.

Kommt qemu-nbd mit dieser komplexen Struktur klar? Ja - und wir müssen dabei nur die richtige Deskriptor-Datei angeben ...

mytux:/vmw/Win7Test # qemu-nbd -c /dev/nbd0 Win7_x64_ssdx-000002.vmdk 
mytux:/vmw/Win7Test # la /dev | grep nbd0
brw-rw----   1 root disk       43,   0 Mar 30 14:51 nbd0
brw-rw----   1 root disk       43,   1 Mar 30 14:51 nbd0p1
brw-rw----   1 root disk       43,   2 Mar 30 14:51 nbd0p2
mytux:/vmw/Win7Test # fdisk -l /dev/nbd0
Disk /dev/nbd0: 4 GiB, 4294967296 bytes, 8388608 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x0efb9e3e

Device      Boot   Start     End Sectors  Size Id Type
/dev/nbd0p1         2048 5312511 5310464  2.5G  7 HPFS/NTFS/exFAT
/dev/nbd0p2      5312512 8384511 3072000  1.5G  7 HPFS/NTFS/exFAT
mytux:/vmw/Win7Test # # 

Das, was hier so selbstverständlich aussieht, ist angesichts der Komplexität des vmdk-Formats eigentlich ein kleines Wunder. Man beachte, dass hier keine irgendwie geartete Kopie der vmdk-Disk in einem neuen Format erzeugt wurde. Vielmehr arbeiten wir auf den originalen Daten - deren Adressierung über eine Block-Layer-Schicht vermittelt wird. Dafür setzt qemu-nbd meines Wissens auch nicht FUSE ein (unix.stackexchange.com-questions-192875/qemu-nbd-vs-vdfuse-for-mounting-vdi-images)

Schritt 3 - Mounten:
So, wie wir qemu-nbd hier verwendet haben, ist es sehr zuvorkommend zu uns und weist neben dem Block-Device "/dev/nbd0" für die gesamte Disk gleich auch noch weitere Block-Devices für die intern erkannten Partitionen des Disk-Images aus. Letztere können wir direkt mounten:

mytux:/vmw/Win7Test # mount /dev/nbd0p2 /mnt2
mytux:/vmw/Win7Test # la /mnt2
total 196128
drwxrwxrwx  1 root root         0 Mar 28 09:52 $RECYCLE.BIN
drwxrwxrwx  1 root root      4096 Mar 28 20:25 .
drwxr-xr-x 39 root root      4096 Mar 28 17:02 ..
drwxrwxrwx  1 root root      4096 Mar 28 09:53 Cosmological_Voids
drwxrwxrwx  1 root root         0 Mar 28 20:26 Muflons
drwxrwxrwx  1 root root         0 Mar 28 09:51 System Volume Information
-rwxrwxrwx  2 root root 200822784 Nov  4  2013 mysql-installer-community-5.6.14.0.msi
drwxrwxrwx  1 root root         0 Mar 29 10:37 ufos

Zugriffs-Rechte und deren Abänderung

Ähnlich wie bei "vmware-mount", das wir im ersten Artikel dieser Serie behandelt hatten, bekommen wir je nach Zweck der vmdk-Untersuchung ggf. ein Problem mit Rechten - siehe die durchgehenden 777-Rechte-Kämme nach dem Mounten. Im Fall von qemu-nbd können wir das aber rechtzeitig im Zuge des Mountens korrigieren.

Dabei ist - je nach Untersuchungszweck - die Frage zu stellen: Wer soll welche Art von Zugriff erhalten und wie privilegiert soll derjenige sein? Ich zeige mal 2 Varianten. (Für das genauere Verständnis sollte man sich mit Mount-Optionen und umasks bzw. fmasks und dmasks befassen.)

Variante 1: Nur Root soll rein lesenden Zugang erhalten:

mytux:/vmw/Win7Test # mount -o uid=root,gid=root,umask=0277 /dev/nbd0p2 /mnt2
mytux:/vmw/Win7Test # la /mnt2
total 196128                                                                                                                        
dr-x------  1 root root         0 Mar 28 09:52 $RECYCLE.BIN/                                                                        
dr-x------  1 root root      4096 Mar 28 20:25 ./                                                                                   
drwxr-xr-x 39 root root      4096 Mar 28 17:02 ../
dr-x------  1 root root      4096 Mar 28 09:53 Cosmological_Voids/
dr-x------  1 root root         0 Mar 28 20:26 Muflons/
dr-x------  1 root root         0 Mar 28 09:51 System Volume Information/
-r-x------  2 root root 200822784 Nov  4  2013 mysql-installer-community-5.6.14.0.msi*
dr-x------  1 root root         0 Mar 29 10:37 ufos/

Variante 2: Nur der User "myself" soll lesenden und schreibenden Zugang zu Dateien und Directories des gemounteten NTFS-Systems erhalten:

mytux:/vmw/Win7Test # mount -o uid=rmx,gid=users,fmask=0177,dmask=0077 /dev/nbd0p2 /mnt2
mytux:/vmw/Win7Test # la /mnt2
total 196128
drwx------  1 myself  users         0 Mar 28 09:52 $RECYCLE.BIN
drwx------  1 myself  users      4096 Mar 28 20:25 .
drwxr-xr-x 39 root root       4096 Mar 28 17:02 ..
drwx------  1 myself  users      4096 Mar 28 09:53 Cosmological_Voids
drwx------  1 myself  users         0 Mar 28 20:26 Muflons
drwx------  1 myself  users         0 Mar 28 09:51 System Volume Information
-rw-------  2 myself  users 200822784 Nov  4  2013 mysql-installer-community-5.6.14.0.msi
drwx------  1 myself  users         0 Mar 29 10:37 ufos
mytux:/vmw/Win7Test # 

Die Linux-Rechte sagen allerdings wenig darüber aus, wem ggf. neu angelegte Dateien mit welchen Rechten dann später welchem User auf einem virtuellen Windows gehören würden. Siehe zu dieser Thematik den entsprechenden Abschnitt und zugehörige Links im ersten Artikel der Serie.

Unmounten und Entfernen der Beziehung eines nbd-Devices zum Disk-Image

Nachdem man die Untersuchung einer Partition des vmdk-Disk-Images unter Linux abgeschlossen hat, muss man alles wieder rückgängig machen. Das geht wie folgt:

mytux:/vmw/Win7Test # umount /mnt2
mytux:/vmw/Win7Test # qemu-nbd -d /dev/nbd0 
/dev/nbd0 disconnected
mytux:/vmw/Win7Test # rmmod nbd
mytux:/vmw/Win7Test # 

Den umount-Befehl muss man natürlich für alle ggf. gemounteten Partitionen absetzen.

Nutzung von Loop-Devices?

nbd war deshalb sehr hilfsbereit, weil wir beim Laden des Kernelmoduls vorgegeben hatten, wieviele Partitionen maximal verwaltet werden sollen. Frage: Können wir die Partitionen auch anders bekommen, wenn wir etwa den Parameter des Kernelmoduls weglassen? Antwort: Ja, das geht.

Ich möchte zwei Varianten vorstellen, die sich nicht nur auf nbd-Devices, sondern in gleicher Weise auch auf raw- oder flat-Files, die man etwa als Output von "vmware-mount -f" erhalten würde, anwenden lassen.

Die erste Methode nutzt Loop-Devices. Loop- oder Loopback-Devices kennt der Linux-Anwender normalerweise im Zusammenhang mit mit der Nutzung von Filesystemen, die von Raw-Dateien beherbergt werden. Man vergisst dabei oft, dass sich Loop-Devices auch Block-Devices überstülpen lassen; die man-Page zu "losetup" sagt dazu:

DESCRIPTION
losetup is used to associate loop devices with regular files or block devices, to detach loop devices, and to query the status of a loop device.

Letztlich ist unter Linux/Unix halt alles ein File :-). Also:

mytux:/vmw/Win7Test # modprobe nbd
mytux:/vmw/Win7Test # qemu-nbd -c /dev/nbd0 Win7_x64_ssdx-000002.vmdk 
mytux:/vmw/Win7Test # la /dev | grep nbd0
brw-rw----   1 root disk       43,   0 Mar 31 15:19 nbd0

mytux:/vmw/Win7Test # fdisk -l /dev/nbd0
Disk /dev/nbd0: 4 GiB, 4294967296 bytes, 8388608 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x0efb9e3e

Device      Boot   Start     End Sectors  Size Id Type
/dev/nbd0p1         2048 5312511 5310464  2.5G  7 HPFS/NTFS/exFAT
/dev/nbd0p2      5312512 8384511 3072000  1.5G  7 HPFS/NTFS/exFAT

Nun müssen wir noch die Offsets der Partitionen in Bytes aus den Start und End-Sektoren berechnen:

Offset Partition 1: 2048 * 512 = 1048576
Offset Partition 2: 5312512 * 512 = 2720006144

Diese Offset-Positionen sind dann über die Option "-o" im losetup-Kommando anzugeben:

mytux:/vmw/Win7Test # losetup -o 1048576 /dev/loop1 /dev/nbd0
mytux:/vmw/Win7Test # losetup -o 2720006144 /dev/loop2 /dev/nbd0
mytux:/vmw/Win7Test # mount /dev/loop1 /mnt2
mytux:/vmw/Win7Test # mount /dev/loop2 /mnt3
mytux:/vmw/Win7Test # la /mnt2
total 8
drwxrwxrwx  1 root root    0 Mar 27 19:35 $RECYCLE.BIN
drwxrwxrwx  1 root root 4096 Mar 27 19:35 .
drwxr-xr-x 39 root root 4096 Mar 28 17:02 ..
drwxrwxrwx  1 root root    0 Mar 27 19:34 System Volume Information

mytux:/vmw/Win7Test # touch /mnt2/hallo.txt
mytux:/vmw/Win7Test # la /mnt2
total 8
drwxrwxrwx  1 root root    0 Mar 27 19:35 $RECYCLE.BIN
drwxrwxrwx  1 root root 4096 Mar 31 15:24 .
drwxr-xr-x 39 root root 4096 Mar 28 17:02 ..
drwxrwxrwx  1 root root    0 Mar 27 19:34 System Volume Information
-rwxrwxrwx  1 root root    0 Mar 31 15:24 hallo.txt

mytux:/vmw/Win7Test # la /mnt3
total 196128
drwxrwxrwx  1 root root         0 Mar 28 09:52 $RECYCLE.BIN
drwxrwxrwx  1 root root      4096 Mar 28 20:25 .
drwxr-xr-x 39 root root      4096 Mar 28 17:02 ..
drwxrwxrwx  1 root root      4096 Mar 28 09:53 Cosmological_Voids
drwxrwxrwx  1 root root         0 Mar 28 20:26 Muflons
drwxrwxrwx  1 root root         0 Mar 28 09:51 System Volume Information
-rwxrwxrwx  2 root root 200822784 Nov  4  2013 mysql-installer-community-5.6.14.0.msi
drwxrwxrwx  1 root root         0 Mar 31 14:02 ufos
mytux:/vmw/Win7Test # 
mytux:/vmw/Win7Test # cat /mnt3/ufos/ufo.txt
Ufos are not real
mytux:/vmw/Win7Test #

Zurückdrehen können wir den gesamten Prozess wie folgt:

mytux:/vmw/Win7Test # umount /mnt3
mytux:/vmw/Win7Test # umount /mnt2
mytux:/vmw/Win7Test # losetup -d /dev/loop2
mytux:/vmw/Win7Test # losetup -d /dev/loop1
mytux:/vmw/Win7Test # qemu-nbd -d /dev/nbd0 
/dev/nbd0 disconnected
mytux:/vmw/Win7Test # modprobe -r nbd
mytux:/vmw/Win7Test # 

Loop-Devices und "vmware-mount -f"
Das Ganze klappt natürlich auch mit "vmware-mount -f" und dem dadurch erzeugten "flat"-File (s. den ersten Artikel):

mytux:/vmw/Win7Test # vmware-mount -f Win7_x64_ssdx-000002.vmdk /mnt/vmdk
mytux:/vmw/Win7Test # la /mnt/vmdk
total 4194304
-rw------- 1 myself users 4294967296 Mar 31 15:25 flat
mytux:/vmw/Win7Test # losetup -o 2720006144 /dev/loop2 /mnt/vmdk/flat 
mytux:/vmw/Win7Test # mount /dev/loop2 /mnt3
mytux:/vmw/Win7Test # cat /mnt3/ufos/ufo.txt 
Ufos are not real
mytux:/vmw/Win7Test # umount /mnt3
mytux:/vmw/Win7Test # losetup -d /dev/loop2
mytux:/vmw/Win7Test # vmware-mount -d /mnt/vmdk
mytux:/vmw/Win7Test #

Über diesen Weg können wir übrigens auch das Problem mit den Zugriffsrechten lösen, dass wir im ersten Artikel für "vmware_mount" angesprochen hatten - wir legen die Rechte analog zum oben besprochenen Vorgehen im Zuge des mount-Befehls fest.

kpartx?

Erfahrene Linux-User wissen, dass kpartx ein nettes Tool ist, das aus Block-Devices oder Raw-Files evtl. enthaltene Partitionstabellen ermittelt und über "/dev/mapper" entsprechende Devices bereitstellt. Das funktioniert natürlich auch auf Basis von "/dev/nbdX"-Devices:

mytux:/vmw/Win7Test # modprobe nbd
mytux:/vmw/Win7Test # qemu-nbd -c /dev/nbd0 Win7_x64_ssdx-000002.vmdk 
mytux:/vmw/Win7Test # kpartx -av /dev/nbd0 
add map nbd0p1 (254:12): 0 5310464 linear 43:0 2048
add map nbd0p2 (254:13): 0 3072000 linear 43:0 5312512    
mytux:/vmw/Win7Test # la /dev/mapper | grep nbd0
lrwxrwxrwx  1 root root       8 Mar 31 15:58 nbd0p1 -> ../dm-12
lrwxrwxrwx  1 root root       8 Mar 31 15:53 nbd0p2 -> ../dm-13
mytux:/vmw/Win7Test # mount /dev/dm-13 /mnt3
mytux:/vmw/Win7Test # cat /mnt3/ufos/ufo.txt
Ufos are not real
mytux:/vmw/Win7Test # umount /mnt3
mytux:/vmw/Win7Test # kpartx -d /dev/nbd0
mytux:/vmw/Win7Test # la /dev/mapper | grep nbd0
mytux:/vmw/Win7Test # modprobe -r nbd
mytux:/vmw/Win7Test # 

Analog für ein flat-File von vmware-mount:

mytux:/vmw/Win7Test # vmware-mount -f Win7_x64_ssdx-000002.vmdk /mnt/vmdk
mytux:/vmw/Win7Test # kpartx -av /mnt/vmdk/flat 
add map loop0p1 (254:12): 0 5310464 linear 7:0 2048
add map loop0p2 (254:13): 0 3072000 linear 7:0 5312512
mytux:/vmw/Win7Test # mount /dev/dm-13 /mnt3
mytux:/vmw/Win7Test # cat /mnt3/ufos/ufo.txt
Ufos are not real
mytux:/vmw/Win7Test # umount /mnt3
mytux:/vmw/Win7Test # kpartx -d /mnt/vmdk/flat
loop deleted : /dev/loop0
mytux:/vmw/Win7Test # vmware-mount -d /mnt/vmdk
mytux:/vmw/Win7Test # 

Alles gut !

Read-Only-Option?

In allen oben dargestellten Beispielen haben wir bislang durchgehend rw-Mounts durchgeführt. Da ist bei vielen Analysen nicht erwünscht. Grundsätzlich ist im Umgang mit Partitionen regelmäßig Vorsicht angebracht, um nichts zu zerstören. Write-´Zugriffe sollte man immer zuerst auf Kopien testen.

Daher stellt sich die Frage nach einer "ro"-Option von "qemu-nbd". Die gibt es, sie lautet "-r". Deren Setzung schlägt auf alle weiteren Maßnahmen durch:

mytux:/vmw/Win7Test # modprobe nbd max-part=4
mytux:/vmw/Win7Test # qemu-nbd -r -c /dev/nbd0 Win7_x64_ssdx-000002.vmdk 
mytux:/vmw/Win7Test # mount /dev/nbd0p2 /mnt3
fuse: mount failed: Permission denied
mytux:/vmw/Win7Test # mount -o ro /dev/nbd0p2 /mnt3
mytux:/vmw/Win7Test # 

Gibt es Größenlimit für die virtuelle Disk?

Ehrlich gesagt: keine Ahnung. Wenn es ein aktuelles Limit gibt, würde ich aufgrund älterer Infos im Zusammenhang mit nbd auf 1TB tippen. Wenn jemand was Genaueres weiß, kann er mir ja eine Mail schreiben. Siehe auch:

vsphere-50 und vddk
vddk51_programming.pdf

Fazit und Ausblick

Das nbd-Kernelmodul und das Kommando qemu-nbd eröffnen relativ einfache Zugänge zu komplexen vmdk-Image-Dateien. Dabei wird auch die aktuelle Version 6 des vmdk-Formats beherrscht. Wir haben zudem die Möglichkeit, das Mounten der bereitgestellten nbd-Block-Devices bzgl. der Rechte individuell zu gestalten.

Im nächsten Artikel

Mounten eines vmdk-Laufwerks im Linux Host – IV – guestmount, virt-filesystems, qemu-img

gehe ich kurz auf "qemu-img" ein und betrachte dann das Kommando "guestmount" aus der neueren und Fuse-basierten Toolkiste von "libguestfs".

Links

losetup - Abkürzung für bestimmte mknod-Operationen zur Nutzung von Loop-Devices
unix.stackexchange.com/questions/98742/how-to-add-more-dev-loop-devices-on-fedora-19

qemu-nbd
https://wiki.ubuntuusers.de/QEMU/
https://opsech.io/posts/2017/Jun/07/how-to-mount-vm-disk-images-on-fedora.html
http://blog.vmsplice.net/2011/02/how-to-access-virtual-machine-image.html
https://sweetcode.io/introduction-to-linux-network-block-devices/