On Fri, Jan 08, 2021 at 02:50:25AM -0500, Matt Coleman wrote:
> On Nov 26, 2020, at 9:42 AM, Daniel P. Berrangé
<berrange(a)redhat.com> wrote:
>
> You ought to pass def->controllers[i] into this method and validate
> as many properties as practical. At very least validate the model
> and report VIR_ERR_CONFIG_UNSUPPORTED for any you can't emulate.
Hyper-V's SCSI controllers are paravirtualized ("synthetic" in Hyper-V
terms). I've been omitting the model setting from my XML files.
I can think of three options for how to handle this:
1. only support VIR_DOMAIN_CONTROLLER_MODEL_SCSI_DEFAULT
2. support VIR_DOMAIN_CONTROLLER_MODEL_SCSI_DEFAULT and
VIR_DOMAIN_CONTROLLER_MODEL_SCSI_AUTO
3. add VIR_DOMAIN_CONTROLLER_MODEL_SCSI_HYPERV and support
VIR_DOMAIN_CONTROLLER_MODEL_SCSI_HYPERV,
VIR_DOMAIN_CONTROLLER_MODEL_SCSI_DEFAULT, and
VIR_DOMAIN_CONTROLLER_MODEL_SCSI_AUTO
Adding another virDomainControllerModelSCSI seems unnecessary to me
because Hyper-V doesn't support emulating any SCSI controllers; it only
has its paravirtualized SCSI functionality.
Which do you recommend?
IIRC "DEFAULT" is when no model=... is given at all and usually
a driver would expand that into the suitable SCSI controller model
for the guest.
With that in mind I'd suggest (2).
> Probably ought to reject any info->type which is not
> VIR_DOMAIN_ADDRESS_TYPE_NONE, since you're not attempting todo
> any device addressing at this time.
There are no address settings for Hyper-V SCSI controllers, so this
will always be the case. I'll report an error if address settings are
provided.
Thanks!
Matt
Regards,
Daniel
--
|:
https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|:
https://libvirt.org -o-
https://fstop138.berrange.com :|
|:
https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|