RFC: add built-in support for kvm devices to -virtual kernels
Dustin Kirkland
kirkland at canonical.com
Thu Jan 21 03:07:11 GMT 2010
On Thu, Jan 21, 2010 at 6:20 AM, Scott Moser <smoser at ubuntu.com> wrote:
> Hello all,
> I've been working on a blueprint [3] to make our uec images boot in ec2
> and in UEC without a ramdisk. In our server team meeting today (minutes
> [1]) we discussed bug 494565 [2].
> 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:
> A.) CONFIG_SCSI_SYM53C8XX_2=y
> 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'.
>
> B.) CONFIG_VIRTIO_BLK=y
> C.) CONFIG_VIRTIO_NET=y
> 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
> support.
> 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
> are
> 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?
No opinion on A, but I strongly support B & C. I have been doing the
vast majority of KVM testing on virtio disk and networking for several
releases now. The performance is spectacular in comparison to
non-virtio (10x in many cases). It's definitely the way we should be
going.
:-Dustin
More information about the ubuntu-devel
mailing list