Timothy J Massey wrote:
> 
>> I'm not convinced that any of that matters when the real issue is moving  
>> a physical disk head around.
> 
> If that's all you want out of life, then pick whatever.  For most people, 
> vMotion is a killer app.  The only reason I would use a solution that 
> *doesn't* provide this would be 100% GPL--which is why I'm keeping a very 
> close eye on KVM.

Most of the services I care about need a large farm of load balanced 
physical servers, so slicing one of them up into virtual machines 
doesn't make a lot of sense and moving them always involves juggling 
hardware anyway.  There could be some exceptions but probably not enough 
to deal with different technology.  An occasional Vmware server/guest 
instance isn't a big deal because I don't rely on it for anything I 
couldn't do with bare hardware.

>> This is the effect I was hoping to get by vmware-mounting the vmdk into 
>> the physical host.
> 
> And I think you'd be a million times better by just using a simple 
> loopback mount--which could be used by a physical *or* a virtual host with 
> zero drawbacks, outside of loopback itself.  And it's rsyncable.

Maybe - but I don't want it live in my main server.  I want the 
chunked-file copy to be a snapshot made quickly locally, then dribbled 
offsite.  When I have a chance to look at the vmdk spec, it's probably 
trivial to copy directly to one creating it as you go as fast as dd 
could copy an image.  I just expected vmware-mount to provide the option 
to see a partition as well as the whole disk - until I tried it.  Maybe 
I'm still missing something.

>> Maybe the fuse/perl driver mentioned earlier would work with one end in 
>> the physical backuppc server and the other in the remote disaster 
>> recovery VMware guest.   But, there is a timing issue unless some sort 
>> of local snapshot capability is added and I'd prefer to avoid LVM.  I 
>> suppose I could sync my existing disk into the raid, break it, and mount 
> 
>> it back separately for the rsync step to decouple the transfer time.
> 
> You have *way* too many preconditions.

I'm trying to change a working process as little as possible.  If I have 
to make big changes, zfs is probably the way to go.

> "I want to deal with my partitions as files"
> 
>  -- Then use loopback

I want something that works with mdadm to add to my raid so the 
partition can remain mounted while the copy occurs.   And I want 
something that is chunked for the rsync steps.

> http://en.wikipedia.org/wiki/Moving_the_goalpost

I have a working setup where I add a physical drive to my raid, then 
remove it and I can access that drive through a USB adapter from a 
vmware guest on my laptop.  The goal is simply to change the step where 
I throw that drive in my briefcase and take it offsite with something 
that happens automatically and still gives me a copy elsewhere that a 
vmware guest can access for disaster recovery.  It doesn't _have_ to get 
copied into a chunked vmdk immediately, but doing so solves all of the 
subsequent steps.

-- 
   Les Mikesell
     lesmikesell 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/