hdiutil create -size 1440k -fs MS-DOS floppy

The last parameter is the file name, floppy in this case. It will add the .dmg extension. After you can rename to img or flp or whatever.

look for name of vmachine…

kill -9 pid of hung vmachine

The instructions were written for ESX 2.x and do not work in 3.x.

You have a number of options with 3.x. Safest options listed first…

1. ‘vmware-cmd /path/to/vm.vmx stop hard’ — may or may not work depending how screwed up the vm is.

2. ‘vm-support -x’ to list the vmids (small x). Then ‘vm-support -X vmid’ (big x) to generate logs and kill it. This way leaves you info for vmware support, but it takes forever to actually kill the vm.

3. ps -auxfww | grep VMNAME. Then kill the pid or kill -9 it.

More info is here. http://virtrix.blogspot.com/2007/09/vmware-stopping-virtual-machine-gone.html

Good luck
Jeremy

(extra ‘*’ in first example as 2nd example doesn’t return a PID at all?

[root@svr-vmh-crcla06 1236]# grep SVR-IAS-CRS01 /proc/vmware/*/*/*
/proc/vmware/vm/1342/names:vmid=1342 pid=-1 cfgFile=”/vmfs/volumes/47fabc0b-cb57433f-2597-0019bb4fcf66/SVR-IAS-CRS01/SVR-IAS-CRS01.vmx” uuid=”50 0c ec b5 52 d8 26 2c-5e ff 72 45 4f 83 7c 28″ displayName=”SVR-IAS-CRS01″

[root@svr-vmh-crcla06 1236]# grep SVR-IAS-CRS01 /proc/vmware/*/*
/proc/vmware/sched/drm-stats: 111 1000 0 -1 1 2 1 0 2 6 2 0 2 6 2 0 4294967293 92 604 512 44 0 0 207 24 133 vm.1341 (/vmfs/volumes/47fabc0b-cb57433f-2597-0019bb4fcf66/SVR-IAS-CRS01/SVR-IAS-CRS01.vmx)

We have a VLAN for the Kernel, another for Service Console, and once the ESX server is built, there will be a separate vswitch just for them with multiple uplinks. We have a different VLAN for provisioning. Plus others for production traffic. Unfortunately, the same provisioning VLAN will be used for building new virtual machines and other physical host OSes as well, so setting the native VLAN to the provisioning VLAN is probably not going to fly.

Although I was hoping to avoid it, I’m pretty sure the only acceptable solution to our security folks will be to configure additional uplinks as access ports to use for provisioning and swap things around after the OS is deployed (although we’re using HP virtual connects, so we may do it there).

Perhaps eventually, the install kernels will jump into the 21st century and figure out a way to support VLANs.

Thanks,

The short story is that using the native vlan does open you to some additional risk. An attack does need to originate from an access port on the same vlan as the native vlan. In my case, normally I will suggest a “management” vswitch used only for ESX things like the service console, vmotion, and nfs mounts for ISOs. The only vlan’s exposed to the risk would be any vlans except the native. This pretty much comes down to the vmotion vlan. Following best practice, this should be a non-routed vlan. If I am fully understanding this, the return traffic from the vmotion network to the attacker should not make it as there would be no return route. The attack would need to consist of a single packet or packets with no return necessary.

Also, many clients I work with have dedicated vlans just for ESX service console and vmkernel interfaces. This would also help narrow down the attack sources.

You can assess your own risk vs reward. Deploying ESX without the native vlan leaves you the following options.

1. Designate a port per rack for deployment. This would be an access port on the same vlan as your service console. Plug in the deployment cable for building. Post build, add the tagging to the service console with esxcfg-vswitch.

2. Same as #1 but build with UDA.

3. Dedicate network interfaces to the service console and use access ports. With HA, it is a best practice to have to vmnic’s on this switch for heartbeat redundancy.

4. Install by hand and script the post installation configuration.

So if you use blades in a lights out datacenter. Good luck.

Also, your comment somehow was held in moderation by wordpress until I approved it. It may have been anti-spam. Anyway, that explains the delay in your comment appearing.

If you set the Native VLAN on the Cisco switch trunk port in this manner, do you expose the network to the VLAN hopping attack via double encapsulation? This is described here:

http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a008013159f.shtml

and also mentioned by Scott Lowe here:

http://blog.scottlowe.org/2008/03/05/vmotion-and-vlan-security/

Thanks,

I had the old copy of smtp_send. It works great with multiple attachments.
Thanks for taking the time to put this together.

Much Appreciated,

Jeff