Fabian Freyer wrote:
> >
> > Extra break;
> >> + break;
> >> + case 'I':
> >> + /* While this flag was deprecated in FreeBSD r257423, keep checking
> >> + * for it for backwards compatibility. */
> >> + def->features[VIR_DOMAIN_FEATURE_APIC] = VIR_TRISTATE_SWITCH_ON;
> >> + break;
> >> + case 'u':
> >> + if ((caps & BHYVE_CAP_RTC_UTC) != 0) {
> >> + def->clock.offset = VIR_DOMAIN_CLOCK_OFFSET_UTC;
> >> + } else {
> >> + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
> >> + _("Installed bhyve binary does not support "
> >> + "UTC clock"));
> >> + goto error;
> >> + }
> >
> > I'm wondering if it actually makes sense to throw an error here? I mean,
> > if a user had this flag, most likely it's supported by that bhyve binary
> > and in unlikely case if it's not, there will be an error thrown anyway,
> > but at the later stage.
>
> True, but why not? I'm guessing a potential use case for this might not just
> be using native command strings from the same host, but I may be mistaken.
This way we actually do the same job twice (because we're required to do
this when starting a domain anyway).
I think we should not try to be very smart here and just try to parse
as much args as we know to build a complete XML.
Also, we cannot even be sure what user is going to do with this XML,
maybe they'll run it on some other hosts with different caps. So I think
we need to leave caps check to the start code and don't do it twice.
Roman Bogorodskiy
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list