Ubuntu
virt-manager package

Afer upgrading "libvirt-bin" to 0.9.8-2ubuntu17.1 to virsh cannot identify machine after reboot

Bug #999681 reported by FlorianOtel
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
libvirt (Ubuntu)
Expired
Undecided
Unassigned
virt-manager (Ubuntu)
Expired
Medium
Unassigned

Bug Description

Hi all,

First a bit of disclaimer. I'm a bit of newcomer to libvirt-bin / qemu etc. so appologies if this is not as crisp / clear as it may need to. TIA for your patience.

My problem: I normally use "virt-manager" to manage my VMs. After installing Ubuntu 12.04 and performing the suggested upgrade of "libvirt-bin" to version "0.9.8-2ubuntu17.1" I just discovered the VMs "disappear" after a reboot. "virt-manager" is at version 0.9.1-1ubuntu5

The connection in virt-manager / URI in virsh is "qemu:///system"

After further investigation it seems that the XML file for the VM is indeed still present in "/etc/libvirt/qemu" but a "virsh list --all" does not identify the machine.

All processes are run as roon. Not exactly sure how/why that VM definition is lost during a reboot. Cannot say what the behavior was prior to upgrading "libvirt-bin" i.e. in vanilla 12.04

Thanks,

Florian

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

Thanks for reporting this bug.

Can you say specifically, step by step, how you created the VMs?

Can you still create new machines (which presumably disappear) or does virt-manager now completely refuse to connect to the local libvirtd?

Are libvirt and virt-manager on the same machine?

affects: libvirt (Ubuntu) → virt-manager (Ubuntu)
Changed in virt-manager (Ubuntu):
status: New → Incomplete
importance: Undecided → Medium
Changed in libvirt (Ubuntu):
status: New → Incomplete
Revision history for this message
FlorianOtel (florian-otel) wrote :

Thanks for the prompt reply.

I create the VMs in virt-manager by pointing to previous images (raw, qcow2 -- both work) I have on my disk --all works as expected.

The VMs are consistent acrosss different "virt-manager" sessions i.e. if I exit then re-enter virt-manager VM is still there (but w/o rebooting)

Creation and deletion of VMs in virt-manager (tested as above) works fine.

It's just that across reboots the only thing I have left ( is an "orphaned" XML file of the (old) VM in "/etc/libvirt/qemu" directory. virt-manager doesn't show the VM, nor "virsh list --all" finds it.

In the mean time I find a (temporary work around) that seems to work across reboots:

1) Create "VM" as above
2) Copy the "VM.xml" definition to another file e.g "VM-new.xml"
3) Edit "VM-new.xml" and change <name>VM</name> to <name>VM-new</name>
4) virsh define VM-new.xml

(outputs an innocent error message wrt the domain)

After that, the "VM-new" is persistent across reboots, but shown with the old name (i.e. "VM") in virt-manager,.

Also, if I try in virsh to do

virsh define OprhanedVM.xml

(for an "OrphanedVM" -- VM orphaned as per above sequence), I get:

error: Failed to define domain from OrphanedVM.xml
error: (domain_definition):4: Comment not terminated
<!--
WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES
  virsh edit OrphanedVM.qcow2
-------------------------^

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

That's nutty :)

While the VM is shown as running in virt-manager, can you do:

(as non-root user)
groups
sudo virsh -c qemu:///system list --all
sudo virsh -c qemu:///session list --all

Then for any results you get,

sudo virsh -c qemu:///system dumpxml VM

(or qemu:///session if that is where they showed up) ?

Can you also post your /etc/libvirt/libvirtd.conf?

Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for libvirt (Ubuntu) because there has been no activity for 60 days.]

Changed in libvirt (Ubuntu):
status: Incomplete → Expired
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for virt-manager (Ubuntu) because there has been no activity for 60 days.]

Changed in virt-manager (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.