Proposal for new method of specifying vm's to backup

[Par_Tojkander]

Good afternoon,

I'm going to go out on a limb here, suggesting an alternative way to
specify which vm's to backup. My proposal is to use command line
switches to directly specify which vm's to backup, either by vm id or
by name.

The way (I've understood) the script works today, the --enablevm
switch puts a '.backup' file in the vm directory, and the --disablevm
switch removes it. The script then takes a backup of all the vm's that
have '.backup' files in them. I hope I've understood this correctly.

Here are my thoughts on the existing method:

- I don't feel comfortable that the script creates and removes files
inside my vm directories. If the script goes wrong, there is the risk
that important files are removed. The script is also run as 'root', so
it's hard to keep the important files safe.

- As for scheduling backups of individual vm's, the current method is
somewhat limiting. For instance, say that you want to backup vm 'foo'
at 04:00, and vm 'bar' at 05:00. You would then have to first '--
enablevm foo --disablevm bar', run backup, and then '--enablevm bar --
disablevm foo', and then run the second backup.

- If you have enabled all vm's for backup, and then add another vm,
you have to manually enable that vm for backup.

Here's my suggestion:

To backup all vm's, you would do something like this:

# backup_vmware.sh --backupall

The script would then get all guests with vmware-vim-cmd, and backup
the files as usual.

If you want to backup only 'foo' and 'bar', you would run:

# backup_vmware.sh --backup foo,bar

...or by id...

# backup_vmware.sh --backup 32,48

This method addresses all of my concerns listed above. I also think
that this will make it easier to convert the script to use 'vmware-vim-
cmd' instead of 'vmrun', since the former uses vm id's and the latter
uses vm paths.

A bonus is that (I think) this method also makes is easy to backup
vm's that are in different datastores than '[standard]'.

A negative issue with my suggestion is that you cannot backup vm's
that are not registered, but registering them (even if they're just
turned off) should be an easy solution.

Please comment, question, thrash and/or praise my suggestion.


Best regards,

Pär

[Par_Tojkander]

Any thoughts on this?


Pär

[Steve Handy]

I am waiting for an open source deduplication system to come out for backing up VM's personally. (Sorry if this doesn't answer your question but I thought I would put that out there..lol)

Stevester

----- Original Message -----
From: vmsb...@googlegroups.com <vmsb...@googlegroups.com>
To: vmsbackup <vmsb...@googlegroups.com>
Sent: Mon Aug 17 06:58:24 2009
Subject: [vmsbackup] Re: Proposal for new method of specifying vm's to backup


Any thoughts on this?


Pär

[ronaldlw]

Just fyi, I'm actually re-writing the script so that it fits my needs
better. I'm new to bash programming so it may take awhile, but I'm
planning to offer whatever I come up with back here if anyone is
interested. Here's what I'm planning at this point:

1) vms to back up will be stored in a .lst file in the same directory
as the script (determined at run time so the script can be moved at
any time and will still work so long as the .lst file is also moved.
(The actual file could be specified as a parameter of the script
allowing for pre-defined backup "groups". otherwise the default .lst
file is used.)

2) the .lst file will be the "file" field from the vmsvc/getallvms
command (including the data store part) so that each line uniquely
identifies a vm that can be in any datastore.

.lst file is like this:
[standard] winxp/winxp.vmx
[2nd data store] winxp/winxp.vmx
[standard] backups/winxp.vmx

3) selecting vms to backup can be done via a "user interface" that
will list all the vms via getallvms and add numbers or letters that
can be used to select vms to add or remove from the backup list. Kind
of like a menu where you get the list of vms and then can enter a
command and then the list numbers separated by commas to enable, or
disable backup.. Hard to explain..

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.

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.

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.

8) At this point I only intend to implement the "hot" back method.

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.

[Pär Tojkander]

ronaldlw wrote:
> Just fyi, I'm actually re-writing the script so that it fits my needs
> better. I'm new to bash programming so it may take awhile, but I'm
> planning to offer whatever I come up with back here if anyone is
> interested. Here's what I'm planning at this point:
>

I totally understand that you want to take the script and modify it for
your needs, but I think that if we instead combined our time and effort
into one single script, it could be a really good one!

> 1) vms to back up will be stored in a .lst file in the same directory
> as the script (determined at run time so the script can be moved at
> any time and will still work so long as the .lst file is also moved.
> (The actual file could be specified as a parameter of the script
> allowing for pre-defined backup "groups". otherwise the default .lst
> file is used.)
>

I'm thinking along the same lines, having the option to backup different
sets of vm's at different times.

> 2) the .lst file will be the "file" field from the vmsvc/getallvms
> command (including the data store part) so that each line uniquely
> identifies a vm that can be in any datastore.
>
> .lst file is like this:
> [standard] winxp/winxp.vmx
> [2nd data store] winxp/winxp.vmx
> [standard] backups/winxp.vmx
>
>

Can different vm's have the same name if they are in different
datastores? I'm thinking that it might be easier to identify vm's by
vmid, if that's the only unique value that's available.

> 3) selecting vms to backup can be done via a "user interface" that
> will list all the vms via getallvms and add numbers or letters that
> can be used to select vms to add or remove from the backup list. Kind
> of like a menu where you get the list of vms and then can enter a
> command and then the list numbers separated by commas to enable, or
> disable backup.. Hard to explain..
>

Okay, here's where I imagine going into a separate direction. My
intention is that the script is designed the so that it can be run via
cron, without any user interaction.

> 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.

> 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.
>
> 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

Pär

[ronaldlw]

Par,

On Aug 17, 9:58 am, Pär Tojkander <par.tojkan...@gmail.com> wrote:
> ronaldlw wrote:
> > Just fyi, I'm actually re-writing the script so that it fits my needs
> > better.  I'm new to bash programming so it may take awhile, but I'm
> > planning to offer whatever I come up with back here if anyone is
> > interested.  Here's what I'm planning at this point:
>
> I totally understand that you want to take the script and modify it for
> your needs, but I think that if we instead combined our time and effort
> into one single script, it could be a really good one!>

