On 2012-04-04 03:56, jdmcdaniel3 wrote:
> Found a possible link here you might want to read as it might be
> helpful with your problem.
>
> ‘VMware Communities: virtual network editor disapeared?’
> (http://communities.vmware.com/thread/270128)
Interesting indeed.
They are all looking for an application named “vmware-netcfg”. First they
copy it from the workstation version (probably “illegal” method), then they
create a symlink to “appLoader”. And version 4.0.2 already has this symlink
made. It needs to be called as root.
But what it configures are the vmnet0, vmnet1, and vmnet8 interfaces at the
host. What I need is assign the same lease to the clients.
However, I see that it says “use local dhcp service to distribute IPs to
VMs”. This is what i need to control, but I thought it was using vmware own
dhcp service, not the system service.
And looking at the running programs, I see:
> 20420 ? Ss 0:00 /usr/bin/vmnet-dhcpd -s 6 -cf /etc/vmware/vmnet1/dhcpd/dhcpd.conf -lf /etc/vmware/vmnet1/dhcpd/dhcpd.leases -pf /var/run/vmnet-dhcpd-vmnet1.pid vmnet1
> 20423 ? S 0:02 /usr/bin/vmnet-natd -s 6 -m /etc/vmware/vmnet8/nat.mac -c /etc/vmware/vmnet8/nat/nat.conf
> 20426 ? Ss 0:00 /usr/bin/vmnet-netifup -s 6 -d /var/run/vmnet-netifup-vmnet8.pid /dev/vmnet8 vmnet8
> 20481 ? Ss 0:00 /usr/bin/vmnet-dhcpd -s 6 -cf /etc/vmware/vmnet8/dhcpd/dhcpd.conf -lf /etc/vmware/vmnet8/dhcpd/dhcpd.leases -pf /var/run/vmnet-dhcpd-vmnet8.pid vmnet8
Is it the system dhcp? No.
Telcontar:~ # rpm -qf /usr/bin/vmnet-dhcpd
file /usr/bin/vmnet-dhcpd is not owned by any package
Looking at “/etc/vmware/vmnet8/dhcpd/dhcpd.conf” I see
> ###### VMNET DHCP Configuration. Start of "DO NOT MODIFY SECTION" #####
> # Modification Instructions: This section of the configuration file contains
> # information generated by the configuration program. Do not modify this
> # section.
and in this section I should not modify I see:
host vmnet8 {
hardware ethernet 00:50:56:C0:00:08;
fixed-address 192.168.74.1;
option domain-name-servers 0.0.0.0;
option domain-name "";
option routers 0.0.0.0;
}
Maybe what I need is add sections like that for my guests, writing the MACs
and the addresses, but below the immutable section :-?
I don’t know, because two days ago I modified the “default-lease-time”,
yesterday I upgraded player, and today I see my modification destroyed.
Ok, I restart the guest to find out the MAC… weird, I have no IP.
rcnetwork restart… failed! No eth0. Fantastic, I updated this guest
yesterday ![:frowning: :frowning:](/images/emoji/twitter/frowning.png?v=12)
Ok, restart the guest. Find out the mac. I add this section at the end:
host os-12_1 {
hardware ethernet 00:0C:29:6B:70:77;
fixed-address 192.168.74.128;
}
I see this entry in the host logs:
> <0.6> 2012-04-04 10:47:07 Telcontar kernel - - - [462108.474298] usb 2-5.4: reset high speed USB device using ehci_hcd and address 4
> <3.6> 2012-04-04 10:47:14 Telcontar vmnet-dhcpd - - - DHCPDISCOVER from 00:0c:29:6b:70:77 via vmnet8
> <3.6> 2012-04-04 10:47:14 Telcontar vmnet-dhcpd - - - DHCPOFFER on 192.168.74.128 to 00:0c:29:6b:70:77 via vmnet8
> <3.4> 2012-04-04 10:47:14 Telcontar vmnet-dhcpd - - - Both dynamic and static leases present for 192.168.74.128.
> <3.4> 2012-04-04 10:47:14 Telcontar vmnet-dhcpd - - - Either remove host declaration os-12_1 or remove 192.168.74.128
> <3.4> 2012-04-04 10:47:14 Telcontar vmnet-dhcpd - - - from the dynamic address pool for 192.168.74.0
> <3.6> 2012-04-04 10:47:14 Telcontar vmnet-dhcpd - - - DHCPREQUEST for 192.168.74.128 from 00:0c:29:6b:70:77 via vmnet8
> <3.6> 2012-04-04 10:47:14 Telcontar vmnet-dhcpd - - - DHCPACK on 192.168.74.128 to 00:0c:29:6b:70:77 via vmnet8
It is conflicting with this clause in the immutable section:
subnet 192.168.74.0 netmask 255.255.255.0 {
range 192.168.74.128 192.168.74.254;
option broadcast-address 192.168.74.255;
option domain-name-servers 192.168.74.2;
option domain-name localdomain;
default-lease-time 1800; # default is 30 minutes
max-lease-time 7200; # default is 2 hours
option netbios-name-servers 192.168.74.2;
option routers 192.168.74.2;
}
I can’t modify that clause, so I have to use another IP on another range…
but if I do that, will it be routed? Or can I ignore the error message?
I’ll have to watch out to see if the IPs change.
AH! No, I have to hand out IPs below 128.
Issue solved - thanks for the idea ![:slight_smile: :slight_smile:](/images/emoji/twitter/slight_smile.png?v=12)
–
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)