[libvirt] 1.4.0 memballoon bug?
Hi, When I run virsh -c qemu:///system domxml-to-native qemu-argv /tmp/qatest.xml from 1.4.0 with the qatest.xml below (which has no memballoon device specified), I get an 'unspecified error'. Some printf debugging shows that virDomainDefParseXML is automatically adding a virtio memballoon device, but that its memballoon->info.type is 0, not the 1 or 8 which is required at qemuBuildMemballoonDevStr(). This didn't happen at 1.2.0, but I'm not sure where the error was introduced, as I don't see any suspicious changes around any of the relevant functions. So I was hoping to send a patch, but for now I'm just asking for help :) Anyone know what might be going on? thanks, -serge
On 05.04.2013 21:22, Serge Hallyn wrote:
Hi,
When I run
virsh -c qemu:///system domxml-to-native qemu-argv /tmp/qatest.xml
from 1.4.0 with the qatest.xml below (which has no memballoon device specified), I get an 'unspecified error'. Some printf debugging shows that virDomainDefParseXML is automatically adding a virtio memballoon device, but that its memballoon->info.type is 0, not the 1 or 8 which is required at qemuBuildMemballoonDevStr().
This didn't happen at 1.2.0, but I'm not sure where the error was introduced, as I don't see any suspicious changes around
You can run git-bisect to find which commit introduced this 'feature' in case it is not obvious from git-log.
any of the relevant functions. So I was hoping to send a patch, but for now I'm just asking for help :) Anyone know what might be going on?
thanks, -serge
Michal
Quoting Michal Privoznik (mprivozn@redhat.com):
On 05.04.2013 21:22, Serge Hallyn wrote:
Hi,
When I run
virsh -c qemu:///system domxml-to-native qemu-argv /tmp/qatest.xml
from 1.4.0 with the qatest.xml below (which has no memballoon device specified), I get an 'unspecified error'. Some printf debugging shows that virDomainDefParseXML is automatically adding a virtio memballoon device, but that its memballoon->info.type is 0, not the 1 or 8 which is required at qemuBuildMemballoonDevStr().
This didn't happen at 1.2.0, but I'm not sure where the error was introduced, as I don't see any suspicious changes around
You can run git-bisect to find which commit introduced this 'feature' in case it is not obvious from git-log.
Yeah I just needed to first git upstream to reliably compile (with patch/unpatch around git bisect operations) git bisect points to: [608512b24a89d9865e402905b2dbbfd1c8a0e83e] S390: QEMU driver support for CCW addresses -serge
Quoting Serge Hallyn (serge.hallyn@ubuntu.com):
Quoting Michal Privoznik (mprivozn@redhat.com):
On 05.04.2013 21:22, Serge Hallyn wrote:
Hi,
When I run
virsh -c qemu:///system domxml-to-native qemu-argv /tmp/qatest.xml
from 1.4.0 with the qatest.xml below (which has no memballoon device specified), I get an 'unspecified error'. Some printf debugging shows that virDomainDefParseXML is automatically adding a virtio memballoon device, but that its memballoon->info.type is 0, not the 1 or 8 which is required at qemuBuildMemballoonDevStr().
This didn't happen at 1.2.0, but I'm not sure where the error was introduced, as I don't see any suspicious changes around
You can run git-bisect to find which commit introduced this 'feature' in case it is not obvious from git-log.
Yeah I just needed to first git upstream to reliably compile (with patch/unpatch around git bisect operations)
git bisect points to: [608512b24a89d9865e402905b2dbbfd1c8a0e83e] S390: QEMU driver support for CCW addresses
That commit appears to make an assumption that qemuDomainAssignAddresses() will have been called if we get to qemuBuildMemballoonDevStr(), but that doesn't appear to be the case when we do domxml-to-native qemu-argv. (a fopen+fprintf at that location isn't being triggered) -serge
participants (2)
-
Michal Privoznik -
Serge Hallyn