My main reason for doing this is really just to get some bash script
experience, and I want to have a really good handle on what the script
is doing, so rewriting seemed the best way to do that. And I guess my
hope is that the good parts of what I do would be integrated into this
script so for just the reason you say (to make it a really good one).
As you can see below, there is a lot of good stuff that I'm not even
going to attempt at this point which I hope will be implemented by
those of you who have done it already in the existing script.

With all of the various options (VLM hot vs cold, hot->cold fail over
etc), the complication of reading messages out of the .conf file, vm-
run, vm-conf, and vmware-vmi-cmd, and support for server 1 and 2, I
gave up on really understanding the existing script. Hopefully what I
implement will be easy to understand and can, if desired, be moved
into the existing script, or be built on to implement whatever
functions are desired from the old script into this one.

1) vms to back up will be stored in a .lst file in the same directory
> > as the script (determined at run time so the script can be moved at
> > any time and will still work so long as the .lst file is also moved.
> > (The actual file could be specified as a parameter of the script
> > allowing for pre-defined backup "groups". otherwise the default .lst
> > file is used.)
>
> I'm thinking along the same lines, having the option to backup different
> sets of vm's at different times.>

Yes, I actually hadn't thought of that until i was making this post, I
think it would be very useful!

> > 2) the .lst file will be the "file" field from the vmsvc/getallvms
> > command (including the data store part)  so that each line uniquely
> > identifies a vm that can be in any datastore.
>
> > .lst file is like this:
> > [standard] winxp/winxp.vmx
> > [2nd data store] winxp/winxp.vmx
> > [standard] backups/winxp.vmx
>
> Can different vm's have the same name if they are in different
> datastores? I'm thinking that it might be easier to identify vm's by
> vmid, if that's the only unique value that's available.> 3) selecting vms to backup can be done via a "user interface" that

Yes, the vms can have the same name... In fact they can have the same
name in the same data store, just have to have different named vmx
files (the vmx file and vm name can be different) if in the same sub-
directory, or they can actually be exactly the same if they are in
different directories. For example, run the backup script on one of
your vms in "copy" mode and then just add the vm in the backup
directory to your inventory to see this in action.

my understanding is that VMID is not guaranteed to be persistent over
time. I've seen posts that say the vmid can change when power cycling
the vms. I don't know that this is true, but I thought it best to do
it this way just in case, plus the .lst file is then "human readable"
and easy to understand what's there.

The combination of datastore and the path and name of the vmx file is
always unique ( I think). I use that to look up the vmid from the
output of getallvms at run time so that I'm sure i have a valid vmid.
This also has a "side benefit" of giving us the parameter needed (the
datastore and vmx file name and path) to use vm-run and vm-cmd if
needed for server1 compatibility.

> > will list all the vms via getallvms and add numbers or letters that
> > can be used to select vms to add or remove from the backup list.  Kind
> > of like a menu where you get the list of vms and then can enter a
> > command and then the list numbers separated by commas to enable, or
> > disable backup..   Hard to explain..
>
> Okay, here's where I imagine going into a separate direction. My
> intention is that the script is designed the so that it can be run via
> cron, without any user interaction.

I don't think this is a separate direction, this is just used to
select vms to be added or removed from the .lst file in an easy and
quick way. I will probably have an option to go ahead and start the
backup from the "menu" but it wouldn't have to be done that way. I
think normally, once the .lst files are created, the normal way to run
the script will be from cron or command line with the appropriate .lst
file as the parameter. Or optionally just part or all of a desired
vm's .vmx file path and datastore info, "[standard] winxp\winxp" for
example to backup a specific vm that may or may not even in a .lst
file. (see 4). In fact you could specify any of the information
listed in the output from the getallvms command, Vmid (probably not
good for reasons I mentioned above), Name, File, Guest OS version or
Annotation (whatever that is). The script will just try to match the
command line provided string against the list of vms and backup those
that match, i think the provided string will also support regular
expressions so "wildcards" would be supported.

>> 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.

>> 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.

> > 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!

> Pär

Ron

[ronaldlw]

I forgot to mention that one of my goals is also to make sure that the
script can be run as a non-root user. I am not sure if the current
script can do this or not.

Thanks,
Ron

[Pär Tojkander]

I totally get your point, I'm in this to get some experience myself,
with bash, svn, patches and such.

Ah, this is more than I knew. I somehow thought that names had to be
unique, either in the same datastore or across datastores.

> my understanding is that VMID is not guaranteed to be persistent over
> time. I've seen posts that say the vmid can change when power cycling
> the vms. I don't know that this is true, but I thought it best to do
> it this way just in case, plus the .lst file is then "human readable"
> and easy to understand what's there.
>

Also something I didn't know. You're correct, VMID's can change if you
reboot the guest from the Console, instead of rebooting it by it's
native command. See here:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1137

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:

http://www.vmware.com/support/ws5/doc/ws_move_uuid.html

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
readable :)

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
system.

>
>>> 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
script better.

Pär

[Pär Tojkander]

ronaldlw wrote:
> I forgot to mention that one of my goals is also to make sure that the
> script can be run as a non-root user. I am not sure if the current
> script can do this or not.
>

A very good idea, I think it should run with the least privileges possible.

I've tried running 'vmware-vim-cmd' as non-root, and keep getting this
error:

$ 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.

Pär

[ronaldlw]

I found this post, do you have time to play around and try to figure
out how to do this?

http://communities.vmware.com/thread/197544

I don't know that changing the owner of all of the files in the /etc/
vmware directory is necessary or desirable, I was able to get the
vmsvc/getallvms command to work by changing ownership of the /etc/
vmware/ssl directory to my user account, but haven't taken time to try
other commands yet.

Thanks!
Ron

[10nico]

Hello!

