Feature: Allow exporting final product as a template rather than VM

[jhenry82]

I'd like to be able to import the final artifact of this plugin into XenServer directly as a template. Rather than suffer the horrible indignity of having to right-click Convert To Template in XenCenter (kidding ;)). But yes, it would be great to automate that step.

I'll submit a PR shortly. It adds a "convert_to_template" boolean that defaults to false. If true, the VM is converted to a template immediately before export. When this is set, I also delete any network interfaces from the VM, since in my personal use case I want the template to be totally generic and not tied to any specific VLAN. I'm open to putting that behavior behind a second option, but it seems to me that if you want a template, you don't want random artifacts of the build process hanging around.

[xenserverarmy]

@jhenry82 I like the feature, but the implementation is missing some key items to my eye:

1. convert_to_template doesn't make sense for xenserver-vm in its current configuration. I could see a world where you want to snapshot an existing VM, but there are far simpler ways to do that than running xenserver-vm. Suggest checking for the parameter in xenserver-vm and if present abort with guidance message. I'm not married to the "doesn't make sense" position, so happy to hear reasons why that might make sense ;)
2. If convert_to_template is used, I don't see much value in nfs_mount, sr_name, and output_directory. It would be best to ensure that those items aren't required if all you're doing is creating a template.
3. To my eye, convert_to_template makes more sense as an option for format than as a standalone parameter. Something like "format": "template" feels cleaner.

To the thought about cleaning the network options, perhaps having an optional parameter called nics? Give it a list of NICs like what you did with VMDisks. Then you could specify an empty list for the generic case. Might be worth putting that as a new feature to avoid muddying the discussion.

[jhenry82]

I wanted to check in and let you know I didn't (intentionally!) dump this PR and run. The code accomplishes what I selfishly want, but I'm totally onboard to improve the project for the whole community, too. Just been super busy lately. I really appreciate the detailed feedback.

1. I've honestly only ever used or needed the ISO builder, so I'm flying a bit blind on the others. I agree it's kind of weird to capture an existing VM and use it as a template... but is it objectively wrong or impossible? If it technically works, I don't see why we'd disallow it. What would the error message be? Creating a template is not the default, so they've gone out of their way to request it on purpose.

2. Not sure I agree with this. Why wouldn't I want the final build artifact available on an NFS share just because it's a template? My use case is building the template once on one VM server, and then having my whole farm of XenServer hosts import it so they can all deploy the exact same template. If packer doesn't export the template to output_dir, then I have an extra manual step of exporting it myself. But I could be missing something obvious about your point.

3. I could go either way. Do templates in XenServer HAVE to be in xva format? Or can they also exist as vhd and others? If there's only one valid format, then sure, this works. If the choice to convert to template is distinct from output format, I don't think this makes sense.

4. I'm happy to open a separate issue to make NICs configurable. Seems like that could be a useful feature. Would this be applicable to all of the builders?

I'll work on a new PR once we agree on all of the above. I'm heading out for a lengthy vacation starting next Friday, so it might be a bit before that hits. But I appreciate you taking the time to own this project and accept and comment on contributions!

PS: I noticed there's an unrelated fix to cross-compiling I made while trying to build for Linux on my personal Mac. You might want to commit that regardless.

-DEV_PLATFORM="./pkg/$(go env GOOS)_$(go env GOARCH)"
+DEV_PLATFORM="./pkg/${XC_OS}_${XC_ARCH}"

[xenserverarmy]

It's probably worthwhile to look at the assumed semantics of each of the builders (which I think I'm going to want to doc anyway).

xenserver-iso is intended to create a VM from a source ISO. The expected artifact is a VM, but I could definitely see that artifact being a template - in large part since a template really isn't that different from a stopped VM. Export options handle the "so I've created a VM - now what" situation.

xenserver-vm is intended to clone an existing VM and export it. The expected artifact is a set of VHDs, and the initial use case is for import into a cloud solution using a post-processor.

xenserver-xva is intended to create (import) a VM from an XVA. Other than taking a different source, xenserver-xva and xenserver-iso are semantically identical.

In terms of personal use, I've used xenserver-iso and xenserver-vm, with a reasonable bias to the latter.

Looking at each of your points ....

1. Capturing a template from a running VM isn't objectively wrong, its just that there are far simpler ways of accomplishing that than a packer workflow. I could see more value in attempting to "remove uniqueness" from a running VM, in which case I'd argue for format: template as an option. So I think you've convinced me there's no reason to error out in xenserver-vm.
2. I could see sr_name sticking around with a format: template option. That way you can specify which SR things should end up on. nfs_mount and output_directory are both related to the quick export of VHD files (need for importation into clouds), and aren't relevant to snapping a template. Net of this, if the intent is to create a template, you'd probably want to pre-create the SR using whatever SR type you like without being forced down an NFS path.
3. If you're wanting to import a template into a second XenServer pool, then you're going to want XVA format. It's possible with VHD files, but non-trivial. From a packer workflow, what I'd expect to see is a builder to create things, and a post-processor which imports into production. The hand-off between building and production could be in XVA or any other format.

btw, the quick export NFS hacks I mentioned are relevant when VMs get large. Without the NFS hacks, you'd have to rely on actually exporting the VDIs from XenServer, and that's a lengthy process (e.g. export in XenCenter time). With the NFS hacks, you have far fewer copy operations on the VHD.

-tim