[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Re: [PATCH][XEND] Fix HVM Domain Creation When No Vifs Configured


  • To: "Daniel Stekloff" <dsteklof@xxxxxxxxxx>
  • From: "Christian Limpach" <christian.limpach@xxxxxxxxx>
  • Date: Fri, 14 Jul 2006 16:00:05 +0100
  • Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ewan Mellor <ewan@xxxxxxxxxxxxx>, Christian Limpach <Christian.Limpach@xxxxxxxxxxxxx>
  • Delivery-date: Fri, 14 Jul 2006 08:00:35 -0700
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Fg2JCHui0NVPdASdaBArcb1ZNeNkWw7edPQiJE2DiA2aAXpMarL6i8sdXlHYgY2wPNOudkkrmT/bYU2PipadAfDXGsNj6ygQVwvpaY9Sum+Sr4gOsi+mcW5+MFrtlYBzSdzOaUWkoHIZ9fR5Fk9ZtQag93Rni6BAorLk2n/9PLM=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

On 7/13/06, Daniel Stekloff <dsteklof@xxxxxxxxxx> wrote:
On Thu, 2006-07-13 at 23:04 +0100, Christian Limpach wrote:
> On 13/7/06 10:46, "Daniel Stekloff" <dsteklof@xxxxxxxxxx> wrote:
> > On Thu, 2006-07-13 at 22:32 +0100, Christian Limpach wrote:
> >> Dan,
> >>
> >>> Currently - with the new qemu code, HVM domain creation will fail if a
> >>> vif isn't configured. Xm-test will not pass sanity tests to run. The new
> >>> qemu expects "-net none", otherwise it defaults to "-net nic -net
> >>> user".
> >>>
> >>> This patch simply adds "-net none" to the qemu-dm cmdline if no vifs are
> >>> configured.
> >>>
> >>> Please apply this patch or something similar, xm-test is broken for HVM
> >>> testing without it.
> >>
> >> I've been meaning to look into this.  I think I'd like to take a slightly
> >> different approach:  change the default in qemu to be -net none.
> >> I'll get to it eventually, but if you want to look into providing a patch,
> >> that would be great!
> >
> >
> > I thought about that... but shouldn't we keep the number of changes to
> > qemu to a minimum? Why support more and more specific xen changes to
> > qemu than necessary?
>
> Sure, but this is a very simple and not very intrusive change.
> I think it's preferable to fix things at the source, in this case it's
> clearly qemu having an unreasonable default for our usage model.


Ok, how's this.

I've checked this in but #ifdef'ed the code away instead of deleting it.

    christian

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.