On 12 Ago, 12:42, Par_Tojkander <par.tojkan...@gmail.com> wrote:
> Good afternoon,
>
> I'm going to go out on a limb here, suggesting an alternative way to
> specify which vm's to backup. My proposal is to use command line
> switches to directly specify which vm's to backup, either by vm id or
> by name.
>
> The way (I've understood) the script works today, the --enablevm
> switch puts a '.backup' file in the vm directory, and the --disablevm
> switch removes it. The script then takes a backup of all the vm's that
> have '.backup' files in them. I hope I've understood this correctly.

Yes you are correct.
There is one exception however; if a VM has the .backup file in its
folder BUT is not registered, it won't be backed up.

>
> Here are my thoughts on the existing method:
>
> - I don't feel comfortable that the script creates and removes files
> inside my vm directories. If the script goes wrong, there is the risk
> that important files are removed. The script is also run as 'root', so
> it's hard to keep the important files safe.

Yes I agree.

>
> - As for scheduling backups of individual vm's, the current method is
> somewhat limiting. For instance, say that you want to backup vm 'foo'
> at 04:00, and vm 'bar' at 05:00. You would then have to first '--
> enablevm foo --disablevm bar', run backup, and then '--enablevm bar --
> disablevm foo', and then run the second backup.

Well, since the script can't know how long it will take to backup VM
'foo' there is the risk that the second copy of the script will try to
run *while* the first is still running.
This is also valid for both versions of the script; I mean the one
which creates the .backup files and the one which specifies the VMs on
the command line.
Only, the second would not need to enable-disable the VMs.

>
> - If you have enabled all vm's for backup, and then add another vm,
> you have to manually enable that vm for backup.
>
> Here's my suggestion:
>
> To backup all vm's, you would do something like this:
>
>     # backup_vmware.sh --backupall

Agreed

>
> The script would then get all guests with vmware-vim-cmd, and backup
> the files as usual.
>
> If you want to backup only 'foo' and 'bar', you would run:
>
>     # backup_vmware.sh --backup foo,bar
>
>     ...or by id...
>
>     # backup_vmware.sh --backup 32,48
>
> This method addresses all of my concerns listed above. I also think
> that this will make it easier to convert the script to use 'vmware-vim-
> cmd' instead of 'vmrun', since the former uses vm id's and the latter
> uses vm paths.

I think that for VMware Server 1.0x we could use the path and for
VMware Server 2.0x it would be better to use the ids.

>
> A bonus is that (I think) this method also makes is easy to backup
> vm's that are in different datastores than '[standard]'.

Some logic to convert id to full pathname would be needed but I don't
think it would be unfeasible.

>
> A negative issue with my suggestion is that you cannot backup vm's
> that are not registered, but registering them (even if they're just
> turned off) should be an easy solution.

MMMmmmhhh...a machine which is not registered is a problem; it cannot
be found by id and only by path, and in this case it must have a
valid .vmx file , which is not guaranteed.
I'd recommend against this practice of registering it before backing
it up.
It would be a lot better to have all the VMs already registered by a
human being which knows what he's doing and not have the script to
"guess and try" to register them.

>
> Please comment, question, thrash and/or praise my suggestion.

Thanks for your suggestions!
I'll take them into consideration but this week I won't be able to do
anything since I'm on vacation (at last!).

>
> Best regards,

Same to you

>
> Pär

Michele

[10nico]

On 18 Ago, 15:30, ronaldlw <goo...@rmwells.com> wrote:
> I found this post, do you have time to play around and try to figure
> out how to do this?
>
> http://communities.vmware.com/thread/197544
>
> I don't know that changing the owner of all of the files in the /etc/
> vmware directory is necessary or desirable, I was able to get the
> vmsvc/getallvms command to work by changing ownership of the /etc/
> vmware/ssl directory to my user account, but haven't taken time to try
> other commands yet.
>
> Thanks!
> Ron
>

Hello Ron, I don't think it would be a great problem to change the
permissions on the file; maybe one could create a group "vmadmins" and
put vmbackup and root as members of it; then give the vmadmins group
full access to the file.

Regards,

Michele

[10nico]

On 17 Ago, 16:26, ronaldlw <goo...@rmwells.com> wrote:
> Just fyi, I'm actually re-writing the script so that it fits my needs
> better.  I'm new to bash programming so it may take awhile, but I'm
> planning to offer whatever I come up with back here if anyone is
> interested.  Here's what I'm planning at this point:
>
> 1) vms to back up will be stored in a .lst file in the same directory
> as the script (determined at run time so the script can be moved at
> any time and will still work so long as the .lst file is also moved.
> (The actual file could be specified as a parameter of the script
> allowing for pre-defined backup "groups". otherwise the default .lst
> file is used.)

I had thought of this, but then when you move a VM to another host
you'd have to remove it from the list and add it to the list of the
new host.
With the .backup file you don't need this.

>
> 2) the .lst file will be the "file" field from the vmsvc/getallvms
> command (including the data store part)  so that each line uniquely
> identifies a vm that can be in any datastore.

Yes this could simplify some operations programming-wise.

>
> 3) selecting vms to backup can be done via a "user interface" that
> will list all the vms via getallvms and add numbers or letters that
> can be used to select vms to add or remove from the backup list.  Kind
> of like a menu where you get the list of vms and then can enter a
> command and then the list numbers separated by commas to enable, or
> disable backup..   Hard to explain..

I'll be honest, I think this is too much effort for too few
advantages; it would be very elegant and user-friendly though.

>
> 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..

I think this would complicate the logic of the script; better to have
always the VMs specified without ambiguity than to rely on script's
ability to "guess".

>
> 5) my goal is to have an absolute minimum number of configuration
> variables, that is everything that can will be determined at runtime.

This is my goal too, in the long term.
Please remember I have few configurations on my hosts and, for what I
need to do, the script already works well; if there is need for
improvements I will take into considerations this need, but my time-
resources for their implementation are limited.

>
> 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.

And for VMware Server 1.0x?

>
> 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 doubt this; the two versions are too different, and these
differences will make it difficult to re-implement the script for
VMware Server 1.0x
Just my 2 cents, but please remember I did the same thing so maybe I
know what I'm talking about...

> 10) I don't plan to implement any email or other logging initially,
> but will try to design with it in mind.

I did this and I'm still regretting this decision now; it would have
been much easier to have loggin and emailing added from day one.

>
> I've just started so things may change as I go, but this is my initial
> design goal list.

