On 9/14/18 5:41 PM, Marek Marczykowski-Górecki wrote:
On Fri, Sep 14, 2018 at 05:21:17PM -0600, Jim Fehlig wrote:
On 8/5/18 3:48 PM, Marek Marczykowski-Górecki wrote:
Handle PVH domain type in both directions (xen-xl->xml, xml->xen-xl).
And add a test for it.
Signed-off-by: Marek Marczykowski-Górecki <marma...@invisiblethingslab.com>
---
Does domain_conf.c (virDomainDefFormatInternal) still need to silently
convert VIR_DOMAIN_OSTYPE_XEN to VIR_DOMAIN_OSTYPE_LINUX? In case of
PVH, VIR_DOMAIN_OSTYPE_LINUX was never reported as a valid option...
I'd prefer that we switch to formatting type as VIR_DOMAIN_OSTYPE_XEN
See discussion on patch 1/10...
Opps, I thought I had already replied to this but apparently not. Let me try
again...
I guess it is possible to extend the hack in virDomainDefFormatInternal to also
check for def->os.machine == "xenpv" before converting to VIR_DOMAIN_OSTYPE_LINUX.
and
indicating PV vs PVH with the machine attribute.
It's already here.
Yes, I know :-).
For back compat we'd need
to continue accepting <type>linux</type> when parsing XML. Other than a lot
of changes to test suite data files, am I overlooking compatibility problems
with such a change?
Still accepting <type>linux</type> obviously must stay. But if we change
what is reported when formatting XML, it may cause:
- unexpected configuration change, confusing to the user (no manual
change, but XML is different)
And I think this is the reason for danpb's objection.
- that XML may not load on very old libvirt versions (I can't find
exactly which one, but older than 0.7.2, which was almost 10 years
ago)
Personally I don't think either of this is a problem.
I agree that libvirt producing different guest XML after an update is not
appealing. But I do think we can extend the existing hack in
virDomainDefFormatInternal.
Regards,
Jim
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
