On 08/19/2013 04:26 PM, René Koch wrote:
-----Original message-----
> From:Greg Padgett <gpadgett(a)redhat.com>
> Sent: Monday 19th August 2013 21:16
> To: René Koch <r.koch(a)ovido.at>
> Cc: ovirt-users <users(a)ovirt.org>
> Subject: Re: [Users] Linux sysprep
>
> On 08/19/2013 10:17 AM, René Koch (ovido) wrote:
>> Hi,
>>
>> Has anyone an idea what's the easiest way to sysprep Linux (CentOS 6 and
>> RHEL 6) machines?
>>
>> The use case is the following: I want to create a lot of virtual
>> machines (e.g. 100) by cloning from one template.
>> So I create a master vm, create a template and a pool with 100 vms
>> assigned to it and set all 100 vms to prestarted.
>>
>> The problem is now, that when I run "sys-unconfig" before creating the
>> template, which does a "touch /.unconfigured" I have to go through the
>> sysconfig-tui and set a new root password for all 100 hosts.
>>
>> So what I'm looking for is a script like the sysprep tool for windows
>> which sets parameters for me automatically.
>> I only need to change:
>> * Hostname + set DHCP_HOSTNAME in ifcfg-eth0 (Hostname == Pool-VM-Name)
>> for some dhcp/ddns magic :)
>> * Clear udev network-rules
>> * remove SSH-Keys
>> * Remove RHN ID and join Satellite/Spacewalk-server
>> * root-password,... should stay the same
>>
>> My first question is: does oVirt provide such a functionality for Linux
>> guest out-of-the-box? I couldn't find one.
>>
>>
>> I think I could solve this with virt-sysprep and virt-file, but I'm
>> unsure if I can use it with oVirt (or only with plain libvirt):
>>
http://libguestfs.org/virt-sysprep.1.html
>>
http://libguestfs.org/virt-edit.1.html
>>
>> For this tools it's required that the vm is not running, as it changes
>> files on the disk. If I'm using a before-vm-start hook, it should be
>> save to access the disk and change content with virt-sysprep/virt-file,
>> right?
>> But do I have access to the disk in a before-vm-start hook?
>> If using NFS storage I should be able to access all disks on the
>> NFS-share, but for iSCSI/FC-LUNS - are they available on the hypervisor
>> in this stage?
>>
>>
>> Another option would be to write a custom script which is started during
>> boot and disables itself after successful run (in the same way as
>> firstboot - I already have such a script for RHN Satellite/Spacewalk
>> joins). The problem here is: How do I get the (oVirt) name of this vm
>> (would need something like virt-whoami :) )? Is the (internal oVirt) ID
>> of this vm stored somewhere in the filesystem of this vm? I don't think
>> so....
>>
>>
>> Thanks a lot for suggestions,
>> René
>>
>
> Hi René,
>
> You may be able to accomplish at least some of what you want using
> Cloud-Init, some features of which we've integrated into oVirt [1]. It
> went in recently so may not be in whichever version you're running, but
> you can probably borrow some of the concepts to get the job done.
Thanks a lot for your answer - this definitely points me into the right way.
Great, happy to help.
>
> Just a few ideas:
> - create a vm payload [2] and attach it to the VM which can hold your
> config info e.g. vm name, which a custom script could pick up. No need
> for the latest oVirt with this option.
For some strange reason I totally missed the vm payload feature (and it seems to be
introduced already in oVirt 3.1 according to the release notes).
Can I attach a vm payload via webadmin portal of oVirt 3.2 (and if yes - how?) or only
via REST-API?
So if I understand this right, I would do the following:
- use before_vm_start_hook which creates the payload and updates vm xml definition - add
<payloads> with e.g. file name "unattended.txt" andcontent
"hostname=pool-vm95"
- have script started in host which mounts the floppy, reads the content of
unattended.txt and do some magic
Only REST API. It sounds like you're on the right track with it.
> - create a Cloud-Init config disk yourself and attach it as a payload,
> and let Cloud-Init do the initialization. There are several formats;
> oVirt uses Config-Drive-v2. Example at [3]. Depending on the config disk
> format, you may need the latest oVirt/vdsm to assign a volume label to the
> vm payload.
> - use the latest oVirt and its Cloud-Init functionality; for fields not
> handled, attach a file and let a script handle it.
cloud-init sounds very interesting, but this requires oVirt 3.3, right?
I'm running oVirt 3.2 at the moment.
Yeah, 3.3 for the integrated features. You could use it standalone in
3.2, i.e. attach a config disk you made yourself--but compared to the
approach above, the effort might not be worth it considering what you want
to accomplish.