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: Thursday, August 6, 2015 5:01 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 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.
Yes.
> 
> 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.
Yeah, this is probably the reason of no findings.
> 
> 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.
Well, I'm afraid we cannot assume dhcp server behaves in this way: always assign
its last time IP. You know l1 will reboot after xen install. After reboot, it 
shall
'ask for' not renew its IP. Though, in most practices, it will get its last 
time IP
but cannot guarantee that.
> 
> 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.
This will make current code more complex; while seems no other chooses.
I would suggest unify this: dynamic all cases, no matter L1 or L0 xen install; 
since
you can fix L0's IP in server side, it will always get same IP.
> 
> 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.
OK
> 
> 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