How to install ViciBox 12 / VICIdial on Google Compute Engine (GCE)

1. Is it possible on Google Cloud?

Yes. We run ViciBox 12 / VICIdial on Google Compute Engine in production today: web admin and agent UIs, Asterisk, MariaDB, agent softphones, and carrier SIP trunks handling live outbound and inbound contact-center traffic.

It is not a one-click marketplace appliance. ViciBox expects an openSUSE Leap 15.6 installer world. GCE will not boot that ISO the way VirtualBox or VMware does. The path that got us to production was:

lab install → export disk → import to GCE → offline virtio/boot repair → Express app install → NAT, TLS, carrier trunks → agent phones → campaigns and floor ops → freeze a reusable image.

If someone tells you “just upload the ISO and next-next-finish on GCP,” they have not done this install. For how a production floor behaves after the stack is healthy, see our fintech VICIdial case study.

3. Preparations

Built for teams putting a real VICIdial floor on GCE — not a disposable lab forever.

• GCP project with Compute Engine, billing, and a region close to agents/carriers (example for Indonesia-facing ops: asia-southeast2).
• Custom images with UEFI_COMPATIBLE, snapshots, static IPs, VPC firewall. See Google’s docs on importing disks and creating custom images.
• A completed ViciBox 12 install in a lab hypervisor you can export as a boot disk (VICIdial / ViciBox project).
• A small rescue image (Debian works) in the same zone for offline chroot repair.
• SSH keying and a locked admin source for port 22.
• Carrier ready: SIP trunk credentials, expected dial patterns, Caller ID rules, and whether agents use UDP SIP softphones.
• FQDN and certificate plan for HTTPS and any SIP-TLS trunks.
• Written go-live criteria (next section) and a habit of snapshotting before Express and before trunk cutover.

5. Execution

Phase A — Disk onto GCE

Install ViciBox 12 in the lab, export the boot disk, import into GCE as a custom image/disk. Do not expect a cloud DVD wizard. Early imports taught us GRUB can look healthy while the guest never reaches a real root filesystem.

Phase B — Boot repair

Stop the broken VM, attach the boot disk to a rescue VM in the same zone, mount root and EFI (our working case: root part4, EFI part2), chroot, add virtio drivers to dracut, rebuild initrds, regenerate GRUB. Confirm with lsinitrd … | grep virtio. UEFI_COMPATIBLE helps firmware/GRUB; it does not replace virtio in the initramfs.

add_drivers+=" virtio virtio_pci virtio_pci_modern_dev virtio_pci_legacy_dev virtio_ring virtio_scsi virtio_blk virtio_net scsi_mod sd_mod "

console=tty0 console=ttyS0,38400n8 net.ifnames=0 biosdevname=0 plymouth.enable=0

Phase C — Network and first production-shaped VM

Serial login without SSH usually means VirtualBox NIC rules still own the story. Delete /etc/udev/rules.d/70-persistent-net.rules, write DHCP ifcfg for eth0/eth1/ens4, bake a UEFI custom image, launch the production host on a dedicated VPC with static external IP and tight tags.

rm -f /etc/udev/rules.d/70-persistent-net.rules

for iface in eth0 eth1 ens4; do
  printf 'STARTMODE=auto\nBOOTPROTO=dhcp\n' > /etc/sysconfig/network/ifcfg-$iface
done

Phase D — Express (VICIdial application)

SSH is not a dialer. Snapshot the disk, then run Express from a temporary copy of the installer with --skipexternal so cloud NAT is under your control. On our 12.x tree the skipexternal path called undefined debugoutput — a no-op on the copy fixed it. Never edit the packaged installer in place.

sub debugoutput { return; }

# Copy the installer tree to a temp workdir first, then:
printf 'y\n' | perl /root/vicibox-install-tmp/vicibox-install.pl \
  --vicibox-express \
  --skipexternal \
  > /root/vicibox-install-tmp/express.stdout \
  2> /root/vicibox-install-tmp/express.stderr

If admin UI 500s: /etc/astguiclient.conf must be readable by Apache (640 root:www on this stack). Agent UI 200 and admin login challenge mean the app is alive. Rotate the default high-level admin before the host is treated as production.

chgrp www /etc/astguiclient.conf
chmod 640 /etc/astguiclient.conf
systemctl reload apache2 || systemctl restart apache2

Phase E — NAT, edge, and certificates

• vicibox-externip with the static external IP.
• sip.conf / pjsip.conf external addresses and localnet for the VPC CIDR (Asterisk SIP/PJSIP concepts: Asterisk SIP docs).
• DB server rows aligned to the same external identity.
• Firewall: SSH locked; web controlled; SIP/RTP only as the carrier design requires — never “open everything to debug.”
• FQDN + certificates for HTTPS and SIP-TLS trunks (on our production host, LE material is wired for the public name; Apache and Asterisk can need separate install paths).

