Re: [Xen-devel] OSSTEST -- nested test case development, RFC: ts-guest-destroy doesn't call guest_await_dhcp_tcp() if guest has fixed IP

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Wed, 2015-08-05 at 06:22 +0000, Hu, Robert wrote:
> Hi Ians,

I don't 100% recall how this is supposed to fit together.

IIRC:

1# L0 is installed as usual

#2 An L1 guest is installed. That L1 guest gets an IP address from DHCP in
the normal way.

3# Then ts-nested setup customises the L1 guest into an L1 host, storing
the DHCP assigned address in $r{"${l1ident}_ip"}. (I'm not sure if it is
actually called l1ident, but whatever it is).

4# Then operations which selecthost(l1ident) see that $r{"${l1ident}_ip"}
and use it as the $ho->{Ip} instead of looking for it in the host db.

5# At some point an L2 guest is installed on the L1 host and it also gets
an IP from DHCP in the usual way.

Is that all correct?

> Current ts-guest-destory will invoke guest_await_dhcp_tcp(); 
> but in nested case, after l1 turns into Xen environment, it then has
> fixed IP address; which in turn has failed at dhcp lease check.

So here are we talking about ts-guest-destroy of an L2 guest on the L1
host, or of the L1 guest on the L0 host?

I think you are talking about the L1 guest on the L0 host.

In that context ts-guest-destroy will be considering the L1 as a guest, so
I would expect that guest_await_dhcp_tcp should work, because the L1
guest's IP was assigned via DHCP in #2 above.

So I suppose the question is how/why is guest_await_dhcp_tcp failing when
operating on the L1 guest? It should be "just a guest" in this context I
think.

> 
> So, how about if I in ts-guest-destroy bypass guest_await_dhcp_tcp()
> if we have $r{guest->Guest_ip}?
> 
> Best Regards,
> Robert Ho
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel