Hello Scott,
Welcome.
At the moment I'm not sure who else is using esxduke.pm, but we would
definitely welcome you or anyone else who wishes to get involved at the
committer level.
For those wanting to contribute code for future releases, ASF requires
the signing and submission of the Individual Contributor License
Agreement (ICLA).
More info about becoming a committer to the Apache VCL incubator project.
https://cwiki.apache.org/VCL/becoming-a-committer.html
Aaron
On 7/19/10 5:19 PM, Scott M. Sorrentino wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
We've been playing with VCL and I really like the concept behind the ESX
module contributed by Sean Dilda from Duke back in February. While I'm not
sure we'll stick with the "snapshot of a template's disk" model, I really
like the lack of dependence on NFS and the fact that the module is interacting
directly with vCenter via the vSphere API.
Our VM admins recently started deploying the Cisco 1000v, a distributed
virtual switch (DVS) for VMware ESX, in our test environment. I've noticed
that the vSphere RegisterVM_Task() API call doesn't seem to properly handle
the VMX configurations for DVS (ie: ethernet0.dvs.portgroupId,
ethernet0.dvs.switchId) and so the VMs get created with bogus ethernet adapter
configurations (ie: no network specified, or the adapter never connects on
poweron). I've been able to work around the problem by completely removing
all references to the ethernet adapters from the VMX, allowing the module to
call RegisterVM_Task(), then adding them back with calls to ReconfigVM_Task()
before the module creates the snapshot and powers on the VM.
We've reported the issue to VMware and, while they acknowledge there's
something not quite right here, there's no estimate on when this might be
addressed. To be fair to them, doing a straightforward deployment of a
template (via the GUI or using the CloneVM_Task() API call) works fine with or
without DVS present.
I'm curious as to whether there are other users of 'esxduke' out there and if
any of them are using (or are planning to use) distributed virtual switches in
their ESX environments. If folks have seen and solved this already, I'd
love to see what they did to fix the problem. If not, and if there is any
interest, I'd certainly be happy to clean up my mods to esxduke.pm and submit
them as a patch for consideration in the future.
- --
Scott M. Sorrentino<sms...@cornell.edu>
CIT Systems& Operations, Cornell University
705 Rhodes Hall // (607) 254-8535
GnuPG fingerprint: 6E30 0B83 43F8 CF8B 3B44 7DBE 6AAE DFC9 1DE6 8C1C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFMRMFFaq7fyR3mjBwRAk4gAJ90YBd+Gy3r8bRJmyreh3Sn5jxMQACfYQKd
Bnw5Yhvx0KFuT8/o3CRX+nI=
=RMd7
-----END PGP SIGNATURE-----
--
Aaron Peeler
Program Manager
Virtual Computing Lab
NC State University
aaron_pee...@ncsu.edu
919-513-4571
