----- "AutoQA" trac@fedorahosted.org wrote:
#182: Write virt management script -----------------------------+---------------------------------------------- Reporter: kparal | Owner: Type: task | Status: new Priority: major | Milestone: Virtualization Component: infrastructure | Version: 1.0 Resolution: | Keywords: -----------------------------+---------------------------------------------- Comment (by jlaska):
I was curious how this might work, so I've modified the script supplied by mmcgrath (slightly newer than what is attached to ticket#128).
Basically, I started by creating master guests for each of the stable system configurations
- f13-i386-master
- f13-x86_64-master
- f12-i386-master
- f12-x86_64-master
- f11-i386-master
- f11-x86_64-master
These systems are tuned and adjusted as desired. They are intended as the master copies used for all subsequent guests. They'll be updated at some pre-defined interval (daily, weekly etc...).
- Updated packages: {{{yum update}}}
- Removed system-specific udev net rules: {{{rm
/etc/udev/rules.d/70 -persistent-net.rules}}}
- Handle other system-specific details - ssh keys,
/etc/sysconfig/network, /etc/sysconfig/network-scripts/ifcfg-eth0
Next, I use the attached script to create a slave guests using a specified ''release'' and ''arch''. The script will creates an LVM snapshot of the specified master image, then creates and boots a virt slave using the LVM snapshot. For example ... {{{ # bash create-virt-slave.sh -r f13 -a i386
Using slave guest name 'f13-i386-slave-1' One or more specified logical volume(s) not found. Creating LVM snapshot - f13-i386-slave-1 ... Logical volume "f13-i386-slave-1" created Creating virt guest using /var/tmp/quickguest.Ddr3CAr1/f13-i386-slave-1.xml ... Domain f13-i386-slave-1 created from /var/tmp/quickguest.Ddr3CAr1/f13-i386-slave-1.xml
Slave 'f13-i386-slave-1' created. Use 'virsh console f13-i386-slave-1' to connect to guest. }}}
This seems like it would satisfy the need for a quick'n'dirty guest management. There is still some work needed with the script. For example,
- The script attaches to the guest console to record it to a log
file. In production, this is probably fine, but for testing, it breaks using {{{virsh console slave}}}
- I'd really like to get this setup so that slaves use a fresh LVM
snapshot on boot. Without this, we run the potential of a test corrupting the snapshot. This still offers some level of protection over a bare- metal setup, we just re-run the ''create-virt-slave.sh'' script. However, it would be handy if the slaves would use a new snapshot on each boot. We can then rely on autotest rebooting the system after each test run (thus cleaning the system).
Hope this helps!
Wow, that seems like a great start. Thanks, James!