Friday, September 12, 2014

When your VM gets stuck in suspended mode in Red Hat KVM...

I needed to re-do my network interfaces in KVM - make more bridged Ethernet connection for the VMs to use.  I totally forgot that I had a guest VM running as I began my reboot.  "Suspending SSB2" it says as I panic suddenly realizing what I had done.  It's ok - I've done this before I quickly remember.  It does a great job of automatically suspending and resuming UNLESS YOU JUST HAPPEN TO CHOSE THAT REBOOT TO SCREW UP THE NETWORK CONFIGURATION.

So, it reboots and networking is goofed.  I quickly see what I did, fix and reboot again.  This time it's ok but the SSB2 VM does not start.  I try to start it manually and get the message:

libvirtError: error creating macvtap type of interface: Device or resource busy

Whatever that means.  (It actually means I tried to un-suspend but couldn't talk to the iSCSI network so we're leaving it in limbo).  I google and google and find a lot of folks in the same boat.  They came up with some very iffy and convoluted solutions involving editing multiple XML files, etc.  I follow the threads to the bottom of each.  None of them seem quite right.

New to KVM, I try clonging the non-startable SSB2 and succeed.  It boots and works (requires a lot of network changes, but oh well).

Still not satisfied I see mention of "/var/lib/libvirt/qemu/save/rhel.save"  (it's ssb2.save in my case).  Again some very complicated procedures involving editing multiple XML files, etc. with no guaranteed results by the author.

Since I have a working clone, I figure "What the heck!  I'll just delete "/var/lib/libvirt/qemu/save/ssb2.save" and try starting.  It worked!  -Except for one snag - I already had an exact doppleganger running.  It locked up my virt-manager and the server hard.  After, rebooting all was well.

This worked for me.  On a TEST system.  Use at your own risk.

No comments: