| Summary: | Libvirt XEN driver doesn't send the <os><type machine="xxx" arch="xxx"></os> | ||
|---|---|---|---|
| Product: | [Community] Virtualization Tools | Reporter: | Antoine Mercadal <antoine.mercadal> |
| Component: | libvirt | Assignee: | Libvirt Maintainers <libvirt-maint> |
| Status: | CLOSED DEFERRED | QA Contact: | |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | unspecified | CC: | berrange, crobinso, franck.villaume, jon, xen-maint |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-03-23 12:52:58 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
Hi Antoine, Thanks for the bug report. I don't have time to look at this in detail ATM, but the relevant code is in domain_conf.c at line 9625 in today's git head (commit id ecfbf79541c76a884b25af6b022b601570f39b25). If you are willing to submit a patch to the upstream list, we'd much appreciate it. Dave okay. I'm on it even if it's been a while I haven't do any C :) It seems that it's a bit more complicated than I thought. Actually, the problem seems to come from xenParseSxpr() function in xen_sxpr.c. Following the execution, I finally reach this file, and this is where it seems libvirt gets informations from xend. Then I thought, "all right, with luck, someone forgets to store machine and arch in virDomainDefPtr". But actually these informations seem to be absent from what xend returns. So I'm not sure I can do anything. Any clue ? So at xen_sxpr.c line 1079, it's not getting back what it expects? Can you attach the output from xend? There is a backwards compatibility issue in here. When libvirt was first written, we mistakenly returned 'linux' for the paravirt guest OS type instead of 'xen'. Unfortunately, we have to preserve that behaviour when generating XML for output. When parsing XML for input we accept 'linux' or 'xen' as OS types for paravirt guests. For fully virt guests, 'hvm' on input should always return 'hvm' on output. The fact that you suggest 'hvm' (fullvirt) turns into 'linux' (paravirt) seems like a bug, if it is really happening that way. It seems to really happens this way. But the real for me problem is the absence of the "arch" attribute. The type can be guessed with the machine (not perfect but it should be ok for now) Any update on this topic ? as I understand the type flag can stay here, but the arch attribute is missing and it's a blocking bug. I'd like to see this fixed too, it would speed up some development work I'm interested to use at work. Sorry this never received much of a response. I suspect the root issue may have been that machine=xenpv was specified, which told xen to make a PV guest, which was then reported back to libvirt. Either way things have changed a lot since then so I suspect it was fixed... if not, please reopen |
Description of problem: When defining a Xen domain with a description XML like : <domain type='xen'> <name>XENTEST</name> <uuid>ab03e04c-9dae-11e0-87bc-0016d4e6adad</uuid> <memory>1048576</memory> <currentMemory>1048576</currentMemory> <vcpu>1</vcpu> <os> <type arch="x86_64" machine="xenpv">hvm</type> </os> [...] </domain> It works great. Then when asking for the description later, we get : <domain type='xen'> <name>XENTEST</name> <uuid>ab03e04c-9dae-11e0-87bc-0016d4e6adad</uuid> <memory>1048576</memory> <currentMemory>1048576</currentMemory> <vcpu>1</vcpu> <os> <type>linux</type> <-------- wrong </os> [...] </domain> Version-Release number of selected component (if applicable): master sha: 6c88f1194cecf9145c3f6acb7dccca90d3385f1e How reproducible: Everytime Steps to Reproduce: 1. Define VM 2. Ask for definition Actual results: wrong os type Expected results: good os type :) Additional info: This is required by Archipel in order to properly build the GUI according to the domain informations.