xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Joao Martins <joao.m.martins@oracle.com>
To: Jim Fehlig <jfehlig@suse.com>
Cc: libvir-list@redhat.com,
	"Daniel P. Berrange" <berrange@redhat.com>,
	xen-devel@lists.xen.org
Subject: Re: [libvirt] [FOR 1.3.0 PATCH] conf: add net device prefix for Xen
Date: Mon, 22 Feb 2016 23:15:09 +0000	[thread overview]
Message-ID: <56CB967D.6040509@oracle.com> (raw)
In-Reply-To: <56670006.40108@suse.com>



On 12/08/2015 04:06 PM, Jim Fehlig wrote:
> Daniel P. Berrange wrote:
>> On Mon, Dec 07, 2015 at 10:59:32PM -0700, Jim Fehlig wrote:
>>> On 12/07/2015 11:52 AM, Daniel P. Berrange wrote:
>>>> On Mon, Dec 07, 2015 at 09:42:21AM -0700, Jim Fehlig wrote:
>>>>> In commit d2e5538b1, the libxl driver was changed to copy interface
>>>>> names autogenerated by libxl to the corresponding network def in the
>>>>> domain's virDomainDef object. The copied name is freed when the domain
>>>>> transitions to the shutoff state. But when migrating a domain, the
>>>>> autogenerated name is included in the XML sent to the destination host.
>>>>> It is possible an interface with the same name already exists on the
>>>>> destination host, causing migration to fail. Indeed the Xen project's
>>>>> OSSTEST CI already encountered such a failure.
>>>>>
>>>>> This patch defines another VIR_NET_GENERATED_PREFIX for Xen, allowing
>>>>> the autogenerated names to be excluded when parsing and formatting
>>>>> inactive config.
>>>>>
>>>>> Signed-off-by: Jim Fehlig <jfehlig@suse.com>
>>>>> ---
>>>>>
>>>>> This is an alternative approach to Joao's fix for this regression
>>>>>
>>>>> https://www.redhat.com/archives/libvir-list/2015-December/msg00197.html
>>>>>
>>>>> I think it is the same approach used by the qemu driver. My only
>>>>> reservation is that it expands the potential for clashes with
>>>>> user-defined names. I.e. with this change both 'vnet' and 'vif' are
>>>>> reserved prefixes.
>>>> Hmm, yes, tricky one.
>>>>
>>>> If we only care about XML parsing, then you could register a post
>>>> parse callback instead to do this.
>>> AFAIK, XML parsing is all that's in play here.
>>>
>>>> I'm not clear why we also have it in the virDomainNetDefFormat
>>>> method - and we can't solve that with a post-parse callback.
>>>>
>>>>
>>>> The other option would be to make the reserved prefix be a
>>>> capability that the parser/formatter could read.
>>> This seems like the best option, since a post-parse callback doesn't solve the
>>> problem in virDomainNetDefFormat. It also has the upshot of making the prefix
>>> visible and known to users. But I doubt such a change is suitable during 1.3.0
>>> freeze.  With the freeze in mind, seems the best solution to the libxl migration
>>> regression is revert d2e5538b1. It can be added again post-1.3.0 release, after
>>> adding the prefix to capabilities.
>>>
>>> DV, since you may be making the release soon, feel free to revert d2e5538b1 if
>>> you agree.
>>
>> Yeah, just go ahead & revert it Jim,  DV isn't doing the releae until
>> tomorrow morning
> 
> I've pushed the revert.
> 
> Joao, sorry for yanking this for 1.3.0. We can get it in 1.3.1, after exposing
> the prefix in capabilities.
> 
Hey Jim,

I had the impression we had pushed this back in (i.e. cherry-picking d2e5538)
but I was double checking and that's doesn't seem to be case. In adding support
for the prefix in capabilities I found out one issue on the migration failure
path leading to dereferencing a NULL pointer on the destination. If you agree
could we squash the following chunk in addition to the cherry-pick of d2e5538:

diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index 63c5b24..f73bfb3 100644
--- a/src/libxl/libxl_domain.c
+++ b/src/libxl/libxl_domain.c
@@ -768,7 +768,7 @@ libxlDomainCleanup(libxlDriverPrivatePtr driver,
         for (i = 0; i < vm->def->nnets; i++) {
             virDomainNetDefPtr net = vm->def->nets[i];

-            if (STRPREFIX(net->ifname, "vif"))
+            if (net->ifname && STRPREFIX(net->ifname, "vif"))
                 VIR_FREE(net->ifname);
         }
     }
diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index 3f4457f..5479441 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -5590,7 +5590,7 @@ static virHypervisorDriver libxlHypervisorDriver = {
     .domainGetJobStats = libxlDomainGetJobStats, /* 1.3.1 */
     .domainMemoryStats = libxlDomainMemoryStats, /* 1.3.0 */
     .domainGetCPUStats = libxlDomainGetCPUStats, /* 1.3.0 */
-    .domainInterfaceStats = libxlDomainInterfaceStats, /* 1.3.0 */
+    .domainInterfaceStats = libxlDomainInterfaceStats, /* 1.3.2 */
     .connectDomainEventRegister = libxlConnectDomainEventRegister, /* 0.9.0 */
     .connectDomainEventDeregister = libxlConnectDomainEventDeregister, /* 0.9.0 */
     .domainManagedSave = libxlDomainManagedSave, /* 0.9.2 */


Or do you think it should be deferred to 1.3.3 ?

Thanks,
Joao

> Regards,
> Jim
> 
> --
> libvir-list mailing list
> libvir-list@redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
> 

  parent reply	other threads:[~2016-02-22 23:15 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1449506541-9856-1-git-send-email-jfehlig@suse.com>
2015-12-07 18:52 ` [libvirt] [FOR 1.3.0 PATCH] conf: add net device prefix for Xen Daniel P. Berrange
     [not found] ` <20151207185212.GO848@redhat.com>
2015-12-08  5:59   ` Jim Fehlig
     [not found]   ` <566671C4.1080706@suse.com>
2015-12-08 10:38     ` Daniel P. Berrange
     [not found]     ` <20151208103834.GE2999@redhat.com>
2015-12-08 16:06       ` Jim Fehlig
     [not found]       ` <56670006.40108@suse.com>
2016-02-22 23:15         ` Joao Martins [this message]
2016-02-23 21:53           ` Joao Martins
2016-02-24  4:31           ` Jim Fehlig
2016-02-24 13:30             ` Joao Martins

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56CB967D.6040509@oracle.com \
    --to=joao.m.martins@oracle.com \
    --cc=berrange@redhat.com \
    --cc=jfehlig@suse.com \
    --cc=libvir-list@redhat.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).