RFC: add built-in support for kvm devices to -virtual kernels
smoser at ubuntu.com
Wed Jan 20 17:20:44 GMT 2010
I've been working on a blueprint  to make our uec images boot in ec2
and in UEC without a ramdisk. In our server team meeting today (minutes
) we discussed bug 494565 .
The kernels used by UEC and EC2 come from linux-image-virtual and
linux-image-ec2 . As linux-image-ec2 is not used anywhere except for EC2,
it isn't of general concern. The -virtual kernel is a 'sub-flavour' of
'-generic-pae' on i386 and '-server' on amd64. As such, changes to its
config spread beyond the "server" and "virtual" realm.
To accomplish ramdiskless boot in UEC, we will need built in support
for the kvm provided hardware in -virtual. Logically, it seems to makes
sense for a kernel named '-virtual' to have good support hardware
available to virtual machines.
To do so, I would like to propose the following changes to the
-generic-pae and -server kernels:
KVM Guests launched from within UEC utilize the '-drive if=scsi' option
of kvm. This is the driver for that kvm provided hardware. It is
currently built as a module. Building it into the kernel could cause
problems on hardware that currently has 'blacklist sym53c8xx'
I really have little experience with this hardware and am looking for
insight from anyone who has some experience. There are some (but few)
google hits for 'blacklist sym53c8xx'.
These 2 are not required for UEC boot, but seem to me to be logical in a
'-virtual' kernel. VIRTIO_BLK would be required for ramdiskless boot if
UEC were to start using '-drive if=virtio', which could give performance
improvements. VIRTIO_NET, i would consider to be only a wishlist item,
but obviously it is very useful to have a network driver built in for
I lumped these together because I don't think that either would likely
have negative side effects as they are designed for specific "hardware".
If we decide that CONFIG_SCSI_SYM53C8XX_2=y is too risky, then our options
1.) drop the ramdiskless boot from uec
2.) move '-virtual' from being a 'sub-flavour' to a full 'flavour' build.
I'm hoping that there is generally no strong reason to not include all of
A,B, and C above. Does anyone have thoughts?
More information about the ubuntu-devel