Serial ATA Support - will it come?

Serial ATA Support - will it come?

[Andy B.]

Hello List,

I was planning to introduce kvm in our server farm to give customers the
possibility to load their OS into kvm in case they did something wrong and
want to fix that.

We have several 100 servers with different Linux distros, but always the
same hardware and kernel. Our hard drives are SATA who use the AHCI driver.
These disks are named /dev/sdXX in the OS and this is where kvm is failing
on me. It seems that our disks are recognized as IDE drives and named
/dev/hdXX while booting the OS into KVM thus giving me some classic kernel
panics.

My initial line is quite straightforward:

kvm -hda /dev/sda -boot c -net nic,model=rtl8139 -vnc :1

I was told to try SCSI emulation, but this didn't help either, as no disk
was found at all:

kvm -drive file=/dev/sda,if=scsi,boot=on -boot c -net nic,model=rtl8139 -vnc
:1


With /dev/hdaX I cannot really boot into kvm without changing a significant
amount of files per server, and changing almost 1000 servers is not a very
sane option :-)


Has SATA support, especially the generic AHCI devices, ever been considered
to be included into kvm? Would it be a lot of work to add this emulation
into kvm? I certainly don't want to ask for impossible things, but I would
just like to know if in the near future I will be able to boot my images
without changing them. Maybe there is a "hidden" solution that I did not
find, if so, please let me know.

Thanks for your time.


Andy

Re: Serial ATA Support - will it come?

[Charles Duffy]

Let's back up here a bit --

When you say "no disk was found at all" when using SCSI emulation, do 
you mean the kernel booted and was unable to find the hard drives, or 
did it not even get that far?

The SCSI emulation uses the sym53c8xx driver, which was first developed 
against 2.0.36; it's been in the kernel long enough that I'm certain 
whatever kernel you're using supports it (or it wouldn't run a modern 
userland either). I'm guessing you're running a monolithic kernel with 
only the drivers you need compiled in, instead of any vendor kernel (as 
any and every vendor kernel would have this driver available). Frankly, 
if you want to allow your users to boot their machines on other than 
your usual hardware, it's only sensible to have a kernel that supports 
the secondary hardware as well as what you normally provision them -- 
whether this secondary hardware is physical or virtual.

That said, there's a mechanism by which you can cheat: Boot the guest 
with an externally-provided kernel using -kernel and -append options to 
kvm. This isn't ideal -- you're no longer going through the guest's 
bootloader and so lose any settings included there -- but should be good 
enough for a rescue environment.