Re: [Qemu-devel] ahci drive: how to make it non-bootable?

[Michael Tokarev]

On 09.05.2012 12:02, Gleb Natapov wrote:
> On Tue, May 08, 2012 at 09:56:10PM +0400, Michael Tokarev wrote:
[]
>>> It's two only:
>>>   -drive if=none,id=<name>,...
>>>   -device virtio-blk-pci,drive=<name>
>>
>> Ok, at least it is not entirely insane :)

> That's the way you suppose to do that. Does it work if you specify
> bootindex for virtio this way? If it does then use it. Restoring
> deprecated hacks is not the way to deal with it. If it does not, then
> it is a bug that should be fixed.

Using the "too verbose" version is, well, difficult to type, when
you have to start many guests - eg, testing etc.  That's why I think
that 3 options for ahci drives is somewhat insane.

Technically there is no problem at all at combining, eg, -netdev and
-device rtl8139, in the same way as current -drive file=foo,if=bar
works, and it is MUCH easier to type and hence is MUCH user-friendly.
And much less error-prone, too.

I think it'd be a good solution to allow bootindex and some other
options to be recognizable in context of, eg -drive with if!=none,
by combining options recognizable from if= with the ones recognizable
by -drive.  Ditto for -netdev..-device: let -netdev to recognize
model=, and allow model-specific (e1000|8130|virtio-net-pci|whatever)
to be recognized as well.  This way there will be no need to specify
id=foo and netdev=foo, the command line will be shorter and also more
understandable.

Please don't say that the only sane option to start qemu guests is
to use libvirt.  Qemu has its great value exactly because it allows
starting guests from command line, which is well-scriptable.

The old hacks which were prematurely removed from qemu-kvm makes the
life easier for the _user_, which is the main target of the software.
I'd love to stop using them but sometimes it is not possible.  With
this extboot thing, qemu-kvm dropped ability to boot from SCSI for
example, and it turns out there are quite some users of this interface
exists - despite the fact SCSI is broken, there is a proprietary
bootrom exists etc -- we just broke users setups without providing
viable alternative, which, to my view, is unacceptable.

Thanks,

/mjt