Description of problem: If the host in 'uri' can't be resolved virt-builder fails with: curl: (6) Could not resolve host: foo Long story Let's say one adds a custom repo (e.g. the host is behind a VPN): $cat /etc/virt-builder/repos.d/foo.conf [foo] uri=http://foo.org/index.asc let's pretend for now that the 'foo.org' is resolvable when on the correct network. If one tries to build an appliance from the publicly available templates (e.g. centos-7.8) virt-builder fails with: curl: (6) Could not resolve host: foo In order to work around the problem one has to either connect to the network which is able to resolve 'foo.org' even though we don't intend to provision any template provided by that server OR simply comment out the 'uri' keyword in the repo, neither of which is really convenient. It would be nice if virt-builder repo syntax adopted something like DNF's skip_if_unavailable=True Version-Release number of selected component (if applicable): guestfs-tools-1.49.2-1.fc37.x86_64