Ubuntu 14.04 VM under Windows 10, VDI size increase

[jack-in-the-box]

Using VirtualBox to host Ubuntu 14.04 for some FFmpeg development has been a struggle. I first tried to use a previously installed version 5.0.26 VirtualBox. Ubuntu installed and started easily, but then the weirdness started. USB drives could be found and selected in VirtualBox, and they would disappear from the Windows environment when used, but would never show up anywhere in the Ubuntu environment. Likewise shared drives were a no-go. A coworker recommended that I upgrade to the current version (5.1.10) and add the extension packs, but neither method for connecting the virtual machine to outside data could be made to work. We finally convinced Samba to install on the Ubuntu machine and connect to the outside world over a bridged Ethernet adapter. Oddly, we found that it was necessary to issue sudo ifdown eth0 followed by sudo ifup eth0 every time the VM starts else Samba would not connect. Thinking the worst was behind me, I started loading the things I needed for development and realized that there was not enough disk space. (The default of 8GB for a dynamically allocated drive seems a little small.) for most of two days now I have been off-and-on trying to find a way to increase the size of the drive. I readily found the instructions for how to increase the size of the VDI (VBoxManage modifyhd <disk name>.vdi --resize <new size>). With a little more looking I found the instructions for using GParted on a live CD to change the partition sizes, although the first site I found recommended the Slitaz 4.0 ISO which will not work on logical volumes. After downloading and using gparted-live-stable 0.27.0-1 I got the partitions adjusted, but found that the effective size of the volume for Ubuntu had not changed. I found no more suggestions on line, but did some research and found that there is yet another set of drive size parameters that are governed by the lvm system. Using lvextend, I was able to expand that table as well. Unfortunately, that also left the effective volume size for Ubuntu unchanged. I then found a recommendation on this forum to use dd to copy from the old drive to a newly created larger drive. (viewtopic t=10348) This appeared to hang (it ultimately finished after nearly four hours on an 80GB drive). While waiting to see if it would finish, I decided that maybe it would be faster to start over, so I created a new VM with a new 80GB dynamic media storage VDI drive. This was still running after three hours so I cancelled it, but cancel did not work. I had to reboot to get back to normal operation. Unfortunately, the dd method also did not work. The resulting drive will not fully boot. The logical root volume is missing.

My basic question is why is this process so incredibly difficult? If I only had my experience to go on, I would think that VirtualBox was just an immature program that is not ready for serious use, but there seems to be widespread evidence that it works well for many other people. Can anyone out there offer any guidance on why my experience is so miserable here? Are any of the things I tried widely known to be troublesome? Is this a Windows 10 thing? Is there a guiding document for how to do any of the things I have mentioned above that does not assume you are an expert on VirtualBox?

[mpack]

My basic question is why is this process so incredibly difficult?

It isn't. The problem is that you have no understanding of the subject matter. Both your use and your criticism of the technology must be understood in that light.

What exactly are you saying should be done differently? Are you suggesting that VirtualBox should have a built in knowledge of any partitioning system and every filesystem used by every guest operating system you might choose to install in a VM? Do you consider that a practical suggestion? Do you know of any "more mature" VM platforms which do this?

Also, a little more research might have led you to CloneVDI. It does some of what you ask for, but it only handles the most popular cases (MBR primary partitions, FATx or EXTx or NTFS filesystems).

[jack-in-the-box]

Okay, bad question. What I should have asked is "why is this process being so difficult for me". I think you have perhaps misread my frustration for criticism. I am sorry that you have taken offence when none was intended. Yes, I am a lightweight VirtualBox user and have little depth with its many twists and turns. I am not in a position to criticize or even to suggest. I am only pointing out a rather long list if items that seem like they should be straightforward, but are giving me endless trouble. What I am trying to find out is whether this system is commonly known to be troublesome or if I am doing something fundamentally wrong. I am fully aware of the tradeoff between open source and commercial systems. Some very useful open source material is widely known to be troublesome, and there is nothing wrong with that. All of Linux was seriously troublesome when it first appeared, but over the years a lot of dedicated work from open source teams all over the world have smoothed over most of those troubles and almost anyone can now load and run Linux. What I would like to know is where VirtualBox is on that path. Are the troubles I am seeing expected or unexpected? Either answer is okay; it would just be less frustrating if I were expecting trouble.

[socratis]

I believe that you're looking at it from the wrong angle. You shouldn't be thinking about a "software" issue, you should be thinking about a "hardware" issue.

You see the only thing that VirtualBox (and other similar software) does is to provide you with a chassis. A (virtual) hard drive, a (virtual) CPU, a (virtual) graphics card and other (virtual) peripherals. What you do with the (virtual) chassis is up to you. You could install Windows, Linux, BSD, DOS, Minix, what-have-you, or if the chassis that you're building on says "Apple made", OSX.

Think how easy/difficult it would be to "resize" your physical hard drive. You'd have to buy a second bigger one, take the whole system offline, use a specialized software to boot from, copy sector-by-sector (or file by file) the smaller HD to the larger one and hope that the software that you're using is not tied to the serial number of your hard disk. And sacrifice a goat to the SCSI gods (that's mandatory I'm afraid).

Now, since this is a virtual procedure, some things are easier. Not a-click away mind you, simply easier. You are looking at the easier procedure. It's not more difficult just for you, it's a difficult process overall...