Exclusive Configuration Lock During a Maintenance Window
A four-member QFX5100 Virtual Chassis provides Top-of-Rack access for a VMware cluster. You manage it in-band over IRB unit 300 (10.30.0.1/24) and also have an out-of-band console server. A colleague opened configure exclusive on member 0 to add VLAN 50 to trunk interface xe-0/0/0 and then left for a meeting without committing. Your attempt to add a new uplink returns: configuration database locked by: jdoe (pid 12345). The colleague is unreachable, the maintenance window has 30 minutes left, and their VLAN 50 change is still uncommitted in that session. A previous engineer resolved a similar stall by rebooting the Virtual Chassis primary, which caused a six-minute outage and reset several protocols. You must complete both changes without an outage.
1. How do you determine whether the lock is stale, and how do you clear it without rebooting the primary?
Read the worked answer
First confirm the session is genuinely still present: run show system users and look for jdoe's login and terminal. If the session is listed, the lock is real, not stale. configure exclusive holds the shared configuration database until that session ends or the user exits configuration mode; simply being idle does not release it.
Clear it without reboot by terminating the session, for example with request system logout user jdoe, or by asking the console operator to do the same. Verify with show system users and by entering configuration mode yourself; a successful commit check proves the lock is gone. Rebooting the primary was unnecessary and risky: it forces a Virtual Chassis mastership change and can reset line cards and protocol sessions, which is a much larger event than ending one login. Only if the session cannot be killed because it is wedged should you consider a more invasive recovery, and even then use the console rather than a blind reboot.
2. After the lock is cleared, describe the sequence for applying both the VLAN 50 change and your uplink change safely.
Read the worked answer
Assume the uncommitted VLAN 50 edit was discarded when the session ended. Verify before rewriting: run show configuration interfaces xe-0/0/0 | display set and check whether VLAN 50 is actually present in the committed configuration. If it is not, reapply it deliberately rather than assuming the abandoned candidate survived.
Then: run commit check to validate both changes; save a known-good point with request system configuration rescue save; apply the combined change using commit confirmed 5; from a second session or the console, verify show vlans, show ethernet-switching interface, and that management connectivity is intact; finally run commit to confirm and cancel the rollback timer. commit confirmed is exactly the protection you want for an in-band management change, because an unreachable session lets the device revert on its own. Note that only one confirmed commit timer exists, so do not stack another one while it is running.
3. How would `configure private` have changed the outcome, and what is the trade-off?
Read the worked answer
With configure private, each user edits a private candidate copy of the configuration. Other users are not blocked, and commits merge the private changes into the shared configuration. Your colleague could have left the session idle without stopping your work, and their VLAN 50 edit would have stayed private until committed.
The trade-off is coordination rather than exclusion: commits merge, so two people editing the same stanza can produce a commit error or an unintended combination. In a 30-minute window with two overlapping changes, configure private would have avoided the lockout but still requires a defined order and a check of show configuration | compare or show system commit before committing. For genuinely conflicting edits, configure exclusive is safer but must be held only for short, well-defined changes, and the engineer must not walk away while holding it.