I wish you good luck, however I think this "fork" will mean a
duplication of work and we could instead combine our resources, but I
don't mean to force anyone.

Regards,

Michele

[10nico]

> Can different vm's have the same name if they are in different
> datastores?

I checked this: they can *even* if they are in the *same* datastore!
The only unique thing is the ID.

> I'm thinking that it might be easier to identify vm's by
> vmid, if that's the only unique value that's available.>

I totally agree on this.
Of course the VM ID reasoning is valid only for VMware Server 2.0x

> Okay, here's where I imagine going into a separate direction. My
> intention is that the script is designed the so that it can be run via
> cron, without any user interaction

I run the script from another script on the windows machine that has
the tape drive attached.
More specifically, this machine calls the script on the various VMware
hosts, one after the other.

> 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.

Which? I never investigated this avenue! This would be very useful,
I'll investigate this, thanks!

> I wonder how many are still using server 1.x? By the look in the forum,
> some do still use it

I almost exclusively use it!

> 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 agree but don't want to force anyone; everyone of us is free to do
what he thinks is better. :-)

>
> Pär

Regards,

Michele

[Pär Tojkander]

>> A negative issue with my suggestion is that you cannot backup vm's
>> that are not registered, but registering them (even if they're just
>> turned off) should be an easy solution.
>>
>
> MMMmmmhhh...a machine which is not registered is a problem; it cannot
> be found by id and only by path, and in this case it must have a
> valid .vmx file , which is not guaranteed.
> I'd recommend against this practice of registering it before backing
> it up.
> It would be a lot better to have all the VMs already registered by a
> human being which knows what he's doing and not have the script to
> "guess and try" to register them

Oh, sorry, I didn't express myself clearly! I don't want the script to
register them, that should be done by a human. This was just a
work-around if you want to backup vm's that are not registered.

Pär

[ronaldlw]

Michele,

On Aug 18, 7:01 pm, 10nico <gcanavra...@yahoo.it> wrote:
> On 17 Ago, 16:26, ronaldlw <goo...@rmwells.com> wrote:
>
> > Just fyi, I'm actually re-writing the script so that it fits my needs
> > better.  I'm new to bash programming so it may take awhile, but I'm
> > planning to offer whatever I come up with back here if anyone is
> > interested.  Here's what I'm planning at this point:
>
> > 1) vms to back up will be stored in a .lst file in the same directory
> > as the script (determined at run time so the script can be moved at
> > any time and will still work so long as the .lst file is also moved.
> > (The actual file could be specified as a parameter of the script
> > allowing for pre-defined backup "groups". otherwise the default .lst
> > file is used.)
>
> I had thought of this, but then when you move a VM to another host
> you'd have to remove it from the list and add it to the list of the
> new host.
> With the .backup file you don't need this.
>

That is true, but I wouldn't think adding it to the new server would
be a major inconvenience, especially compared to actually moving the
vm. But that is a good point.

>
>
> > 2) the .lst file will be the "file" field from the vmsvc/getallvms
> > command (including the data store part)  so that each line uniquely
> > identifies a vm that can be in any datastore.
>
> Yes this could simplify some operations programming-wise.
>
>
>
> > 3) selecting vms to backup can be done via a "user interface" that
> > will list all the vms via getallvms and add numbers or letters that
> > can be used to select vms to add or remove from the backup list.  Kind
> > of like a menu where you get the list of vms and then can enter a
> > command and then the list numbers separated by commas to enable, or
> > disable backup..   Hard to explain..
>
> I'll be honest, I think this is too much effort for too few
> advantages; it would be very elegant and user-friendly though.
>
>

I actually implemented this part first and it took very little time.
It's not super sophisticated, but it works! It's nice not to have to
cut and paste or type in the whole name of the vm.

>
> > 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..
>
> I think this would complicate the logic of the script; better to have
> always the VMs specified without ambiguity than to rely on script's
> ability to "guess".
>
>

It actually doesn't add any complication the way I'm doing it, and you
would have the option of typing in the whole vmx name including the
data store (as you do now to add a vm) or, if you were comfortable
with putting less you could do that. Just more flexible and I think
the worst problem would be you might backup more vm's that you had
intended.

>
> > 5) my goal is to have an absolute minimum number of configuration
> > variables, that is everything that can will be determined at runtime.
>
> This is my goal too, in the long term.
> Please remember I have few configurations on my hosts and, for what I
> need to do, the script already works well; if there is need for
> improvements I will take into considerations this need, but my time-
> resources for their implementation are limited.
>
>

Yes, I do understand completely! That's part of why I thought it
would be nice to try to re-write this more geared towards what I want
it to do. Plus, I'm enjoying getting to learn more about bash
scripting and regular expressions and vmware commands as well!

>
> > 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.
>
> And for VMware Server 1.0x?
>

Since I am doing this with the needs that I have right now I'm not
implementing server 1.0x at all, but I am trying to keep it in mind.
As far as I can tell so far all the required info can be gotten using
vmrun or vmcmd commands.. but I'm not sure of that. 1.0x
implementation may indeed require parsing the config files.

>
>
> > 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 doubt this; the two versions are too different, and these
> differences will make it difficult to re-implement the script for
> VMware Server 1.0x
> Just my 2 cents, but please remember I did the same thing so maybe I
> know what I'm talking about...
>

You are probably correct, I'm sure that you have run into and solved
lots and lots of issues that I haven't even thought of yet!

> > 10) I don't plan to implement any email or other logging initially,
> > but will try to design with it in mind.
>
> I did this and I'm still regretting this decision now; it would have
> been much easier to have loggin and emailing added from day one.
>
>

Again, you're probably right.. I am trying to think through what would
be need to implement these parts, but am not ready to tackle that part
yet. Again, I'm hoping to gain some experience and also hopefully
some of what I come up with will be beneficial to the current script
in some form or another!

>
> > I've just started so things may change as I go, but this is my initial
> > design goal list.
>
> I wish you good luck, however I think this "fork" will mean a
> duplication of work and we could instead combine our resources, but I
> don't mean to force anyone.
>

