Timothy J Massey wrote:
>
>> I know there are there in the form of a directory of files which will be 
> 
>> nice for the rsync step.  What I want to know is if the physical host 
>> can see the virtual disk/partition the same way a guest can. There is a 
>> vmware-mount that I think lets you see the virtual filesystem, but I 
>> want access to the raw virtual partition at a block device level.
> 
> No, you really don't!  :)
> 
> What is the advantage of this?  You can simply rsync the *file* just as 
> easy as try to work with "raw virtual partitions".  I see no advantage, 
> only problems.  Even better, rsync is already set up to handle files!  Why 
> not just use it as-is?

Maybe I'm not making this clear.  I want the physical backuppc host to be able 
to mirror its current 750 GB backuppc partition onto what appears at the time 
to 
be a virtual partition, but which results in the updating of the files that 
comprise a vmdk disk. Backuppc isn't running on a VM.  After this step 
completes, I want to rsync those files to copies elsewhere.  At the other 
location, I might want to access the vmdk from a VM if it is necessary to 
restore something.


>> I was hoping to be able to see a block device on the host that would be 
>> the same thing a guest would see.  Then, without running a guest I could 
> 
>> either let the virtual partition sync as a raid member or dd an image 
>> copy to it.  When that is complete, I'd like to be able to rsync the 
>> directory of files that hold the vmdk virtual disk off to another 
>> machine where a virtual machine could be started to access it the usual 
> way.
> 
> You don't *need* all of that complexity.  Do *exactly* what you're 
> describing, but use cp instead of dd to copy the files. 

The files don't have any contents yet.

> I think you need 
> to really think long and hard about the hoops you're trying to jump 
> through.  The logic that you'd use for a physical machine is obselete when 
> you're dealing with VMware.  Just copy the native files as native files to 
> another machine with VMware server, and start the host.  That simple.

I need to get the image of my working system on there in the first place.

> There is *no* need for dealing with RAID, dd, etc.  cp'ing the files is 
> logically *identical* to a DD or RAID1 rebuild of a physical machine.  And 
> *way* simpler.

But it also doesn't do anything useful when there is nothing on the partition 
yet.


>> I suppose I could do dd over ssh to image copy to a running guest if the 
> 
>> physical host can't do it directly, then shut the guest down for the 
> rsync.
> 
> Again, what is your logic here?  You don't move the contents of a block 
> device from one guest to another.  YOU MOVE THE ENTIRE GUEST.  Period. 
> This is so, very, very way better than what you're trying to do.

The point is to get the data which is on a physical host partition into a vmdk 
that can be copied as a set of smaller files - and used that way directly if 
needed.

> It's like waving a magic wand and cloning an entire pretend-physical (i.e. 
> virtual) machine into two complete, identical machines.  Or better yet, 
> imagine you've magically cloned the hard drives and slid them into an 
> identical machine.  By simply cp'ing the contents of the guest directory 
> you have accomplished exactly that.

But I do that on the physical machine now by adding a partition to the raid, 
letting it sync, then removing it.  The cloning part isn't a particular problem 
within the machine.  I just want to get it into something rsync can handle.

>> If I have to change the parent OS, it would probably be to opensolaris 
>> so I could work with zfs snapshots.
> 
> But you can't get VMware for OpenSolaris!  :)  I hate to tell you, ZFS 
> buys you *NOTHING* in this situation.  You'll be forced to use VMware 
> snapshotting anyway, in which case you no longer *need* filesystem 
> snapshotting.

Virtualbox seems to be a reasonable match for VMware these days.  It can even 
use vmdk format disks directly.  With zfs I'd be able to use the incremental 
send/receive function which would likely be even better than rsync'ing the 
files 
sitting on top of it.

-- 
   Les Mikesell
    lesmiksell AT gmail DOT com




------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/