On 12/14/2015 01:05 PM, John Snow wrote: > I was actually contemplating re-spinning this for a v3: > > Instead of having a "typeA" and "typeB" properties of the FDC, I'll just > spin the properties in such a way that they write directly to > FDCtrl.drives[n].drive, which avoids the need for two new members and a > method designed to "fetch" the default from the controller. > > I also want to add a "fallback" member to the FDC as a CLI configurable > parameter such that when using "auto" you can configure directly what > type of drive you'll get. > > This way the default behavior will be "auto" (but configurable) and the > fallback if the drive is empty or it cannot make a confident guess will > be whatever the user chose as "fallback" -- presumed "144" before this > series and "288" afterwards. > > I believe this also opens up the possibility for having "fallback" > default to "144" for machine types created prior to 2.6 ... I think. > (I'm less familiar with machine compat code as of yet.) > > Sound reasonable?
On paper, yes that sounds reasonable. I'm also not familiar enough with machine types to know if it will let you keep 2.5 and earlier machines with a fallback of 144, and newer machines with a fallback of 288, but sounds promising. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