Well, possibly, however I need to learn anyway, so I think I would
have to spend the time and resources to get up to speed enough to
really contribute to the current script in any case. I'm sure once I
learn more I'll be contributing to the current script as much as would
be welcomed by the group!

> Regards,
>
> Michele

Thanks for your comments Michele, and again thanks for the great
script that you have made available to us all!

Ron

[ronaldlw]

Ok, I'm making good progress on this and am wondering something
hopefully Michele or Par can answer. I'm trying to figure out if it
would be better to use vmrun or vmware-vim-cmd. It seems to me that
everything that needs to be done should be able to be done in both
server1 and server 2 using vmrun. What am I missing? Why was the
vmware-vim-cmd used for server 2 instead of vmrun commands?

Thanks!
Ron

[ronaldlw]

Also, do you know how to get the results of a vmware-vim-cmd call? I
don't see anyway to tell if the call failed?

Thanks,
Ron

[Pär Tojkander]

One difference I can see is that 'vmware-vim-cmd' uses vm_id for
identification, while vmrun uses the full path to the vmx file.

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.

Pär

[Pär Tojkander]

ronaldlw wrote:
> Also, do you know how to get the results of a vmware-vim-cmd call? I
> don't see anyway to tell if the call failed?
>
>

You should be able to use $? to determine if the command was successful
or not. A zero return value indicates success, and a non-zero indicates
failure.

Example script, exit.sh:

#!/bin/bash
exit 1

pirre@boo:~$ bash exit.sh
pirre@boo:~$ echo $?
1
pirre@boo:¨$

Pär

[ronaldlw]

Ya, I was trying that, but for vmware-vim-cmd it doesn't really work,
since it returns before the command you issue actually completes. The
only way I can think of to accurately get this info is to read the
results using the vimsvc/task_info command.

[Pär Tojkander]

Well yes, it does return control before the actucal task is done. But if
it fails, it does return a non-zero return code, see this example:

boo:~# vmware-vim-cmd -U <user> -P <pass> vmsvc/power.getstate 32
Retrieved runtime info
Powered on
boo:~# vmware-vim-cmd -U <user> -P <pass> vmsvc/power.on 32
Powering on VM:
(vim.fault.InvalidPowerState) {
dynamicType = <unset>,
requestedState = "poweredOn",
existingState = "poweredOn",
msg = "The attempted operation cannot be performed in the current
state (Powered On)."
}
boo:~# echo $?
1

I've used 'vmsvc/power.getstate' to see if the desired powerstate was
reached, if not then wait i.e. 5 seconds. See issue 4 for my patch.

http://code.google.com/p/vmsbackup/issues/detail?id=4

Regards, Pär

[10nico]

That's exactly the problem that prevented me from adopting vmware-vim-
cmd commands; they do return control to the shell before the task is
done.
And yes, the commands *seem* to return a non-zero error code if
there's a problem, but if you try this command you'll soon discovere
that this is not always true.

a) First of all, you suspend a VM
b) then you snapshot it with vmware-vim-cmd -U user -P pass vmsvc/
snapshot.create 32
c) echo $? will return 0 (and this is ok)
d) you snapshot the VM again with the same command
In the graphical VMware Console you'll see this error:

"Snapshot not taken since the state of the virtual machine has not
changed since the last snapshot operation"

However if you do
e) echo $?
it will incorrectly return error code 0, even though there *was* an
error!

And this *is* a problem! (at least IMHO!)

Of course for suspending and resuming the vmware-vim-cmd command seems
to work ok and there is no reason to not to adopt it.
Error checking should be no problem; as for logging we must find a way
to "read" the result from somewhere.
I've tried to use the vimsvc/task_info command as suggested by
Ronald, but I don't understand its inner logic; how does one retrieve
the id of a submitted task?

Also, If we can find a way to "read" the result of the snapshot
operations we could manage to "interpret" if the snapshot did succeed
or not.

Regards,

[ronaldlw]

That's exactly the issue i ran into that made me start to investigate
how to get the info. I was testing the script with a vm that was
suspended, so I would get the message that the vm hadn't changed, just
as you said.. I was able to get the info we need by basically reading
the output of vimsvc/task_list and finding the last createSnapshot
command issued for the vimd we're interested in. This gives the task
id that can then be used to read the status of the task to see if it's
still in progress or if there was an error, etc.... I have this part
actually working.

For me to be comfortable using this method there would have to be a
check of the time stamps to make sure that we're checking the status
of the command we just issued, although that probably isn't strictly
required. In theory though, the same command could have been issued
to the same vm within the time that the info stays in the task list
(not very long) and we could be checking the task list before our most
recent command has been added to the list. But if we capture the time
right before issuing the command then make sure that the item we find
in the task list occurred after that time then that would be pretty
good assurance that we're looking at the correct data.

I came up with a way to do all that, but for now I decided to just
use the VMRUN command instead. I would like to go back an fully
implement this because I think there are a lot of cool things we can
do if we have this capability, but for now it's not necessary.

here is the code that i have so far to do this (note no time checks or
parsing of the result found)

