A VM Is One XML Document, and nsswitch Decides Accounts — libvirt and LDAP

In one line

The Operations domain of the LFCS has "create and manage virtual machines with libvirt", and the Users and Groups domain has "configure LDAP accounts". Both are heavy to actually do inside this platform's VM (nested virtualization, an LDAP server). So this module covers only concepts. There are two key points. In libvirt a VM is one XML document, and virsh is the tool that handles that document. An LDAP account does not replace /etc/passwd; it is one slot in the order that nsswitch decides.

Why this exists

When you handle Linux on nodes, you meet two situations. One is "a few VMs run on this server and one won't start", and the other is "this account is not in /etc/passwd but it can log in". The first is the realm of libvirt and the second is that of LDAP/sssd. Both are in the exam scope, and for both, knowing "what is written where" solves half of it.

This lab environment is a VM on KubeVirt. Turning KVM on again inside it requires nested virtualization (vm_nested), and setting up an LDAP server and attaching a client is too big for one lab. So here we organize the structure confirmed from the documentation and check it with a quiz.

How it works

A libvirt VM is called a domain and is defined in XML. The libvirt domain XML format document is the whole of that syntax. Under the top-level <domain type='kvm'> come <name>, <memory>, <vcpu>, <os> (boot method), and <devices> (disks, networks, consoles). For a disk, you write "which file as which device of the guest" with <source file='…'/> and <target dev='vda' bus='virtio'/> inside <disk type='file' device='disk'>. For networking, <interface type='network'> attaches to a virtual network managed by libvirt (the default, default, NAT), and <interface type='bridge'> attaches to a host bridge.

virsh is the shell that handles that XML. It is easy to memorize the frequently used verbs if you look at them as state transitions.

What it does	Command	Note
Define only (register in a stopped state)	virsh define 파일.xml	A persistent domain
Define and start right away	virsh create 파일.xml	A transient domain
Start / graceful shutdown / forced shutdown	virsh start / shutdown / destroy	destroy is a power cut
Delete the definition	virsh undefine	The disk file remains
View / edit the definition	virsh dumpxml / virsh edit	edit saves after validation
List	virsh list --all	Without --all, only the running ones
Auto-start at boot	virsh autostart

The name destroy is a trap. It does not delete; it pulls the power, and the definition remains. Deleting the definition is undefine, and even that does not delete the disk image.

There are two kinds of snapshots. The libvirt snapshot guide distinguishes internal snapshots and external snapshots. An internal snapshot keeps the state inside the qcow2 image, and an external snapshot creates a new overlay file and leaves the original as a read-only backing file. The snapshot XML format defines the <domainsnapshot> document, and you create it with virsh snapshot-create-as. The places you run into in practice are that a snapshot that holds only the disk differs from one that holds the memory state too, and that the chain of external snapshots needs management (block commit).

An LDAP account starts from one line of nsswitch. nsswitch.conf(5) decides, for each database such as passwd, group, and shadow, "which sources in which order". passwd: files sss means it looks at /etc/passwd first and asks sssd if it is not there. getent passwd 이름 (the placeholder is the account name) follows exactly this order, so the first command to ask "where does this account come from" is getent.

Behind that is SSSD. sssd is a daemon between remote account stores such as LDAP, Kerberos, and AD and the local system; it provides modules for both NSS (account lookup) and PAM (authentication) and keeps an offline cache. So even if the LDAP server goes down for a while, cached accounts can still log in. The configuration takes the form of writing id_provider = ldap, ldap_uri, and ldap_search_base in a domain section of /etc/sssd/sssd.conf, and the RHEL 9 documentation on configuring authentication and authorization explains the procedure of matching nsswitch and PAM together with authselect.

The tool that taps LDAP itself is ldapsearch. -H ldap://서버 says where (the placeholder is the server), -b "dc=example,dc=com" says under which branch, -x means simple authentication, and the last argument is the filter ((uid=alice)). The result comes out as LDIF, and posixAccount attributes such as uid, uidNumber, gidNumber, homeDirectory, and loginShell correspond to the columns of /etc/passwd. Looking directly with ldapsearch for an account sssd cannot find is the basis of diagnosis.

What it looks like in the field

For "the VM won't start", you look at the state with virsh list --all and check with virsh dumpxml whether the disk <source file> really exists. It is common for the path to be stale after storage was moved. Incidents where someone mistook virsh destroy for "delete", pressed it in a hurry, and cut a service are not rare either.

For "the LDAP user cannot log in", you narrow it down in order. If getent passwd 이름 (the placeholder is the account name) is empty, it is an NSS (nsswitch and sssd lookup) problem, and if it comes out but login fails, it is a PAM (authentication) problem. Because of sssd's cache, old results can remain even after you fix the server, so clear it with sss_cache -E and look again. And whether that entry can be looked up directly from the server with ldapsearch is the last branch.

What you will check in the next quiz

The difference between virsh define and create, what destroy and undefine each leave behind, which element the disk is written in within the domain XML, the difference between internal and external snapshots, the order that passwd: files sss in nsswitch.conf means, what sssd does in NSS and PAM, and -b and the filter of ldapsearch. The quiz asks only what this reading explained.