[Users] Linux sysprep

René Koch (ovido) r.koch at ovido.at
Wed Aug 21 07:25:09 EDT 2013


On Mon, 2013-08-19 at 16:54 -0400, Greg Padgett wrote:
> On 08/19/2013 04:26 PM, René Koch wrote:
> >
> > -----Original message-----
> >> From:Greg Padgett <gpadgett at redhat.com>
> >> Sent: Monday 19th August 2013 21:16
> >> To: René Koch <r.koch at ovido.at>
> >> Cc: ovirt-users <users at 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.


I'm just playing around with the payload feature but I can't access the
cd/floppy in my vm.
I adapted Yuriy's script
(http://lists.ovirt.org/pipermail/users/2013-June/014907.html - which is
working fine btw) to create payload xml content and write it with
hooking.write_domxml(domxml).

In vdsm.log I can see that my python script exits with status code 0 and
that the content seems to be added to the vm definition:

Thread-130844::DEBUG::2013-08-21
12:43:52,669::libvirtvm::1520::vm.Vm::(_run)
vmId=`79dc3123-4584-4dd9-b0f0-c28ede13d672`::<?xml version="1.0"
encoding="utf-8"?><domain type="kvm">
	<name>centos6</name>
....snip....
	</cpu>
<payloads><payload type="cdrom"><file
name="unattended.txt"><content>hostname:
centos6</content></file></payload></payloads></domain>


But in my vm I can't mount the cd drive:
# mount /dev/sr0 /media
mount: you must specify the filesystem type

Is there a special filesystem I have to specify?

Furthermore shouldn't I be able to see the payloads content added to
this vm via REST-API? Because I can't.

Maybe I'm doing some wrong?


Thanks,
René



> 
> >
> >
> >>    - 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.
> 
> >
> > Regards,
> > René
> >
> >
> >>
> >> HTH,
> >> Greg
> >>
> >> [1] http://www.ovirt.org/Features/Cloud-Init_Integration
> >> [2] http://www.ovirt.org/Features/VMPayload
> >> [3]
> >> http://docs.openstack.org/trunk/openstack-compute/admin/content/config-drive.html
> >>
> >>
> 



More information about the Users mailing list