[libvirt] [PATCH] Ignore listen attribute of <graphics> for type network listens

[Ján Tomko]

On Thu, Feb 26, 2015 at 12:40:43PM -0500, Laine Stump wrote:
> On 02/26/2015 11:39 AM, Ján Tomko wrote:
> > On Thu, Feb 26, 2015 at 04:29:53PM +0100, Martin Kletzander wrote:
> >> On Thu, Feb 26, 2015 at 09:57:22AM -0500, Laine Stump wrote:
> >>> On 02/26/2015 08:53 AM, Ján Tomko wrote:
> >>>> Commit 6992994 started filling the listen attribute
> >>>> of the parent <graphics> elements from type='network' listens.
> >>>>
> >>>> When this XML is passed to UpdateDevice, parsing fails:
> >>>> XML error: graphics listen attribute 10.20.30.40 must match
> >>>> address attribute of first listen element (found none)
> >>>
> >>> Note that the listen attribute of <graphics> won't be filled in if you
> >>> request the *inactive* xml, and so there will be no error when it is fed
> >>> back to updatedevice. I can't think of any examples right now, but have
> >>> a very definite memory that there are several items in the config like
> >>> this - if you feed the status xml output back to update/define "you're
> >>> gonna have a bad time". That's why virsh edit asks for the INACTIVE xml.
> >>>
> >>> Did you see this when trying to do an update-device manually, or as the
> >>> result of some management application that has forgotten to add the
> >>> INACTIVE flag to its request for XML?
> >>>
> >>> If the latter, then I guess I can live with ignoring the error in order
> >>> to preserve backward compatibility with the broken application.
> >>> Reluctant ACK.
> >>>
> > Yes, this was a workaround for vdsm.
> >
> > But now I notice that  since the check is only done against type='address'
> > listens, restarting libvirtd will lose any domain started with
> > listen type='network', because libvirt fails to parse its own live XML.
> 
> Ah yes. Less reluctance (*much* less) in the ACK then. I actually ran
> into something similar with networks just a week or two ago - commit
> 8f8e581a - and had to do the same thing.
> 

I have pushed the patch now.

Jan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20150227/fbecf416/attachment-0001.sig>