Note: http://<ip>/ may 403 while /agc/vicidial.php and /vicidial/admin.php are the real surfaces.

Phase F — Carrier SIP and production floor

This is the line between “stack installed” and “production dialer.”

• Define carriers in VICIdial with dialplan patterns that match how you build numbers (example: campaign prefix + national mobile form that hits SIP/carrier-trunk — never invent a string the dialplan does not own).
• Carrier Caller ID rules matter: bare originates without CID can fail (e.g. 484) even when the trunk is healthy.
• Agent phones: chan_sip UDP registration to the host; registration password is not always the same field as the agent UI login password.
• Campaigns and lists for the real floor, hopper or owner-dial rules, and local call-time/GMT aligned to your market (server GMT and lead offsets must match where agents and customers actually are).
• Inbound DIDs and any secondary trunks (including messaging/SIP side paths) only after the primary PSTN path is proven.
• Day-2: dead-call cleanup, list reset hygiene, monitoring — production is a living system, not a single green check.

Prove go-live with: trunk qualify/register, controlled originate with correct CID, agent softphone REGISTERED, manual dial that rings a real handset, then campaign traffic under supervision. Freeze a post-cutover snapshot and UEFI custom image once that holds across stop/start.

Extractable answers (cost, ISO myth, boot, SIP, softphone)

Self-contained blocks for the questions this install log already implies. Details still live in the journey sections above; floor KPIs live in the production case study, and the VICIdial installation service explains the infrastructure, testing, and handover path for teams planning the same build.

How much does ViciBox on GCE cost?

Answer: Budget a steady Compute Engine VM, disk and snapshot storage, and usually a static external IP — not $0. Carrier SIP and people time dominate once agents are live.

• VM class — production shape we reuse: general-purpose 4 vCPU (e.g. e2-standard-4) near agents/carriers.
• Disk — ~50 GB balanced boot plus snapshot/image storage for rebuilds.
• IP — static external IP when carriers need stable signaling (billable when reserved).
• Outside GCP — SIP trunk minutes, DIDs, and operator time are not in the Google invoice.

Why not a marketplace appliance or “cloud ISO” install?

Answer: There is no trustworthy one-click DVD path for production ViciBox 12 on GCE. Marketplace shortcuts and “boot the ISO in the cloud” myths skip virtio, NAT, Express, and carrier work.

• Proven path: lab ViciBox 12 → disk export/import → boot repair → Express → NAT/TLS → trunks → phones.
• UEFI guest flags alone do not make a bare ISO image production-ready.
• See section 1 and Phase A–B for the import path we use.

Virtio / boot repair checklist (single block)

Answer: If the imported disk hangs after GRUB, fix virtio in a rescue chroot before blaming ViciBox itself.

1. Attach the disk to a rescue VM in the same zone; mount and chroot.
2. Ensure virtio block/SCSI (and related) drivers are in dracut; rebuild initramfs.
3. Verify with lsinitrd that virtio modules are present.
4. Fix GRUB serial / legacy NIC naming baggage from the lab hypervisor when needed.
5. Build a UEFI_COMPATIBLE custom image; boot a fresh instance; confirm SSH after stop/start.
6. Only then run Express and app configuration (snapshot first). Full narrative: Phase B.

SIP/RTP ports and NAT on public cloud

Answer: Treat the dialer as a public-cloud PBX: one consistent external IP/NAT story, tight firewall tags, and carrier-shaped SIP/RTP — never world-open “debug” ports.

• SSH locked to admin sources; web 80/443 controlled; SIP/RTP only as the trunk design requires.
• External IP and NAT must match sip/pjsip and VICIdial server IP fields or trunks fail mysteriously.
• Prefer a dedicated VPC and network tags for dialer traffic separate from other apps.
• FQDN + certificates for HTTPS and any SIP-TLS trunks. Details: Phase E–F.

Agent softphone path (high level)

Answer: Prove one agent phone end-to-end before campaigns. On our GCE production shape, agent softphones typically register UDP SIP (chan_sip) while trunks follow the carrier’s UDP SIP and/or PJSIP TLS path.

• Create/test phone → register softphone → manual dial with correct CID → hear far end.
• Do not open the floor until trunk qualify + one real call succeed across stop/start.
• Some floors use browser WebRTC phones instead — pick one path and document it; do not mix casually.
• Operational scale-up of agents and KPIs: case study.

Go-live gates and “Not proven” list

Answer: SSH and a green Apache page are not production. Treat anything below as not proven until checked.

• Not proven: import without stop/start persistence.
• Not proven: UI only on a temporary IP without the planned FQDN/TLS path.
• Not proven: trunk “registered” without a successful originate + correct CID.
• Not proven: agent account exists but softphone never places a real call.
• Not proven: campaign traffic before lists/prefixes match carrier dial patterns.
• Go-live: ladder in Planning — each rung holds before the next.