Does openSUSE 42.1 guest not play well with dynamically allocated VDIs?

[HeadScratcher]

Yesterday I installed openSUSE 42.1 LEAP as a guest under Linux for the third time. I specified dynamically allocated disks for the first two installations, and now suspect that this isn't a good virtualbox recipe with openSUSE 42.1. Both installations delivered "no more room in home directory" messages after attempting patch updates, and refused to function thereafter. I wasn't sophisticated enough to repair the mess, and wound up recreating the virtual machine.

This time I specified a fixed disk size.

This message:

viewtopic.php?f=6&t=77618&p=362815&hili ... SE#p362815

sounds like user LSV ran into similar problems. I'm curious what others think. Do dynamically allocated disks work better with some guests than with others?

[Perryg]

Stick with the defaults for the best experience. You can increase the drive size at install ( I usually select 50gb for guests that I intend to keep and use ). The best thing that you can do when installing the guest is to make sure to *NOT* use LVM when creating a reliable/permanent guest until you learn how to work with it. VirtualBox has nothing to do with the guests partitions or formats.

[HeadScratcher]

Thanks for the feedback, PerryG. I've forgotten what the defaults were for the openSUSE 64-bit installation.

The two previous VDIs with dynamically-allocated disks both died with similar 'no room in the home directory' messages when the system tried to apply just-downloaded patches. To this inexperienced VirtualBox user, that suggested that openSUSE 42.1 LEAP didn't understand dynamic allocation, or that VirtualBox didn't know how to explain dynamic allocation to the distro.

I'll see how long the fixed disk allocation lives, and will try to remember to update this thread with news good or bad.

[socratis]

Operating systems on a VM do not understand dynamic allocation, because they are not aware of it. None of them.

I think that it is you that does not understand the difference between dynamic and fixed. You should definitely read the relevant chapter in the User Manual. Even if you use the same size, but you set it to fixed, you're going to run into exactly the same problem. That's why Perry's advice was:

make sure to *NOT* use LVM when creating a reliable/permanent guest until you learn how to work with it. VirtualBox has nothing to do with the guests partitions or formats.

[HeadScratcher]

You may very well be correct; I see that you have 3,800+ posts here, and this is my tenth.

I just downloaded the .pdf of the manual, and found the most relevant information on fixed vs dynamic in sections 5.2 -- https://www.virtualbox.org/manual/ch05.html#vdidetails -- and 5.4. I didn't see anything in these sections to show me a configuration error. Is there another chapter I should be studying, or another document about Virtual Box?

A word search in the manual for LVM or logical volume turned up only section 8.13 -- VBoxManage controlvm -- as a candidate. I haven't used VBoxManage, so presume that this isn't relevant to me.

I just made a note on my calendar to update this thread at the end of June, if the openSUSE installation lives, or earlier, if it perishes as quickly as its siblings did.

[socratis]

Exactly. Chapter 5.2 is the one that describes the differences between dynamic and fixed. The basic difference is a simple one; fixed allocates the whole virtual disk from the beginning, dynamic does it as needed. The bottom line is the same; the guest sees the same HD and has no clue if it's fixed or dynamic.

Now, the next thing is to look at the LVM documentation on how the partitions are allocated. So, for example. on a computer with 4 GB of RAM, how much space of a 10GB HD is actually available for the user's use. Answer: not 10GB.

[Perryg]

Please note that dynamic allows for the guest drive to grow, which is true, but not past the initial size you select at creation. Just like on metal you would need to replace the drive if you want to increase the physical size. VirtualBox ( VBoxManage modifymedium ) however allows you to expand that size is the only difference but just like on metal you would need to adjust the partitions to include this new size. Something that eludes most people and one that VirtualBox has no direct control over. You do this from within the guest. Or booting to a partition editor to expand the primary partition depending on the guest and format that you chose at installation of the guest.

So bottom line is if you want to use LVM you must learn how to adjust those partitions with the Logical Volume Manager of the guest if they end up being too small. Simpler method is to use standard partitions and a partition manager/editor like gParted to do the adjusting for most folks.