function get_task_status_from_task_list() #vmid, command
{
# declare local variables for the passed in params for easier
reading
local VMID=$1
local COMMAND=$2

# change the IFS to sparate based on line break
local OLD_IFS=$IFS
IFS="$(echo -e "\n\r")"

# some locals to keep track of stuff
local C
local COUNT
local LAST_FOUND=0

local TEMP
local LIST

# get the output of vimsvc/task_list and put in array to
parse
TEMP=$($VIMCMD -U $VMUSER -P $VMPASS vimsvc/task_list)
LIST=( $TEMP )
COUNT=${#LIST[@]}

# scan the task_list for the specified command with the
specified VMID
for((C=1;C<COUNT;C++))
do
# looking for entry with the vmid and command we're
intersted in
# temp is the task id if there is a match, otherwise
it's empty
TEMP=`expr match "${LIST[$C]}" ".*\(haTask-$VMID.*
$COMMAND[^']*\)"`
if [[ $TEMP != "" ]]; then
# found a match, this is now the most recent
one found
LAST_FOUND="$TEMP"
fi
done

# if we found a match then parse the results for that command
if [[ $LAST_FOUND != "" ]]; then
# get the task info for the found task id
TEMP=$($VIMCMD -U $VMUSER -P $VMPASS vimsvc/task_info
$LAST_FOUND )
LIST=( $TEMP )
COUNT=${#LIST[@]}

for((C=1;C<COUNT;C++))
do
# search for the "state" field and set TEMP
to the value inside the "'s
TEMP=`expr match "${LIST[$C]}" '.*state.*"\(.*
\)"'`
if [[ $TEMP != "" ]]; then
break;
fi
done
echo "$TEMP"
else
echo "command $COMMAND for VIMD $VMID not found"
fi


IFS=$OLD_IFS

[ronaldlw]

also note that the lines are split on the message .. argh!

[Par_Tojkander]

Hm, maybe we should just abandon this 'vmware-vim-cmd' route? It seems
that it might just complicate things, and it's not clear why it's
better than 'vmrun'.

What do you guys think? :)


Pär

[ronaldlw]

I think so, except for getting configuration information, which we can
tell if it fails in that we won't be able to find the info we're
looking for if the call fails.

So far I'm only using:
vmware-vim-cmd vmsvc/getallvms
which we can get similar less detailed info using vmrun
listRegisteredVM

but by using:

vmware-vim-cmd ... /hostsvc/datastore/summary

we can get the full path to the data store, which is needed to do the
backup of the files no matter what data store they're in. Is there a
corresponding way to do that with a vmrun command or other method that
would also work with Server 1?

[ronaldlw]

I think so, except for getting configuration information, which we can
tell if it fails in that we won't be able to find the info we're
looking for if the call fails.

So far I'm only using:
vmware-vim-cmd vmsvc/getallvms
which we can get similar less detailed info using vmrun
listRegisteredVM

but by using:

vmware-vim-cmd ... /hostsvc/datastore/summary

we can get the full path to the data store, which is needed to do the
backup of the files no matter what data store they're in. Is there a
corresponding way to do that with a vmrun command or other method that
would also work with Server 1?

On Aug 26, 2:02 pm, Par_Tojkander <par.tojkan...@gmail.com> wrote:

[ronaldlw]

On problem I see now using VMRUN is that if we have the case like we
discussed before (snapshot a suspended vm that already has a snapshot)
we just get an error... so even though it is ok to backup this vm we
would fail it because of the error. Obviously this isn't a case that
should occur because we wouldn't want to create a snapshot when a vm
is suspended anyway, but are there other cases though that might cause
problems that you guys can think of? At least with parsing the task
list we can see what the actual problem was and deal with it
accordingly.. But perhaps there aren't many if any situations that
this will be an issue.

Thanks,
Ron

[ronaldlw]

Does anyone see an issue with using the vmrun list command to find the
running vms and if they are not running then don't snapshot them,
otherwise do the snapshot?

I think the current script uses the vmcmd getstate for server 1 and
vmware_vim_cmd vmsvc/power.getstate for server 2. Using the vmrun
list command would do the same thing for either server 1 or 2. what
do you think?

Thanks,
Ron

[10nico]

The answer is quite simple!
Since the syntax of vmrun is quite different in 1.x and 2.x I
preferred to use the command that was the easiest to implement in each
version.
For version 1.x it's vmrun, for version 2.x it's vmware-vim-cmd.
Please also note that if run as root and on the local machine , the
vmware-vim-cmd command does not require authentication, and is thus
easier to implement.

My philosophy is always "maximum yield with the least possible
effort" (please forgive my direct translation from italian)

Regards,

Michele

[ronaldlw]

Please forgive me again for not being more familiar with Server 1, so
please correct me if I'm wrong.

vmrun syntax on server 2 is the same as server one except for needing
the host, username and password, is that correct? so for server 1 you
would do like this:

vmrun snapshot /var/lib/vmware/Virtual Machines/MyVM/MyVm.vmx

and on server 2 it would look like this:

vmrun -h https://127.0.0.1:8333/sdk -u user -p password snapshot /var/
lib/vmware/Virtual Machines/MyVM/MyVm.vmx

right?

if so then the differences could be accounted for like this:

HOST=https://127.0.0.1:8333/sdk
VMUSER=user
VMPASS=password
VMRUN=vmrun

VMRUN_DEFAULT_PARAMS="-h $HOST -u $VMUSER -p $VMPASS

so all vmrun commands would be implemented in the code as:

VMRUN_CMD=snapshot # or whatever

$VMRUN $VMPARAMS $VMRUN_CMD $VMX_PATH

Then if on server 1 we would just define VMRUN_DEFAULT_PARAMS as ""

Wouldn't that be a simple implementation?

Ron

[ronaldlw]

sorry, i forgot the data store in the server 2 version:

> vmrun snapshot [standard] /var/lib/vmware/Virtual Machines/MyVM/MyVm.vmx

and of course in server one that would not be there.. but it's also
not there in the output from the listRegisteredVM which is used to get
the vmx path anyway, so all the code could be the same.. right?

On Aug 28, 9:02 am, ronaldlw <goo...@rmwells.com> wrote:
> Please forgive me again for not being more familiar with Server 1, so
> please correct me if I'm wrong.
>
> vmrun syntax on server 2 is the same as server one except for needing
> the host, username and password, is that correct?  so for server 1 you
> would do like this:
>
> vmrun snapshot /var/lib/vmware/Virtual Machines/MyVM/MyVm.vmx
>
> and on server 2 it would look like this:
>

> vmrun -hhttps://127.0.0.1:8333/sdk-u user -p password snapshot /var/

[ronaldlw]

Dang it.. i mean on version 2 it would be like this:

vmrun -h https://127.0.0.1:8333/sdk -u user -p password snapshot

[standard] /var/
lib/vmware/Virtual Machines/MyVM/MyVm.vmx

On Aug 28, 9:07 am, ronaldlw <goo...@rmwells.com> wrote:
> sorry, i forgot the data store in the server 2 version:
>
> > vmrun snapshot [standard] /var/lib/vmware/Virtual Machines/MyVM/MyVm.vmx
>
> and of course in server one that would not be there.. but it's also
> not there in the output from the listRegisteredVM which is used to get
> the vmx path anyway, so all the code could be the same.. right?
>
> On Aug 28, 9:02 am, ronaldlw <goo...@rmwells.com> wrote:
>
> > Please forgive me again for not being more familiar with Server 1, so
> > please correct me if I'm wrong.
>
> > vmrun syntax on server 2 is the same as server one except for needing
> > the host, username and password, is that correct?  so for server 1 you
> > would do like this:
>
> > vmrun snapshot /var/lib/vmware/Virtual Machines/MyVM/MyVm.vmx
>
> > and on server 2 it would look like this:
>

> > vmrun -hhttps://127.0.0.1:8333/sdk-uuser -p password snapshot /var/

[10nico]

Not exactly:
the correct syntax would be:

vmrun -h https://127.0.0.1:8333/sdk -u user -p password snapshot

"[standard] MyVM/MyVm.vmx"

Regards,

Michele

On Aug 28, 4:09 pm, ronaldlw <goo...@rmwells.com> wrote:
> Dang it.. i mean on version 2 it would be like this:

> vmrun -hhttps://127.0.0.1:8333/sdk-u user -p password snapshot

> [standard] /var/
> lib/vmware/Virtual Machines/MyVM/MyVm.vmx
>
> On Aug 28, 9:07 am, ronaldlw <goo...@rmwells.com> wrote:
>
> > sorry, i forgot the data store in the server 2 version:
>
> > > vmrun snapshot [standard] /var/lib/vmware/Virtual Machines/MyVM/MyVm.vmx
>
> > and of course in server one that would not be there.. but it's also
> > not there in the output from the listRegisteredVM which is used to get
> > the vmx path anyway, so all the code could be the same.. right?
>
> > On Aug 28, 9:02 am, ronaldlw <goo...@rmwells.com> wrote:
>
> > > Please forgive me again for not being more familiar with Server 1, so
> > > please correct me if I'm wrong.
>
> > > vmrun syntax on server 2 is the same as server one except for needing
> > > the host, username and password, is that correct?  so for server 1 you
> > > would do like this:
>
> > > vmrun snapshot /var/lib/vmware/Virtual Machines/MyVM/MyVm.vmx
>
> > > and on server 2 it would look like this:
>

> > > vmrun -hhttps://127.0.0.1:8333/sdk-uuser-p password snapshot /var/

[ronaldlw]

Right, actually I forgot the -T server also, but you get the idea. Do
you see any reason that wouldn't work for both server 1 and server 2?

Thanks!
Ron

On Aug 28, 9:37 am, 10nico <gcanavra...@yahoo.it> wrote:
> Not exactly:
> the correct syntax would be:
>

> vmrun -hhttps://127.0.0.1:8333/sdk-u user -p password snapshot
> "[standard] MyVM/MyVm.vmx"
>
> Regards,
>
> Michele
>
> On Aug 28, 4:09 pm, ronaldlw <goo...@rmwells.com> wrote:
>
> > Dang it.. i mean on version 2 it would be like this:

> > vmrun -hhttps://127.0.0.1:8333/sdk-uuser -p password snapshot

> > [standard] /var/
> > lib/vmware/Virtual Machines/MyVM/MyVm.vmx
>
> > On Aug 28, 9:07 am, ronaldlw <goo...@rmwells.com> wrote:
>
> > > sorry, i forgot the data store in the server 2 version:
>
> > > > vmrun snapshot [standard] /var/lib/vmware/Virtual Machines/MyVM/MyVm.vmx
>
> > > and of course in server one that would not be there.. but it's also
> > > not there in the output from the listRegisteredVM which is used to get
> > > the vmx path anyway, so all the code could be the same.. right?
>
> > > On Aug 28, 9:02 am, ronaldlw <goo...@rmwells.com> wrote:
>
> > > > Please forgive me again for not being more familiar with Server 1, so
> > > > please correct me if I'm wrong.
>
> > > > vmrun syntax on server 2 is the same as server one except for needing
> > > > the host, username and password, is that correct?  so for server 1 you
> > > > would do like this:
>
> > > > vmrun snapshot /var/lib/vmware/Virtual Machines/MyVM/MyVm.vmx
>
> > > > and on server 2 it would look like this:
>

> > > > vmrun -hhttps://127.0.0.1:8333/sdk-uuser-ppassword snapshot /var/

[Pär Tojkander]

Could this be documented in the google code site, maybe? It could be
done by creating a wiki page explaning the syntax for server 1 & 2.

/ Pär

[ronaldlw]

Par,

I'm not sure what you mean? document what exactly? the vmrun
syntax? I think that would be a good idea!

thanks!
Ron

On Aug 29, 3:31 am, Pär Tojkander <par.tojkan...@gmail.com> wrote:
> Could this be documented in the google code site, maybe? It could be
> done by creating a wiki page explaning the syntax for server 1 & 2.
>
> / Pär
>
> ronaldlw wrote:
> > Right, actually I forgot the -T server also, but you get the idea.  Do
> > you see any reason that wouldn't work for both server 1 and server 2?
>
> > Thanks!
> > Ron
>
> > On Aug 28, 9:37 am, 10nico <gcanavra...@yahoo.it> wrote:
>
> >> Not exactly:
> >> the correct syntax would be:
>

> >> vmrun -hhttps://127.0.0.1:8333/sdk-uuser -p password snapshot
> >> "[standard] MyVM/MyVm.vmx"
>
> >> Regards,
>
> >> Michele
>
> >> On Aug 28, 4:09 pm, ronaldlw <goo...@rmwells.com> wrote:
>
> >>> Dang it.. i mean on version 2 it would be like this:

> >>> vmrun -hhttps://127.0.0.1:8333/sdk-uuser-p password snapshot

> >>> [standard] /var/
> >>> lib/vmware/Virtual Machines/MyVM/MyVm.vmx
>
> >>> On Aug 28, 9:07 am, ronaldlw <goo...@rmwells.com> wrote:
>
> >>>> sorry, i forgot the data store in the server 2 version:
>
> >>>>> vmrun snapshot [standard] /var/lib/vmware/Virtual Machines/MyVM/MyVm.vmx
>
> >>>> and of course in server one that would not be there.. but it's also
> >>>> not there in the output from the listRegisteredVM which is used to get
> >>>> the vmx path anyway, so all the code could be the same.. right?
>
> >>>> On Aug 28, 9:02 am, ronaldlw <goo...@rmwells.com> wrote:
>
> >>>>> Please forgive me again for not being more familiar with Server 1, so
> >>>>> please correct me if I'm wrong.
>
> >>>>> vmrun syntax on server 2 is the same as server one except for needing
> >>>>> the host, username and password, is that correct?  so for server 1 you
> >>>>> would do like this:
>
> >>>>> vmrun snapshot /var/lib/vmware/Virtual Machines/MyVM/MyVm.vmx
>
> >>>>> and on server 2 it would look like this:
>

> >>>>> vmrun -hhttps://127.0.0.1:8333/sdk-uuser-ppasswordsnapshot /var/

[Pär Tojkander]

What I mean is, we are discussing the syntax for vmrun/vmware-vim-cmd
and the difference for server version 1 and 2.

I think it would be useful to take these discussions and turn them into
a wiki page, where the syntax and command differences could be explained.

/ Pär

[ronaldlw]

Ummm.. I'm working on doing some logging and am totally lost on what
it is you're doing here:
if (("$VMRUN" snapshot """$1""" 2>&1 1>&3 | tee -a /tmp/errors.log)
3>&1 1>&2 | tee -a /tmp/output.log) >> /tmp/final.log 2>&1 ; then

I'm thinking of just doing a more simple logging that would have a
verbose setting and could output to the system log and/or a file that
could then be emailed or just viewed later? Do we need multiple log
files?

Thanks,
Ron

[ronaldlw]

I think that would be great, do you know anything about server 1
syntax?

On Aug 30, 2:49 am, Pär Tojkander <par.tojkan...@gmail.com> wrote:
> What I mean is, we are discussing the syntax for vmrun/vmware-vim-cmd
> and the difference for server version 1 and 2.
>
> I think it would be useful to take these discussions and turn them into
> a wiki page, where the syntax and command differences could be explained.
>
> / Pär
>
> ronaldlw wrote:
> > Par,
>
> > I'm not sure what you mean?  document what exactly?  the vmrun
> > syntax?  I think that would be a good idea!
>
> > thanks!
> > Ron
>
> > On Aug 29, 3:31 am, Pär Tojkander <par.tojkan...@gmail.com> wrote:
>
> >> Could this be documented in the google code site, maybe? It could be
> >> done by creating a wiki page explaning the syntax for server 1 & 2.
>
> >> / Pär
>
> >> ronaldlw wrote:
>
> >>> Right, actually I forgot the -T server also, but you get the idea.  Do
> >>> you see any reason that wouldn't work for both server 1 and server 2?
>
> >>> Thanks!
> >>> Ron
>
> >>> On Aug 28, 9:37 am, 10nico <gcanavra...@yahoo.it> wrote:
>
> >>>> Not exactly:
> >>>> the correct syntax would be:
>

> >>>> vmrun -hhttps://127.0.0.1:8333/sdk-uuser-p password snapshot

> >>>> "[standard] MyVM/MyVm.vmx"
>
> >>>> Regards,
>
> >>>> Michele
>
> >>>> On Aug 28, 4:09 pm, ronaldlw <goo...@rmwells.com> wrote:
>
> >>>>> Dang it.. i mean on version 2 it would be like this:

> >>>>> vmrun -hhttps://127.0.0.1:8333/sdk-uuser-ppassword snapshot

[ronaldlw]

10nico,

Hello! I've made a LOT of progress on the script, Par has been
helping me with some testing and I think it's close to being ready for
a broader test. If you'd like to take a look at it email me at
ronaldleew at gmail dot com and I'll send you the latest script.

It's only working on Server 2 but I plan to get it working on server 1
once I have a chance to set up server 1 on a system so I can test it
out.

If anyone else in the group is interested in checking it out and
giving me feedback on how it works for you that would be great, just
send a request to the email address I gave above!

Here is a quick over-view of what this version of the script does:
(NOTE: I'll send you much more detailed info if you request to test
out the script!)

The script is designed to be "menu" oriented in use and setup. When
you first run the script a setup menu will appear and you can enter
the "user" variables through the menu, no editing of the script is
required (or desired). The script presents only the variables that
are appropriate for the version of server that you are running.
Running the script on server 1 will not ask for user name or password
or host for example. (NOTE: server 1 is not ready yet, but this is
just an example of how the script will make it easy to set up your
system based on what is required by your system.) Typically the
default values will work fine, the only changes that would normally be
required are the password and if you use a user other than the
suggested vmbackup.

Once the script is set up you will be presented with a "menu". The
menu consists of an information line followed by a numbered list of
registered vms on your system. The number of each vm is what is used
to enable, disable or initiate a backup of that vm from the menu.
I'll refer to these numbers as vm#. This script stores the list of
vms (by name, not the vm#) to be backed up in a file (by default)
called vmbackup.lst. You can create any number of .lst files with any
combination of vms to be backed up that can then be backed up via the
command line, using cron or whatever you wish.

The script currently only does "hot" backup, that is if the vm is
running it takes a snapshot and then copies the files, then it can
optionally remove the snapshot when the backup finishes (server 2
only). It also currently supports "copy"

I really think this script will be of great help to anyone that needs
to backup their VMs, it's pretty powerful, yet very intuitive to use.
IMHO. :)

Thanks,
Ron

[ronaldlw]

the script supports copy or gzip backups at this time. Also, the
backups are placed in a sub-directory based on the date and time so
each backup of the same vm won't over-write the older backup. Also
the script can store backups "per data-store", that is backups for
datastore XYZ will be stored in a sub-directory of the XYZ data-store
directory, or "global" so that all backups from all data stores will
go into a specified directory located where ever you wish.

Anyway, I've only touched on how the script works.. Let me know if
you're interested in seeing more.

Ron