I am running one of the RPM Fusion builders in a VM using CentOS and after I saw that the newly created VMs on my notebook are using virtio for network and disk access I thought that I will try this also for my builder VM. It was pretty easy and straight forward.
First I had to update from CentOS 5.2 to CentOS 5.4 so that the virtio drivers are available. After that I was just following http://wiki.libvirt.org/page/Virtio.
For the network:
- shut down the VM
- edit the XML and add <model type='virtio'/> to the network section
- start the VM
- done
For the disk:
- create a new ramdisk with the virtio drivers: mkinitrd --with virtio_pci --with virtio_blk -f /boot/initrd-$(uname -r).img $(uname -r)
- or dracut -f --add-drivers "virtio_pci virtio_blk" /boot/initrd-$(uname -r).img $(uname -r) for Fedora 12
- change /boot/grub/device.map from “(hd0) /dev/hda” to “(hd0) /dev/vda“
- using LVM requires no changes to the root= parameter in /etc/grub.conf
- shut down the VM
- edit the XML changing <target dev='hda' bus='ide'/> to <target dev='vda' bus='virtio'/>
- start the VM
- done
During the boot of the VM I can now see that it is loading the virtio disk drivers and detecting vda1 and vda2. Using lspci and lsmod I can also verify that the new virtio devices are available and also used. The VM seems to be faster but I have not actually benchmarked it.
On the last day of the last year (2009-12-31) both RPM Fusion’s mirrorlist server were most of the time not reachable. The problem started at 00:53 (UTC) and it was at least going on until 16:00 (UTC). Both mirrorlist servers have been on the same network and the router for that network broke down. If it would have been the link to our provider the router had a backup route to stay on-line, but this time it actually hit the single point of failure – and everything was off-line. See: error report of the provider (german).
I was never happy that both mirrorlist server were running in the same network and I especially wanted to get the mirrorlist server off my mirror server. Thanks to Patrick I have now access to another VM at a different provider where I am running a new mirrorlist server instance. It does not require much in terms of resources and bandwidth, but having root access makes everything so much easier.
RPM Fusion’s mirrorlist server are now two dedicated VMs at two different providers and that should protect the functionality from failures like the one on 2009-12-31.
RPM Fusion now also has a MirrorManager instance running. I have written some minimal documentation about RPM Fusion’s MirrorManager setup but it is pretty much the same as already documented for Fedora. It took me a few days to understand how all the different parts of the MirrorManager are working together, but I think I have now a pretty good overview how it all works. Matt has really written a nice piece of software and he accepted all my patches. My patches were mostly getting rid of hardcoded Fedora URLs and putting Fedora specific stuff in configuration files.
The public mirror list can be accessed here: http://mirrors.rpmfusion.org/mm/publiclist/
The mirrorlist which is generated for yum can be accessed here: http://mirrors.rpmfusion.org/mirrorlist?…
To provide at least some kind of “high” availability mirrors.rpmfusion.org consists of two hosts. One is run by me and the other is provided by Oliver.
The MirrorManager database web interface is running at https://lisas.de/mm/. The reason for not running it under the rpmfusion.org domain was that I have signed SSL certificate for lisas.de and because it transmits a user name and password I wanted it to run over an encrypted connection. But as only mirror admins have to use that interface it should cause not too much confusion for the users of RPM Fusion.
I am using the information from the mirrorlist accesses to generate some statistics about the countries where RPM Fusion is used as well as statistics about the usage of the repositories and architectures: http://mirrors.rpmfusion.org/statistics/