Anyone doing libvirt template provisioning with Foreman?

According to the 1.5 release notes there is support for libvirt/kvm
provisioning via template, yet the documentation is sparse. I using
virt-sysprep I have created an image and I can create a full vm pretty
quickly using the webvirtmgr front end.
I can connect it to puppet, but foreman won't manage the compute resource
(that is if I delete the host it will just remove it in puppet).

There's a fragment of information in the wiki:
http://projects.theforeman.org/projects/foreman/wiki/Provision_KVM_VM_without_DHCP

While this does give some more background, it looks like more work than the
template approach I'm currently using.

I don't want to use a libvirt private network I have a bridged network
which connects on the first boot. The ideal solution would be to either
provide the ip address or let dhcp figure it out, make the host from the
template and have a finishing script either assign the static ip or just go
with dhcp.

If this isn't possible I would just like to know how to register the
compute resource with Foreman and I will do either via shell or webvirtmgr
for now.

Also the 1.5 release notes mention that changing the default template can
cause errors with the provisioned vm does this mean this is not building a
new disk from a template?

TIA

> According to the 1.5 release notes there is support for libvirt/kvm
> provisioning via template, yet the documentation is sparse. I using
> virt-sysprep I have created an image and I can create a full vm pretty
> quickly using the webvirtmgr front end.
> I can connect it to puppet, but foreman won't manage the compute
> resource (that is if I delete the host it will just remove it in puppet).

So if you want to provision the VMs through another tool and then manage
them post-provision from Foreman, then you can add a libvirt compute
resource and click the "Associate" button on the CR page to link the
host in Foreman to the VM. Next when you delete the host in Foreman,
it'll delete the VM too.

> There's a fragment of information in the wiki:
> Provision KVM VM without DHCP - Foreman
>
> While this does give some more background, it looks like more work than
> the template approach I'm currently using.

This is describing a variant of the normal kickstart workflow, if you're
looking to template, then this probably isn't relevant.

> I don't want to use a libvirt private network I have a bridged network
> which connects on the first boot. The ideal solution would be to either
> provide the ip address or let dhcp figure it out, make the host from the
> template and have a finishing script either assign the static ip or just
> go with dhcp.

Yeah, if you want to provision templates from Foreman, it needs to know
the IP ahead of time - so either you need to specify it during host
creation and then reserve that on your DHCP server, or use Foreman's
DHCP orchestration.

> If this isn't possible I would just like to know how to register the
> compute resource with Foreman and I will do either via shell or
> webvirtmgr for now.

http://theforeman.org/manuals/1.5/index.html#5.2.1UsingComputeResources
has information about registering your libvirt hypervisor as a compute
resource.

And then Foreman :: Manual
has some information under the image provisioning section about what to
set up (register the image/template in Foreman). Then you'll be able to
select it when creating the host.

http://www.youtube.com/watch?v=1nuwLRirGB0&feature=share&t=51m11s may be
useful too.

> Also the 1.5 release notes mention that changing the default template
> can cause errors with the provisioned vm does this mean this is not
> building a new disk from a template?

The libvirt imaging support uses a copy-on-write technique:

base_image (1GB)
>-- host1.example.com (2MB)
`-- host2.example.com (50MB)

The host images just contain the changes made from the base_image. This
means if the base_image is modified on the file system, the qcow2
copy-on-write gets out of sync.

The best way to manage changes to your base images is probably to
version them and create new hosts on new images.

··· On 12/05/14 05:11, sanderant@gmail.com wrote:


Dominic Cleal
Red Hat Engineering

Thanks Dominic!

>
> > According to the 1.5 release notes there is support for libvirt/kvm
> > provisioning via template, yet the documentation is sparse. I using
> > virt-sysprep I have created an image and I can create a full vm pretty
> > quickly using the webvirtmgr front end.
> > I can connect it to puppet, but foreman won't manage the compute
> > resource (that is if I delete the host it will just remove it in
> puppet).
>
> So if you want to provision the VMs through another tool and then manage
> them post-provision from Foreman, then you can add a libvirt compute
> resource and click the "Associate" button on the CR page to link the
> host in Foreman to the VM. Next when you delete the host in Foreman,
> it'll delete the VM too.
>

Thanks this worked.

> If this isn't possible I would just like to know how to register the

> > compute resource with Foreman and I will do either via shell or
> > webvirtmgr for now.
>
> Foreman :: Manual
> has information about registering your libvirt hypervisor as a compute
> resource.
>
> And then Foreman :: Manual
> has some information under the image provisioning section about what to
> set up (register the image/template in Foreman). Then you'll be able to
> select it when creating the host.
>
> http://www.youtube.com/watch?v=1nuwLRirGB0&feature=share&t=51m11s may be
> useful too.
>
Thanks I registered a template, but I don't see the same provisioning
option that you show in the sprint.
Am I to understand you always need a pxelinux and provisioning template
even if in this case I really only want a finsihing template?

> > Also the 1.5 release notes mention that changing the default template
> > can cause errors with the provisioned vm does this mean this is not
> > building a new disk from a template?
>
> The libvirt imaging support uses a copy-on-write technique:
>
> base_image (1GB)
> >-- host1.example.com (2MB)
> `-- host2.example.com (50MB)
>
> The host images just contain the changes made from the base_image. This
> means if the base_image is modified on the file system, the qcow2
> copy-on-write gets out of sync.
>
> The best way to manage changes to your base images is probably to
> version them and create new hosts on new images.
>
>
OK what I am doing is some sort of cloning, but that process is much
better. I gave up on ovirt because I wanted some sort of resliency if the
whole system fails so I can just extract the img files and move them to
another host. I assume Foreman should be able to do this type of
provisioning too at some point if its authenticating as ssh already so it
can probably run virt-* commands.

··· On Monday, May 12, 2014 4:26:23 AM UTC-4, Dominic Cleal wrote: > On 12/05/14 05:11, sand...@gmail.com wrote:

> Thanks Dominic!
>
>
> And then
> Foreman :: Manual
> <Foreman :: Manual>
> has some information under the image provisioning section about what to
> set up (register the image/template in Foreman). Then you'll be
> able to
> select it when creating the host.
>
> http://www.youtube.com/watch?v=1nuwLRirGB0&feature=share&t=51m11s
> <http://www.youtube.com/watch?v=1nuwLRirGB0&feature=share&t=51m11s>
> may be
> useful too.
>
> Thanks I registered a template, but I don't see the same provisioning
> option that you show in the sprint.
> Am I to understand you always need a pxelinux and provisioning template
> even if in this case I really only want a finsihing template?

You can stick with just a finish template if you're only creating hosts
from images, the PXELinux+provision templates are only needed when
network booting them (PXE).

>
> > Also the 1.5 release notes mention that changing the default template
> > can cause errors with the provisioned vm does this mean this is not
> > building a new disk from a template?
>
> The libvirt imaging support uses a copy-on-write technique:
>
> base_image (1GB)
> >-- host1.example.com <http://host1.example.com> (2MB)
> `-- host2.example.com <http://host2.example.com> (50MB)
>
> The host images just contain the changes made from the base_image.
> This
> means if the base_image is modified on the file system, the qcow2
> copy-on-write gets out of sync.
>
> The best way to manage changes to your base images is probably to
> version them and create new hosts on new images.
>
>
> OK what I am doing is some sort of cloning, but that process is much
> better. I gave up on ovirt because I wanted some sort of resliency if
> the whole system fails so I can just extract the img files and move them
> to another host. I assume Foreman should be able to do this type of
> provisioning too at some point if its authenticating as ssh already so
> it can probably run virt-* commands.

We're using the libvirt API at the moment, even though it's running over
SSH, so the API lets us create hosts with volumes based on other disks.
It does though let us do complete volume cloning, so if you'd prefer
this then please file a feature request and maybe it can be added to the
libvirt CR some time.

··· On 13/05/14 03:31, sanderant@gmail.com wrote: > On Monday, May 12, 2014 4:26:23 AM UTC-4, Dominic Cleal wrote: > On 12/05/14 05:11, sand...@gmail.com wrote:


Dominic Cleal
Red Hat Engineering