DHCP issue on XEN virtual machine

[unicell]

When using AMT with XEN hypervisor running windows guest with DHCP enabled. Following behaviour could be observed

Machine1: AMT 3.x
(before windows VM starts) Web console available at: Xen's IP address (host)
(after windows VM started) Web console avaiable at: Windows guest's IP address


Machine2: AMT 5.0
(before windows VM starts) Web console available at: Xen's IP address (host)
(after windows VM started) Web console avaiable at: Xen's IP address (host)

This "running virutal machine with DHCP would cause AMT changing it's listening IP" thing was a known issue by Intel.
Please refer to the this URL for detail
http://communities.intel.com/docs/DOC-1247#Running_virtual_machines_and_DHCP_can_cause_Intel_AMT_to_be_inaccessible

So, I tend to believe the above behaviour difference was once a bug for AMT 3.x. And now Intel fixed it in AMT 5.0.

Could anyone here help to verify this assumption? I've already tried to google it, checked it in AMT release note, AMT website, but seems there's no such infomation available.

[Gael_H_Intel]

Quoting - unicell

When using AMT with XEN hypervisor running windows guest with DHCP enabled. Following behaviour could be observed

Machine1: AMT 3.x
(before windows VM starts) Web console available at: Xen's IP address (host)
(after windows VM started) Web console avaiable at: Windows guest's IP address


Machine2: AMT 5.0
(before windows VM starts) Web console available at: Xen's IP address (host)
(after windows VM started) Web console avaiable at: Xen's IP address (host)

This "running virutal machine with DHCP would cause AMT changing it's listening IP" thing was a known issue by Intel.
Please refer to the this URL for detail
http://communities.intel.com/docs/DOC-1247#Running_virtual_machines_and_DHCP_can_cause_Intel_AMT_to_be_inaccessible

So, I tend to believe the above behaviour difference was once a bug for AMT 3.x. And now Intel fixed it in AMT 5.0.

Could anyone here help to verify this assumption? I've already tried to google it, checked it in AMT release note, AMT website, but seems there's no such infomation available.

Hi there! Thank you for posting your question.

The only similarissue that I could find documented in the readme file, starting with AMT 3.x to AMT 5.0 is the following:

-Title: Failure to connect to Intel AMT device over TLS while OS is down, and DHCP options 81 & 12 are not supported
-ID: 42466
-Symptoms: When the enterprise's DHCP configuration does not support DHCP options 81 and 12, it won't be possible to connect to the Intel AMT device over a TLS connection after DNS tables refresh.
-Cause: The certificate used for TLS is based on host name. If these DHCP options are disabled, the Intel AMT device has no means to update the DNS. Thus, DNS will remove the Intel AMT deviceentry upon tables refresh.

-Impact On developer: None
-Resolution: See Name Resolve Sample readme.


Are you operating in a TLS environment? Does this sound like what you were experiencing? From your question it sounded like you are notseeing this issue in either AMT 3.0 or AMT 5.0 - but maybe your aren't provisioned to use TLS (and so it wouldn't be a problem.)

So... if we haven't answered your question we will need more details on things like how your systems are provisioned (SMB, Enterprise, TLS, etc), specifics on your DHCP server - which options are set, where is the DHCP running, etc.

--Gael

[unicell]

Quoting - Gael Holmes (Intel)

Hi there! Thank you for posting your question.

The only similarissue that I could find documented in the readme file, starting with AMT 3.x to AMT 5.0 is the following:

-Title: Failure to connect to Intel AMT device over TLS while OS is down, and DHCP options 81 & 12 are not supported
-ID: 42466
-Symptoms: When the enterprise's DHCP configuration does not support DHCP options 81 and 12, it won't be possible to connect to the Intel AMT device over a TLS connection after DNS tables refresh.
-Cause: The certificate used for TLS is based on host name. If these DHCP options are disabled, the Intel AMT device has no means to update the DNS. Thus, DNS will remove the Intel AMT deviceentry upon tables refresh.

-Impact On developer: None
-Resolution: See Name Resolve Sample readme.


Are you operating in a TLS environment? Does this sound like what you were experiencing? From your question it sounded like you are notseeing this issue in either AMT 3.0 or AMT 5.0 - but maybe your aren't provisioned to use TLS (and so it wouldn't be a problem.)

So... if we haven't answered your question we will need more details on things like how your systems are provisioned (SMB, Enterprise, TLS, etc), specifics on your DHCP server - which options are set, where is the DHCP running, etc.

--Gael

Hi Gael,

Really thanks for helping.

But no, I don't think it has anything to do with TLS. Because I can always connect to AMT web console, the problem is AMT's listening IP would change if I started a virtual machine with its IP obtained from DHCP. However, listening IP would not change in this scenario with AMT 5.0. That is confusing. So I just doubted if new version of AMT internally changed its logic.

For your infomation I set the provision model as "Small Enterprise" and TCP/IP as "DHCP", that is all I changed. I am not quite sure about the DHCP server. But I tested in both company LAN environment and self-configured DHCP server (a Linux machine running dhcpd, no specific option for TLS, no option 81 or 12).

--
Yu

[Andrew_S_Intel2]

Quoting - unicell

When using AMT with XEN hypervisor running windows guest with DHCP enabled. Following behaviour could be observed

Machine1: AMT 3.x
(before windows VM starts) Web console available at: Xen's IP address (host)
(after windows VM started) Web console avaiable at: Windows guest's IP address


Machine2: AMT 5.0
(before windows VM starts) Web console available at: Xen's IP address (host)
(after windows VM started) Web console avaiable at: Xen's IP address (host)

This "running virutal machine with DHCP would cause AMT changing it's listening IP" thing was a known issue by Intel.
Please refer to the this URL for detail
http://communities.intel.com/docs/DOC-1247#Running_virtual_machines_and_DHCP_can_cause_Intel_AMT_to_be_inaccessible

So, I tend to believe the above behaviour difference was once a bug for AMT 3.x. And now Intel fixed it in AMT 5.0.

Could anyone here help to verify this assumption? I've already tried to google it, checked it in AMT release note, AMT website, but seems there's no such infomation available.

After talking to a few people in the team, the consensus was that this still should be a known issue in AMT 5. The AMT IP address follows and adjusts for new IP addresses, since otherwise an IP address renew in the OS would make the AMT system more difficult for a management console to find.

If you're seeing different behavior on the AMT 5 system, there are a couple of possibilities for why AMT didn't change it's IP address, mostly to do with whether AMT saw the DHCP request. Were you consistently seeing this behavior on your AMT 5 system?

[unicell]

Quoting - Andrew Schiestl (Intel)

After talking to a few people in the team, the consensus was that this still should be a known issue in AMT 5. The AMT IP address follows and adjusts for new IP addresses, since otherwise an IP address renew in the OS would make the AMT system more difficult for a management console to find.

If you're seeing different behavior on the AMT 5 system, there are a couple of possibilities for why AMT didn't change it's IP address, mostly to do with whether AMT saw the DHCP request. Were you consistently seeing this behavior on your AMT 5 system?

Yes. I can always see this behaviour on all AMT 5 system now I have. They're all of the same model with Intel Active Management Technology firmware version: 5.0.2-build 1121.

Could it be BIOS related?

[Andrew_S_Intel2]

Quoting - unicell

Yes. I can always see this behaviour on all AMT 5 system now I have. They're all of the same model with Intel Active Management Technology firmware version: 5.0.2-build 1121.

Could it be BIOS related?

Hmm, that is interesting. I don't believe it would be BIOS related, but I can't say that for certain. Let me see if this can be recreated on some of our AMT 5 systems.

That will take a little bit of time, so I might not be able to reply again with what happened immediately. In the mean time, could you give me a little more information about the systems you're working with? Like who manufactured those systems (Lenovo, Dell, etc) and what flavor of Windows is in the VM (Windows XP Service Pack 2, for example)?

Andy

[unicell]

Quoting - Andrew Schiestl (Intel)

Hmm, that is interesting. I don't believe it would be BIOS related, but I can't say that for certain. Let me see if this can be recreated on some of our AMT 5 systems.

That will take a little bit of time, so I might not be able to reply again with what happened immediately. In the mean time, could you give me a little more information about the systems you're working with? Like who manufactured those systems (Lenovo, Dell, etc) and what flavor of Windows is in the VM (Windows XP Service Pack 2, for example)?

Andy

Thanks for helping, Andy!

Here're some information for your reference:

Machine model: Lenovo M58p (AMT 5.05), Lenovo M57 Blueleaf (AMT 3.0.2)
XEN hypervisor: Xen 3.2.3
Windows guest: Windows XP professional, SP2
VM was running with virtual network in bridged mode (config file attached)

FYI. I also tried running Linux guest (Ubuntu 8.04, DHCP) on top of XEN. Result is the same: on AMT 5, listening IP doesn't change even after guest obtained its IP from corporate DHCP server.

Sorry, I don't know how to add an attachment in this forum. So simply pasted VM config file below. (It is the same config file I used for both AMT3 and AMT 5. I don't think VM configuration really matters, just for your reference

import os, re
arch = os.uname()[4]
if re.search('64', arch):
arch_libdir = 'lib64'
else:
arch_libdir = 'lib'

kernel = "/usr/lib/xen/boot/hvmloader"
builder='hvm'
memory = 512
name = "XP"
vcpus=2
vif = [ 'type=ioemu, mac=00:16:3e:01:02:03, bridge=xenbr0' ]
disk = [ 'file://home/work/xen-images/winxp.raw.img,hda,w', 'file://home/work/ISO/ubuntu-8.04.iso,hdc:cdrom,r' ]
device_model = '/usr/' + arch_libdir + '/xen/bin/qemu-dm'
boot="d"
sdl=0
vnc=1
vnclisten="0.0.0.0"
vncdisplay=5
vncconsole=1
vncpasswd='password'
stdvga=0
serial='pty'
monitor=1

--
Yu

[Andrew_S_Intel2]

Quoting - unicell

Thanks for helping, Andy!

Here're some information for your reference:

Machine model: Lenovo M58p (AMT 5.05), Lenovo M57 Blueleaf (AMT 3.0.2)
XEN hypervisor: Xen 3.2.3
Windows guest: Windows XP professional, SP2
VM was running with virtual network in bridged mode (config file attached)

FYI. I also tried running Linux guest (Ubuntu 8.04, DHCP) on top of XEN. Result is the same: on AMT 5, listening IP doesn't change even after guest obtained its IP from corporate DHCP server.

Sorry, I don't know how to add an attachment in this forum. So simply pasted VM config file below. (It is the same config file I used for both AMT3 and AMT 5. I don't think VM configuration really matters, just for your reference

import os, re
arch = os.uname()[4]
if re.search('64', arch):
arch_libdir = 'lib64'
else:
arch_libdir = 'lib'

kernel = "/usr/lib/xen/boot/hvmloader"
builder='hvm'
memory = 512
name = "XP"
vcpus=2
vif = [ 'type=ioemu, mac=00:16:3e:01:02:03, bridge=xenbr0' ]
disk = [ 'file://home/work/xen-images/winxp.raw.img,hda,w', 'file://home/work/ISO/ubuntu-8.04.iso,hdc:cdrom,r' ]
device_model = '/usr/' + arch_libdir + '/xen/bin/qemu-dm'
boot="d"
sdl=0
vnc=1
vnclisten="0.0.0.0"
vncdisplay=5
vncconsole=1
vncpasswd='password'
stdvga=0
serial='pty'
monitor=1

--
Yu

Thanks for the information you provided about your setup, it's good to have that data point as we're looking into this.

We did confirm the same behavior you saw on one of our AMT 5 systems. I still need to test it with an AMT 4 system, but we believe it will behave the same there. We have a theory on what changed between AMT 3 and AMT 5 that we're following up with the architects on, but if it's correct than you should see this behavior on all AMT 5 systems. I'll post again once I have more information.

[Lance_A_Intel]

Hello Yu,
It is great to see you working with virtualization and AMT. Intel is starting to invest more in virtualization on the client and we are interested in it's uses for manageability. Check this video out.

If you have some usage models planned for Xen and AMT we would love to hear them.

Thanks for using the forum and feel free to open discussions on any manageabilty topics here.

--Lance

[Andrew_S_Intel2]

Quoting - unicell

Thanks for helping, Andy!

Here're some information for your reference:

Machine model: Lenovo M58p (AMT 5.05), Lenovo M57 Blueleaf (AMT 3.0.2)
XEN hypervisor: Xen 3.2.3
Windows guest: Windows XP professional, SP2
VM was running with virtual network in bridged mode (config file attached)

FYI. I also tried running Linux guest (Ubuntu 8.04, DHCP) on top of XEN. Result is the same: on AMT 5, listening IP doesn't change even after guest obtained its IP from corporate DHCP server.

Sorry, I don't know how to add an attachment in this forum. So simply pasted VM config file below. (It is the same config file I used for both AMT3 and AMT 5. I don't think VM configuration really matters, just for your reference

--
Yu

Yu,
Sorry for the delay. I have confirmed with some of the firmware engineers that you should see this behavior on all AMT 4 and AMT 5 systems. It was a side effect of changes put in place to support the mobile platform that are common to both the mobile and desktop platform.

So to answer your original question, you should no longer see the known issue you listed, and the behavior you saw on your AMT 5 system should be consistent.

Andy

[unicell]

Quoting - Andrew Schiestl (Intel)

Yu,
Sorry for the delay. I have confirmed with some of the firmware engineers that you should see this behavior on all AMT 4 and AMT 5 systems. It was a side effect of changes put in place to support the mobile platform that are common to both the mobile and desktop platform.

So to answer your original question, you should no longer see the known issue you listed, and the behavior you saw on your AMT 5 system should be consistent.

Andy

Hi Andy,

I got it. Thank you! Really appreciate your help!