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 [email protected] ------------------------------------------------------------------------------ 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 [email protected] List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/
