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 Thu, 2015-08-06 at 01:57 +0000, Hu, Robert wrote:
> > 
> > -----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).

Reconfiguring things on a system to be static rather than dynamic has no
effect on how the network administrator (i.e. the person who operated the
DHCP server) views the IP address. As far as they are concerned the IP
address remains part of the dynamic allocation pool.

However by reconfiguring things to be static the L1 host will no longer be
generating DHCP RENEW requests when the lease times out, so the DHCP server
is at liberty to release the lease when it times out or, worse, reuse the
IP address for something else.

This doesn't apply for L0 in our deployments because we statically assign
IP addresses to MAC addresses associated with physical network interfaces.

So I think we do actually need to start supporting a dynamic mode for at
least L1 hosts (and that may well easily extend to L0 hosts too). Although
it is not 100% accurate I think we can assume that DHCP renewal will always
work, i.e. once a host is given a particular IP address so long as it keeps
renewing the lease it will keep the same address.

So I think we can still discover the DHCP address assigned to the L1 guest,
and propagate it into $r{"${l1ident}_ip"} when we convert it to an L1 host,
but we then also need to modify the Xen installation runs to use dhcp mode
for such cases and not switch to static as we do for an L0 host.

I'm not quite sure how this should be recorded in the runvars. I think we
may want to wait for Ian to return from vacation next week.

The alternative would be that selecthost needs to query the DHCP leases
file for these kinds of hosts, that would have the benefit of handling
potential lease expiry over a reboot.

Ian?


> 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