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

["Hu, Robert" <robert.hu@xxxxxxxxx>]

> -----Original Message-----
> From: Ian Campbell [mailto:ian.campbell@xxxxxxxxxx]
> Sent: Wednesday, August 5, 2015 8:27 PM
> To: Hu, Robert; ian.jackson@xxxxxxxxxxxxx; wei.liu2@xxxxxxxxxx
> Cc: xen-devel@xxxxxxxxxxxxx
> Subject: Re: OSSTEST -- nested test case development, RFC: ts-guest-destroy
> doesn't call guest_await_dhcp_tcp() if guest has fixed IP
> 
> 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.
yes
> 
> 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).
After l1 installed Xen and turned into Xen environment (12 testid 
xen-install/l1 below),
its IP get fixed (this is current normal Xen installation behavior, same in 
l0's Xen install).
See /etc/network/interface in l1:
root@l1:~# cat /etc/network/interfaces 
...
auto xenbr0
iface xenbr0 inet static
    address 192.168.199.175
    netmask 255.255.255.0
    gateway 192.168.199.1
    bridge_ports eth0
    bridge_fd 0
    bridge_stp off

Then, in guest-destroy, we cannot get its IP by searching lease file.
> 
> 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.
Yes
> 
> 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.
Yes, L2 will get IP from dhcp.
> 
> Is that all correct?
Here is current test steps

2015-08-06 01:44:58 Z standalone.test-amd64-amd64-qemuu-nested ========== 1 
testid build-check(1) ==========
2015-08-06 01:44:58 Z standalone.test-amd64-amd64-qemuu-nested ========== 2 
testid hosts-allocate ==========
2015-08-06 01:44:58 Z standalone.test-amd64-amd64-qemuu-nested ========== 3 
testid host-install(3) ==========
2015-08-06 01:44:58 Z standalone.test-amd64-amd64-qemuu-nested ========== 4 
testid host-ping-check-native ==========
2015-08-06 01:44:58 Z standalone.test-amd64-amd64-qemuu-nested ========== 5 
testid xen-install ==========
2015-08-06 01:44:58 Z standalone.test-amd64-amd64-qemuu-nested ========== 6 
testid xen-boot ==========
2015-08-06 01:44:58 Z standalone.test-amd64-amd64-qemuu-nested ========== 7 
testid host-ping-check-xen ==========
2015-08-06 01:44:58 Z standalone.test-amd64-amd64-qemuu-nested ========== 8 
testid leak-check/basis(8) ==========
2015-08-06 01:44:58 Z standalone.test-amd64-amd64-qemuu-nested ========== 9 
testid debian-hvm-install ==========
2015-08-06 01:44:58 Z standalone.test-amd64-amd64-qemuu-nested ========== 10 
testid nested-setup ==========
2015-08-06 01:44:58 Z standalone.test-amd64-amd64-qemuu-nested ========== 11 
testid host-ping-check-native/l1 ==========
2015-08-06 01:44:58 Z standalone.test-amd64-amd64-qemuu-nested ========== 12 
testid xen-install/l1 ==========
2015-08-06 01:44:58 Z standalone.test-amd64-amd64-qemuu-nested ========== 13 
testid xen-boot/l1 ==========
2015-08-06 01:44:58 Z standalone.test-amd64-amd64-qemuu-nested ========== 14 
testid host-ping-check-xen/l1 ==========
2015-08-06 01:44:58 Z standalone.test-amd64-amd64-qemuu-nested ========== 15 
testid leak-check/basis/l1(15) ==========
2015-08-06 01:44:58 Z standalone.test-amd64-amd64-qemuu-nested ========== 16 
testid debian-hvm-install/l1/l2 ==========
2015-08-06 01:44:58 Z standalone.test-amd64-amd64-qemuu-nested ========== 17 
testid guest-stop/l1/l2 ==========
2015-08-06 01:44:58 Z standalone.test-amd64-amd64-qemuu-nested ========== 18 
testid guest-destroy ==========
2015-08-06 01:44:58 Z standalone.test-amd64-amd64-qemuu-nested ========== 19 
testid leak-check/check/l1 ==========
2015-08-06 01:44:58 Z standalone.test-amd64-amd64-qemuu-nested ========== 20 
testid capture-logs/l1(20) ==========
2015-08-06 01:44:58 Z standalone.test-amd64-amd64-qemuu-nested ========== 21 
testid final-poweroff/l1 ==========
2015-08-06 01:44:58 Z standalone.test-amd64-amd64-qemuu-nested ========== 22 
testid leak-check/check ==========
2015-08-06 01:44:58 Z standalone.test-amd64-amd64-qemuu-nested ========== 23 
testid capture-logs(23) ==========
> 
> > 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?
l1 on l0.
> 
> 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.
explained above, it is not after we xen-install l1.
> 
> 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.
It is a special guest now.
> 
> >
> > 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