Chris Sears's questions

Should the following scenario work?

I have a DHCP server on VLAN 101, with the IP 192.168.0.5. I have two other VLANs 102 and 103 where I want to hand out IPs the same range 10.20.30.40-240, but from different scopes. So a client on VLAN 102 could get 10.20.30.40 and a different client on vlan 103 could also get 10.20.30.40.

Their routing doesn't overlap, so there is no layer 3 issue.

I will configure the DHCP IP helper setting on the firewalls for each VLAN to forward the DHCP traffic to my DHCP server on VLAN 101.

I know the MAC addresses of all the clients in VLAN 102 and 103, so I can use a filter or static mapping to assign clients to the VLAN 102 scope or the VLAN 103 scope.

Thanks!

Greetings,

I'm working with RHEL 5.5 guest VMs under VMware ESX 4. When I configure the virtual disks in the VM hardware settings, each disk has a SCSI address in the format "N:M". For example, "1:3" would mean SCSI host number 1 and SCSI target ID 3.

When I look at the disk info from the VM's BIOS or a Windows OS, the detected SCSI address info matches up with the virtual hardware settings. But under Linux, the SCSI address components don't match up, at least not completely or consistently.

I've tried the three supported virtual SCSI and SAS drivers and they all seem to be "broken", but in different ways. Here's a list of the virtual hardware addresses vs what was detected under Linux with each of the drivers:

Driver    vHW Addr  Linux Addr
--------  --------  ----------
LSI SAS   0:0       0:0
LSI SAS   0:3       0:1
LSI SAS   0:6       0:2
LSI SCSI  1:1       2:1
LSI SCSI  1:4       2:4
LSI SCSI  1:7       2:7
pvSCSI    2:2       1:2
pvSCSI    2:5       1:5
pvSCSI    2:8       1:8

My main question is why does this happen under Linux? The next question is: how do I get it fixed or fix it myself?

If I was going to guess, I'd say it's an issue with how the kernel is handing out the SCSI host number and how the Linux SCSI driver (included with VMware tools) is detecting the SCSI target number. Perhaps the order the drivers are loaded also has something to do with the issue. I'm guessing this would not involve udev, but I could be wrong.

Any thoughts would be appreciated. Thanks!

PS. My environment is VMware, but I don't need an answer for these drivers specifically. I imagine this might be a problem with any SCSI driver under Linux.

Greetings,

I'm trying to automate the testing of driver support in a library of OS images used for automated deployment in a data center environment.

In most cases, I see people standardize on a few OSs and a few server hardware models, which makes testing and validating that all the OS images contain drivers that are supported on all the hardware fairly manageable.

Unfortunately, I can't do that. I have several dozen OSs (Linux/Windows/Solaris, x86/x64/SPARC, versions going back 3 years) that really should be tested against representative server hardware from Dell, HP, IBM and Sun going back 3 years. That's a lot of work and a lot of physical systems.

What I'd rather do is pick up the PCI device info of the various storage controllers (and maybe NICs) and use something to simulate the devices in a VM. I could then apply/install the OS images to the VMs and see if the kernel code which matches up detected PCI devices with available drivers runs into a problem or not. There would have to be some simulation of actual device functions, since the OS would start trying to use the device after the driver loaded, but it seems like people doing driver or hardware development might have a similar need for such a tool.

Does anyone know if such a thing exists? Or is there a completely different workaround that would address my problem?

Thanks!