VMwareand I think most VM vendors) have "physical-to-virtual" conversion tools that should do the job. It's been a long time since I've tried them, but when I did I had no good luck (I'm sure that's probably not the case anymore - it's been a very long time).
However, if you find they don't work for you, you can do what I usually do - attach an empty virtual drive to an existing virtual machine and use Ghost or Acronis (or any other drive imaging software) to image the physical disk to the empty VM disk. This works great - just like if you wanted to copy a drive from one physical machine to another.
Sure is, you can make it an ISO and mount it on the system. Beware, that it will take up as much harddisk space as the drive it's a copy of, so you'll want to do this on another drive. There are far easier ways. For instance: Use "File->Import" on the Workstation to choose the harddrive as the source drive to mount.
You can add a windows (samba) share on your hardware node, and go to it through your virtual node (\) to copy the files. Alternatively, you can use the network browsing feature to locate the files on the shared drive, and copy them.
If you want to preserve ACLs and all the NTFS metadata (make a perfect image,) use ImageX to capture an image of the physical disk. And then immediately apply the image to the attached virtual disk drive. You'll need enough space to have a complete backup of the source hard drive, though.
After a long research i found out that the only way to import the informations from your computer to the virtual machine is by sharing them folder by folder and giving full rights for them.Worked for me!
Is it possible/feasible to migrate a Virtual Machine installation of Ubuntu onto a physical machine? If possible, how difficult would this be to accomplish and what steps would i need to take to prepare for the migration.
Both VMWare and VirtualBox (amongst others) use disk formats that don't lend themselves well to being written directly to disk. You can but I personally feel it's more convenient to write it to an intermediary, standard image first. You can do this from your current system without having to boot to a LiveCD.
Move /media/wherever-the-image-is/disk.img somewhere that you're not about to write to. If you're planning to write it to the disk that it's currently sitting on, you'll want to stick it on a separate internal disk, or, worst-comes-to-worst an external disk.
Before you do any serious writing, make sure you have backups. It's a cliche thing to say but one typo and there's a very real possibility you'll nuke your system. Assume that things will go wrong and be prepared. CloneZilla can help you take whole disk backups if you have somewhere for that data to be stored.
You'll want to do something like this. This assumes you're going to overwrite a whole disk. If you want to do an alongside-Windows install, don't follow these instructions! Skip to after the bullets.
Follow the installer through, repartition things as you see fit. About 10 minutes later, you'll be installed and it'll ask you to reboot. Don't reboot. Doesn't matter if you accidentally do, just make sure you're back in the LiveCD for the next instructions.
A .img file sometimes contains a master boot record and a partition table before the actual partition that you might want to mount. Hence you need to find out the offset of the required partition. To this, one can use the parted tool. For an example, look at the answer by sisco311 in this link -1576011.html
Since all your settings are stored in your home directory, you can just make a backup copy of it to another partition on a real disk. After you installed a fresh Ubuntu on a real disk, just run backup program once again to restore your home directory with all setting intact.
Since you have a vmdk file, you might have a VMWare Workstation at your disposal, even complete Virtual Machine this vmdk is attached to. Run your Virtual Machine with this particular vmdk attached, but instead of ordinary boot use PartedMagic liveCD to boot from.
After you've started the sender, you need to start receiver as well. Since you have a physical hdd, I'm assuming, you also have a complete PC with this hdd attached to it. Same thing here: you need to start liveCD with UDPCast Disk Cloning selecting receiver this time as well as appropriate physical hdd.
Worth noting, that you should make all the necessary arrangements to have network connectivity between your Virtual Machine and physical hardware. You should take necessary precautions if your vmdk contains private data, since its contents would be effectively streaming over your network. Another thing is that your target hdd should have no less storage capacity, than your vmdk's capacity. It is obvious, but also worth noting that your image is laid out one-to-one on your target hdd and you need to perform suitable operations with gparted or the like to make use of greater capacity of your new hdd.
If you have the new physical disk attached to the machine the VM virtual disk is on, you can convert VDI to physical without an intermediate conversion, probably saving a bunch of time & disk space. This is assuming your physical disk is the same or larger than the virtual disk's maximum size. In my case, the goal was to convert a VDI to a ZFS zvol, but the approach should be the same with any block device.
In my case, the new zvol was exactly the same size as the virtual disk. Given that your physical disk is probably different, you'd need to employ some kind of partition resizing mechanism to fill the full disk. Gparted or something perhaps. You should be able to point that at the physical /dev/sdX device while still attached to the VM machine so you don't have to resort to boot CD's the physical host.
On the Storage tab, expand the SAN Servers folder in the navigation tree, select a SAN server item contained within the folder. Select the Physical Disks option in the Perspective drop-down list. Select the physical disk that you wish to clone in the table presented in the management pane.
To clone a physical disk used by a particular server, on the Servers and VMs tab, expand the Server Pools or Unassigned Servers folder, to select a particular server in the navigation tree. Select the Physical Disks option in the Perspective drop-down list. Select the physical disk that you wish to clone in the table presented in the management pane.
First off, you can't do this with the system running, or at least, you can't do this safely and expect to get a proper, coherent disk image from doing it with the system running. That's probably the big argument against the dd approach, though it's hard to say without reference to the specific recommendations against it.
Partimage is disk backup software for Linux that can efficiently store disk images. It does this by only copying sectors that are in-use, and compressing the resultant image file. It's included on most system recovery Live CD's, and even has support for saving and restoring images across the network. The downside is that it has to support the filesystems you have on the disk you're backing up, and it notably does not include support for ext4 or BTRFS. Provided that that's not a limitation, this is what I would suggest using. I'll not go into specifics here of how to use it as there are numerous good tutorials out there.
Using dd for this type of thing isn't as much of an issue if you're doing it from a live system, but it still ahs limitations in that it's a pain to restart a partial copy, it fails if there are any failed reads or writes, and it doesn't give nice progress info. That's where GNU ddrescue comes in. It can do some things similar to dd, but it provides a bunch of features that are extremely useful for copying or cloning disks. The process of using it is essentially the same as for dd, but the command line syntax is different. They have good documentation, so I won't waste space here explaining how to use it, except to comment that you almost always want to use a log file so it can resume partial transfers. Like Partimage, ddrescue is included on most system recovery Live CD's.
qemu-img is a special tool included with the QEMU virtualization software that is used to convert between disk image formats supported by QEMU. QEMU helpfully supports both raw disk images and VDI images, so you can use qemu-img to produce a VDI image from a regular physical disk, which means you can just skip the process of restoring the image inside VirtualBox. The exact command you want looks something like:
Where /dev/sda is whatever disk you're copying from, and /path/to/image.vdi is the intended file name for the disk image. This approach has two downsides though, namely that it can't be resumed if interrupted part way through, and that qemu-img isn't included in most Live CD's (let alone most system recovery focused ones).
If you intend to run the VM on a different system than the one that you're copying the disk from and can establish a network connection between the two systems, you have a lot more flexibility, and can completely remove the need for temporary storage. In this case, you should set up the VM other than copying the disk in, and boot both it and the source system into a Live CD environment. You can then use either NBD or iSCSI between the two systems to directly copy the disk over the network using either dd or ddrescue.
I have a hard drive in my laptop with a windows and an ubuntu partition. I got an SSD to replace my hard drive, but it has a slightly lower capacity. I've already partitioned the SSD to the sizes I want, and each partition on the new disk is larger than the amount of used space on my old hard drive.
How can I copy my old partitions onto my new ssd? I'm copying my boot partition too, so how can I make sure the new disk is bootable, and the new partitions are exactly the same as the old ones (but with less free space)?
3a8082e126