Les Mikesell <[email protected]> wrote on 09/11/2009 12:14:22 PM:
> Timothy J Massey wrote: > > > > So you're attempting to convert a physical BackupPC server into a virtual > > image? VMware has conversion tools that do this. I've only used the > > Windows version of VMware Converter, but it has worked perfectly for > > converting a physical host into a virtual host. There is a Linux version. > > I'm hoping to accomplish a couple of different things in one step. I > don't want to convert my existing server to VMware. I want to make a > snapshot copy of the backuppc partition with as little downtime as > possible - and sync'ing a RAID member will do that. Then I want a copy > of that offsite - and so far splitting into 2GB chunks looks like a good > way to make rsync work. Then, if the chunked remote copy just happened > to be in a form that could connect up directly to a VMware guest that > could be set up for disaster recover restores, so much the better. Sure. I can see that you want to do that. But I think you're trying to shoehorn too much into a single process--and requiring pieces (i.e. VMDK) that weren't designed to do what you're asking of them. I think you're wanting more than the tools will deliver. But go for it--prove me wrong! :) > > And if all you're doing is to try to capture a file-based version of your > > block device (a physical partition) that you want to mount using some > > other physical server (or even a virtual server, come to think of it), I > > think you'd be *far* better off just dd'ing the partition into a file and > > using a loopback mount to mount it someplace else. > > > > In other words, the only time you should be dealing with VMDK files is if > > you're trying to create a new virtual guest. And if you are doing this, > > the proper way of doing this is *not* by trying to use LVM/RAID weirdness, > > but using the VMware Converter tools to do this for you properly. > > > > If you're *not* trying to create a new virtual guest, then don't mess with > > VMDK files. They're an annoyance that should only be dealt with if you > > actually have to. > > I'd like to accomplish both at once - that is, image copy/raid sync to > get a snapshot, and have the result usable by a separate VM. However, I > haven't been able to figure out how do do it with the vmware (server > 2.x) utilities. I can create a chunked disk with vmware-diskmanager and > I can connect it so the host sees the whole disk image in one piece with > vmware-mount and the -f option, but I can't find a way to see a raw > partition. I could mount a single partition if it had a filesystem on > it but I don't see how to access the partition in a way that mdadm will > like. Like I said, you may want to do it, but wanting it won't make it so, unfortunately. > > VirtualBox compares fairly with the free VMware Server, but VMware server > > is about 10% of what you can do with VMware--with the paid-for tools. > > > > When it comes to commercial tools, VMware is in a class by itself, though > > Citrix is trying hard with XenServer (still too cumbersome and unpolished > > compared to VMware, and requires VM hardware for Windows). When it comes > > to free-as-in-beer, XenServer is the best. It's still cumbersome, but > > they give you several of the items for free that VMware charges for. > > > > VirtualBox is neither the best tool overall, nor the best tool for free. > > And unfortunately, the GPL'ed code is only a fraction of what you really > > need for a usable virtualization environment. If you want GPL tools, KVM > > (especially in RHEL 5.4) is the best around. > > 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. > > How much performance do you lose using a loopback mount? It's *gotta* be > > less than the overhead of virtualization! I like that idea even better. > > 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. I go back to my original statement: unless you're *trying* to migrate something to a virtual guest, don't saddle yourself with VMDK's. We use them because we have to, not because we *want* to. Use the loopback. You still haven't given me a drawback for this, other than "I want to use VMDK's, even though they aren't designed to be generic containers for data." VMDK files are not tar files, here... Again, a virtual guest can use a loopback file *just* as easily as a physical host... > 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 want to deal with my partitions as files" -- Then use loopback "But I want to use VMDK files" -- Then use the VMware Converter Tools "But I only want to do *some* partitions" -- Then use LVM and snapshot them "But I don't want to use LVM" -- Well, then, I guess you're out of luck... http://en.wikipedia.org/wiki/Moving_the_goalpost Tim Massey ------------------------------------------------------------------------------ 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/
