This makes the VMID pretty useless, I agree. I think I've found a more
unique value -- the vm uuid. But even that can change. See this link:
The link is for Workstation, but I think the same applies for Server.
The UUID seems to be too much of a hassle to be working with, so I think
your format may be the best one, and also has the benefit of being
I see your point now, the script would work the same, but your menu
script is more for setting which vm's to backup. I think that makes
sense, having a "backend" and a "frontend", so to speak.
>>> 4) vms to back up could also be selected by command line using any or
>>> all of the info in the "file" field of the getallvms command separated
>>> by commas, basically you just have to put in enough info to ensure
>>> that you uniquely identify the vm, which would depend on your setup.
>>> I.E. if you only have one data store then you would never need to
>>> specify that, if you have more than one data store but never have vms
>>> with the same file name in both data stores then you still wouldn't
>>> need to specify the data store..etc..
>>> 5) my goal is to have an absolute minimum number of configuration
>>> variables, that is everything that can will be determined at runtime.
>> I agree. You could get all the paths to the programs needed by using
>> 'which', that way the user doesn't have to specify them. Of cource, if a
>> program doesn't exist the script should fail with an error code.
> I actually don't think which would be required, since the vmware-vim-
> cmd is in the path we can just issue that command without the whole
> path to it.. right? At least that's how i'm proceeding at this point.
Sorry, I was referring to the other programs needed, such as mail, sed,
awk, etc. If you use `which` to see where the program is, the user
doesn't need to customize that value to fit in their current operating
>>> 6) my goal is to get all information required without having to parse
>>> any vmware config files, instead getting info from the vmware-vim-cmd.
>> Sounds reasonable. My opinion is that it's best to choose one way of
>> getting the information, and vmware-vim-cmd is very suitable.
>>> 7) I'll be writing with server2 in mind, but I'll try to make is so
>>> that it won't be too hard to implement server1 if someone is so
>>> inclined or i have time later.
>> I wonder how many are still using server 1.x? By the look in the forum,
>> some do still use it.> 8) At this point I only intend to implement the "hot" back method.
> Yes, it seems that some are, but I think it would be trivial to
> implement server 1 support if I write this well enough.
I've sometimes though if it would be better to split the script into
three parts -- one file with functions, common for both 1 and 2, one
file specific to version 1, and one specific to version 2. But that's
probably a lot of work.
>>> 9) I also don't intend to use any of the LVM stuff.
>>> 10) I don't plan to implement any email or other logging initially,
>>> but will try to design with it in mind.
>>> I've just started so things may change as I go, but this is my initial
>>> design goal list.
>> Again, I think that if we combined our efforts into one single script,
>> that could be a really good one. I hope that the developers can give us
> I think this line was cut off? Anyway, I agree that it would be best
> to have one script. Perhaps this will happen. Once I get this
> working I'll post it here and we can all try to decide what to do with
> it! If you think there is a better way to proceed that that please
> let me know!
Yes it seems to be cut off. I was going to say that to make this a great
script, we will need the focus and attention from the developers.
I think you should proceed and write your own script, and when you're
ready and if you feel like it, contribute parts of it to make this
I've tried running 'vmware-vim-cmd' as non-root, and keep getting this
$ vmware-vim-cmd -U user -P pass vmsvc/get.summary 16
Failed to connect: Crypto Exception: error:0200100D:system
library:fopen:Permission denied:unable to load /etc/vmware/ssl/rui.key
It seems that you need read access to the above file, haven't tried
that. Could perhaps be a security issue.
Another is that 'vmware-vim-cmd' needs to be run on the server itself,
while vmrun can be run from a remote host. Or so I've read, anyway.
Example script, exit.sh:
pirre@boo:~$ bash exit.sh
pirre@boo:~$ echo $?