[rhelv6-list] KVM issues post RHEL6-1->6.2 update

[Matthias Saou]

On Thu, 08 Dec 2011 10:34:44 -0500
Robin Price II <rprice at redhat.com> wrote:

> On 12/08/2011 04:31 AM, Ben wrote:
> > My questions are:
> >
> > 1) Is it a bad idea to patch the host's libvirtd while guests are
> > running? 2) Should libvirtd have killed the guests like that?
> > 3) With this update to KVM/qemu/libvird are "address type='pci'" now
> > unnecessary and removable from /etc/libvirt/qemu/<domain>.xml files
> > as PCI IDs are now dynamically assigned?
> 
> Ben,
> 
> Sorry to hear your upgrade was a PITA.  :(
> 
> 1) With any patching or upgrading for a KVM host or non-KVM host
> should be done in a maintenance window.  I normally stop all of my
> guests before I fully upgrade my host KVM.  I did this yesterday.
> All guests were off and then I brought up my host machine to
> RHEL6.2.  From there I brought up my RHEL6.1 guest to RHEL6.2.

This is clearly the best practice, but wouldn't have changed much in
this scenario.

> 2) I am not sure what the results would be if I was to upgrade all
> the packages with running guests.  Sounds like your scenario is what
> would happen.  Have you ever upgraded Firefox while running the older
> instance and never relaunching the browser?  I have done this before
> and Firefox starts acting crazy.  I now close the browser, update
> (patch) FF and relaunch.  I would expect libvirtd it act in a similar
> fashion towards it's running guests.

Yes and no. Once VMs are running as processes inside the host, I don't
see why an update of the management tools should need to interact with
them right away.

> 3) Not sure?  I didn't notice.  FWIW, here is some snips from my
> guests XML configurations:
[...]

My conclusion is that after updating, it's no longer valid to have that
PCI id of 0:0:2:0 for anything other than the video card. But the
problem is that apparently virt-install has been happily assigning that
id to other devices for headless guests up to now (NICs in my case,
Ben had it for a disk device).

The bottom line is that even shutting down the guests prior to updating
the host, and rebooting after the update, ends up with none of the
guests starting. Clearly a bug, but one of those fun ones where you'd
need to go back in time to get the clean fix applied...

Matthias