Option to persist domain after built
Opened this issue · 4 comments
Currently, after a successful build and the domain is stopped, the domain will be undefined.
I'd like to have an option to persist domain as an artifact (much like what we can do with volume).
Use case: after the domain is built and persisted, I can invoke virsh or using virt-manager to use the VM right away. I think having the volume alone is kind of useless (I can use QEMU if I only want to build the volume).
Another idea is to have a libvirt post-processor (taking a volume as the input). This is a more flexible solution and I can use QEMU plugin with it.
Right now my work around is to use QEMU plugin to build the box, import it to libvirt with this plugin, then have an intentionally failed provision script to persist the domain.
Hi,
There are two separate ideas here, let me try to react to both.
First, about the issue of persisting the domain itself:
I don't think that is a wise idea, the purpose of packer is to build reusable artifacts. What you are trying to have here is more of a job for Terraform. In my home build, I use this provider from dmacvicar to start and manage VMs. The images I build with this packer plugin will serve as base images for those VMs, but that's just one way to use this.
For these reasons, I believe that persisting the domain created by packer is not the right way and hence it won't be implemented.
Your idea of importing/uploading artifacts built by the qemu provider in the post-processing step sounds good. To manage expectations: I'm still having some busy days ahead of me, then a long vacation. I'll probably get back to this at the end of September or the beginning of October.
I know about and have been using the Terraform provider before trying to accomplish the same thing with Packer alone. This way I can avoid duplicating the machine specs in both Packer and Terraform configuration.
For the first idea, yes, I agree that having a domain running after a build goes against the purpose of using Packer. I should have used the right words there. What I meant is to have an option to export a domain definition file (a .xml file) as an artifact. This way I can get a VM running simply with just 1-2 commands virsh define ... && virsh start ....
For the second option, if you agree with making a post-processor provider then it's all good. I expect to have a simple way to get a libvirt VM from a provided image file, so if a method is provided, I don't care much how it is achieved. You can take your time how you like it since this is your project after all. I don't mind waiting.
The reason for wanting to persist a domain definition instead of only the volume is that unlike other Packer plugins, libvirt doesn't provide a convenient way to get a VM from a volume alone. Writing a domain xml file from scratch is pretty horrible.
For comparison, virtualbox plugin provides a way to export the built machine (OVA/OVF file with VM specs defined) that can simply be imported to have a VM running.