Launchpad has imported 9 comments from the remote bug at https://bugzilla.redhat.com/show_bug.cgi?id=1644848.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2018-10-31T17:18:42+00:00 poc wrote: Description of problem: An existing VM (running Fedora 28) will not start in F29. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1.Attempt to run a VM created under F28, using Virtual Machine Manager 2.Fail 3. Actual results: Error starting domain: internal error: process exited while connecting to monitor: 2018-10-31T17:12:46.079682Z qemu-system-x86_64: can't apply global IvyBridge-IBRS-x86_64-cpu.osxsave=on: Property '.osxsave' not found Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/asyncjob.py", line 75, in cb_wrapper callback(asyncjob, *args, **kwargs) File "/usr/share/virt-manager/virtManager/asyncjob.py", line 111, in tmpcb callback(*args, **kwargs) File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 66, in newfn ret = fn(self, *args, **kwargs) File "/usr/share/virt-manager/virtManager/domain.py", line 1344, in startup self._backend.create() File "/usr/lib64/python3.7/site-packages/libvirt.py", line 1080, in create if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self) libvirt.libvirtError: internal error: process exited while connecting to monitor: 2018-10-31T17:12:46.079682Z qemu-system-x86_64: can't apply global IvyBridge-IBRS-x86_64-cpu.osxsave=on: Property '.osxsave' not found Expected results: VM working as before Additional info: Guest is a basic F28 server with no GUI and has worked correctly before updating the host to F29. Reply at: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1825195/comments/0 ------------------------------------------------------------------------ On 2018-10-31T17:22:57+00:00 berrange wrote: The "osxsave" property was removed from QEMU upstream as it was never actually exposed to the guests. I expect that your existing guest has this CPU flag encoded in its XML config, as it was a previously supported flag. Fixing it should be as simple as "virsh edit $guest" as root and delete the mention of "osxsave" feature flag. Newly provisioned guests shouldn't get given this flag in the first place, only upgraded guests will suffer. Reply at: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1825195/comments/1 ------------------------------------------------------------------------ On 2018-10-31T21:12:35+00:00 poc wrote: (In reply to Daniel Berrange from comment #1) > The "osxsave" property was removed from QEMU upstream as it was never > actually exposed to the guests. > > I expect that your existing guest has this CPU flag encoded in its XML > config, as it was a previously supported flag. > > Fixing it should be as simple as "virsh edit $guest" as root and delete the > mention of "osxsave" feature flag. > > Newly provisioned guests shouldn't get given this flag in the first place, > only upgraded guests will suffer. That solved it, thanks. Curiously, a Windows 10 guest, also inherited from F28, does not have this problem as the osxsave feature was not set. I've no idea why. Reply at: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1825195/comments/2 ------------------------------------------------------------------------ On 2018-11-01T10:19:32+00:00 berrange wrote: Maybe the problematic guest was in fact installed under an even earlier Fedora release than the Windows guest ? In any case, while this is a genuine problem, I don't think we're going to try todo anything to automagically remove the flags on upgrade, so i'm moving this to WONTFIX. Reply at: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1825195/comments/3 ------------------------------------------------------------------------ On 2018-11-01T10:56:35+00:00 poc wrote: (In reply to Daniel Berrange from comment #3) > Maybe the problematic guest was in fact installed under an even earlier > Fedora release than the Windows guest ? > > In any case, while this is a genuine problem, I don't think we're going to > try todo anything to automagically remove the flags on upgrade, so i'm > moving this to WONTFIX. In fact it's the oher way round. The Windows guest was installed over a year ago. The Fedora guest is only a couple of months old at most. Reply at: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1825195/comments/4 ------------------------------------------------------------------------ On 2019-01-04T12:23:55+00:00 poc wrote: (In reply to Patrick O'Callaghan from comment #4) > (In reply to Daniel Berrange from comment #3) > > Maybe the problematic guest was in fact installed under an even earlier > > Fedora release than the Windows guest ? > > > > In any case, while this is a genuine problem, I don't think we're going to > > try todo anything to automagically remove the flags on upgrade, so i'm > > moving this to WONTFIX. > > In fact it's the oher way round. The Windows guest was installed over a year > ago. The Fedora guest is only a couple of months old at most. FYI an attempt to create a new VM triggered this error again. Since the VM XML file was never created, I had to track down the offending line in /usr/share/libvirt/cpu_map/x86_features.xml and remove it. Reply at: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1825195/comments/5 ------------------------------------------------------------------------ On 2019-01-05T12:57:07+00:00 poc wrote: (In reply to Patrick O'Callaghan from comment #5) > (In reply to Patrick O'Callaghan from comment #4) > > (In reply to Daniel Berrange from comment #3) > > > Maybe the problematic guest was in fact installed under an even earlier > > > Fedora release than the Windows guest ? > > > > > > In any case, while this is a genuine problem, I don't think we're going to > > > try todo anything to automagically remove the flags on upgrade, so i'm > > > moving this to WONTFIX. > > > > In fact it's the oher way round. The Windows guest was installed over a year > > ago. The Fedora guest is only a couple of months old at most. > > FYI an attempt to create a new VM triggered this error again. Since the VM > XML file was never created, I had to track down the offending line in > /usr/share/libvirt/cpu_map/x86_features.xml and remove it. Removing the line from /usr/share/libvirt/cpu_map/x86_features.xml didn't fix the problem. I'm still getting a complaint about .osxsave so presumably it's being set somewhere else. Reply at: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1825195/comments/6 ------------------------------------------------------------------------ On 2019-01-06T21:45:14+00:00 crobinso wrote: Reopening. Patrick can you provide: * full virt-manager --debug output from app startup to reproducing the bug * /var/log/libvirt/qemu/$vmname.log , for the VM name you are trying to create * output of: sudo virsh domcapabilities Reply at: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1825195/comments/7 ------------------------------------------------------------------------ On 2019-01-07T11:16:30+00:00 poc wrote: (In reply to Cole Robinson from comment #7) > Reopening. Patrick can you provide: > > * full virt-manager --debug output from app startup to reproducing the bug > * /var/log/libvirt/qemu/$vmname.log , for the VM name you are trying to > create > * output of: sudo virsh domcapabilities On a second attempt, the error refuses to show itself. I tried both with and without the change to /usr/share/libvirt/cpu_map/x86_features.xml and it made no difference. I can only assume it's because I rebooted after some system updates (though these were not to qemu or libvirt directly). Now on kernel 4.19.13-300.fc29.x86_64 if it matters. Sorry for the noise. I'll come back to this if it happens again. Reply at: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1825195/comments/8 ** Changed in: qemu (Fedora) Status: Unknown => Won't Fix ** Changed in: qemu (Fedora) Importance: Unknown => Undecided -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1825195 Title: qemu lost osxsave feature bit (ok) which might cause upgrade issues (not so ok) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1825195/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