[HeadScratcher]

Thanks for the responses, socratis and Perry G. I now wish I'd taken better notes during previous openSUSE-in-VB efforts. I think -- but am not sure -- that I specified a small size for the first dynamically allocated disk, and a 30+ gig size for the second (also dynamically allocated).

I think that the resulting VDI in the second install was around twelve gigs, but grew no larger, and perished with the above-described 'no room in home directory' message during the patch update.

I shall now humbly bow out of this thread, until:

--> my third, current, fixed-disk-size-specifying openSUSE installation goes south,

or

--> the end of June,

whichever comes first. I hope it's the end of June!

[Perryg]

Don't miss out on what you said. The /home folder was full. That is not the entire drive but the way the OS setup the LVM /home partition. Had you selected to not install using LVM then you would not have had this issue. Just to point out what most miss.

[smithlar]

openSUSE 42.1 uses BTRFS as the root file system by default.
BTRFS takes file system snapshots as the disk changes - updates are installed, etc
I believe the recommended minimum root file system size for openSUSE with BTRFS is 40 GB.
More details can be found on the openSUSE web site.

[HeadScratcher]

I don't think I'll have to wait until the end of the month to post a follow-up. (long sigh)

openSUSE wanted to download many updates when I fired up the virtual OS yesterday. Suspicious instinct prompted a check of the file system. What I believe is the root directory -- and yes, that does show what a Linux ignoramus I still am! -- had only 70 mb. The home directory had a comfy 15.8 gigs.

(To be sure I'm comparing apples to apples: under 'Devices' in the oenSUSE file manager, the virtual OS shows a 12 gig HD and a 16 gig HD. The 12 gig HD is the one that was filling up. The 16 gig HD had 15.8 gigs free.

I cleared tmp files, installed BleachBit, watched the virtual OS perish as BleachBit failed to find sufficient room to complete the install. Essentially the same problem that prompted the first post in this thread.

Fortunately, I had a back-up of the VDI file. I copied it back over, then checked this thread, and saw Smithlar's post.

AH HA!

I googled BTRFS and openSUSE, found this thread: https://forums.opensuse.org/showthread. ... tting-full that mentioned a utility, Snapper. I loaded Snapper in openSUSE, found many snapshots, deleted a bunch of them, took another look at the root directory.

Lots of space now. Problem solved, I think. I may do further research to figure out how to delete Snapper entirely.

I guess I should expect whacks on the head of this sort while experimenting in VirtualBox with high-powered OSs that I hardly understand.

Smithlar, I'm grateful that you contributed to this thread. I should dedicate my virtual openSUSE installation to you! <g>

[HeadScratcher]

(After more configuration/tinkering) I'm now almost certain that the installed-by-default space-devouring openSUSE utility 'snapper' was to blame for the woes that started this thread.

I followed user Miuku's instructions at https://forums.opensuse.org/showthread. ... ile-System to ditch Snapper. To quote the highlights:

From a root prompt:

snapper list
snapper delete 1-x (where x is the last snapshot in the list)

Then:

zypper rm snapper snapper-zypp-plugin yast2-snapper grub2-snapper-plugin

to dump the program.

After that, I went into openSUSE's YAST (acronym for Yet Another Setup Tool), searched for Snapper and marked Snapper-related programs as 'taboo,' to insure they won't try to reinstall.

I now have almost 5 gigs in the root directory, which is more than I had when I installed the virtual OS, and will be plenty for my purposes.

Problem solved.

[HeadScratcher]

I feel self-conscious about updating a thread after nearly two years away from it, but for the benefit of others who may deal with similar problems:

I have now successfully installed and maintained openSUSE Leap 42.1, 42.2 and 42.3 VMs in VirtualBox, without the issues that prompted this post in 2016. PerryG and socratis were proven correct; dynamically allocated storage has worked just fine; I never needed to specify fixed storage.

I believe that the key is killing Snapper via the steps described above.