10

This question arose from “Is it safe to answer “erase disk and install Ubuntu” on a virtual machine?”.

Guest space from host:

What happens when the disk space gets larger than the unused disk space, perhaps not at start, but later, when the usage grows e.g. to 40 out of 50 GB and your main drive has only 40 GB space left? In other words, will the VM ever overwrite data, or will it report this? I do not think that the VM will ever overwrite data of the host, I just want to be sure.

Host space from guest:

And the other way round, what if the host disk wants to use space that is guaranteed to the guest, is there a chance that it can damage the guest somehow, and is it possible at all? Will the host just tell you that host space is limited due to that VM?

Guest space to guest:

Just an example from Oracle VirtualBox — or any similar VM software — installing Linux Mint guest on Windows 10 host, using “thin provisioning.” The installer tells me directly after the choice of the “Erase” option:

“If you continue, the changes listed below will be written to the disks. Otherwise, you will be able to make further changes manually. The partition tables of the following devices are changed: SCSI3 (0,0,0)(sda) The following partitions are going to be formatted: partition #1 of SCSI3 (0,0,0)(sda) as ext4.”

I have chosen “Continue” and nothing bad has happened. Probably, the message pops up because I have another VM already installed. It seems as if the VM can take space from another VM, is this possible?

This question is not restricted to the usage of Oracle VirtualBox; this question is meant as a general question about VMS in general, not excluding answers on VirtualBox of course.

Improve this question
4
  • 2
    Typically a whole harddisk as seen from the guest is stored as a normal, physical file on the host (expert users may use physical disks directly but that is rare). If the drive runs full so the file cannot expand, I would expect the guest to be told that the write operation failed.
    – Thorbjørn Ravn Andersen
    Dec 18, 2020 at 1:23
  • 2
    In Oracle Virtualbox, as soon as the host drive is full so that the write fails, the virtual machine is halted and a message box warning the user (and allowing to resume the VM after space is freed) is displayed, IIRC.
    – Mormegil
    Dec 18, 2020 at 10:49
  • 1
    Does your Virtualisation environment allow "thin provisioning" ? If yes, did you enable that ?
    – Criggie
    Dec 18, 2020 at 10:54
  • 1
    @Criggie According to "mass storage" info in Oracle VirtualBox, the vdi is "dynamically allocated", which is "thin provisioning" according to nakivo.com/blog/use-virtualbox-quick-overview. I think that the message pops up normally, see the answer of gronostaj. Strange that I do not remember it from the very first vm, only from the second.
    – questionto42
    Dec 18, 2020 at 19:46

6 Answers 6

Reset to default
2

Guest space to guest

On Linux Mint, using a VirtualBox, the installer tells me directly after the choice of the "Erase" option:

If you continue, the changes listed below will be written to the disks. Otherwise, you will be able to make further changes manually. The partition tables of the following devices are changed: SCSI3 (0,0,0)(sda) The following partitions are going to be formatted: partition #1 of SCSI3 (0,0,0)(sda) as ext4.

I have chosen "Continue" and nothing bad has happened. Probably, the message pops up because I have another VM already installed. I do not think that the VM will ever overwrite data of the host. It seems, though, that a VM can take space from another VM perhaps?

Virtual machines are completely self-contained. They are (broadly speaking) indistinguishable from a physical computer and don't know about each other unless you connect them somehow - just like physical computers.

That message is not caused by existence of another VM. It's a "sanity check" type of dialog. It asks you to double-check that installer's automatically made choices match your intentions.

I've experimentally confirmed that this message appears when installing Ubuntu 18.04 and 20.04 to an empty, non-partitioned drive.

Host space from guest

While from the inside a VM looks like a normal computer, from the outside (ie. host's perspective) it's just a bunch of files. Generally you'll have one file which describes VM's hardware configuration and one file for each virtual disk attached to the VM. So in most use cases, a VM consists of two files: one for the config and one for the disk.

Disk files can either be pre-allocated or dynamically allocated. Pre-allocated disk is created to take up amount of space equal to its capacity from the very beginning. It can improve performance slightly at the cost of consuming host's disk space for unused disk regions. If you don't have enough disk space for this, the process will fail while the VM is getting created but it's not running yet.

A dynamically allocated virtual disk file will grow as the guest is trying to write to its previously unused regions. The technical term for this is a sparse file. This is the case where host can indeed run out of disk space when guest is trying to write to its virtual disk. Nothing will be overwritten because it's just a typical case of a program trying to create a file too large to fit on the disk (the program being your VM software - the hypervisor). The fact that it's a virtual disk attached to a running VM is irrelevant, because from host's perspective it's a file no different than any other. The operating system's filesystem driver will simply deny writing to that file. How the hypervisor handles this is up to its implementation.

Guest space from host

Once again, for the host the virtual disk is just a file and it's subject to the same rules as any other file. Any process allowed to write to this file can make any modifications to it, unless this file is locked for exclusive writing by another process at the moment.

Improve this answer
1
  • 1
    Good answer for the "usual" way to do it. Note, however, that VM software (if the user running it has sufficient permission) can generally use any file as the boot disk, including the raw vie of any drive, including the entire boot drive (say /dev/sda on Linux). Read-only direct access to a physical CD-ROM drive is fairly common; read-write access to the whole boot disk is equally possible, although it's VERY DANGEROUS. But if the operator is careful to never mount any partition from the other side when either host or guest has it mounted read-write already, it should work.
    – david
    Dec 19, 2020 at 15:22
15

"Ever" is a very long time, and if someone knows how to access other Guest or Host from a VM (I do know how), then yes, of course it is possible.

However, erase space or even a whole machine will not overwrite other systems outside its bounds.

Windows and Linux guests delete unused space from time to time with no issues.

I compact Virtual Disks (Windows and Linux) to recover deleted VM space with no issue.

What you want to do (expand a virtual disk or delete space inside a virtual disk) will not harm a host system or other guest.

Just make sure you do not run out of real disk space. That can cause issues to any system.

Anecdotal note: The first time I built a VM (Windows 98 which I still have on VMware Workstation Version 1 on a Windows NT4 Workstation host), the Windows 98 setup said "I am going to format your hard drive"

I sure did pause before saying OK, so your question is most reasonable and well put.

Improve this answer
2
  • 6
    "I am going to format your hard drive" Even though that OS had Windows for many years already, it nevertheless had never looked through them to see the beauty of the Cosmos out there.
    – Hastur
    Dec 18, 2020 at 11:06
  • 1
    There was one time I created a VM with only a few megs of disk space (less than 1 Gb), on which I tried to install Kali Linux. At some point, it said the installation failed (because it ran out of space). When I told it to resume installation, somehow, it managed to crash my entire computer (BSoD). I still had plenty of real disk space, but I guess it tried to go beyond its boundary of virtual disk.
    – Clockwork
    Dec 19, 2020 at 12:48
14

Can a virtual machine (VM) ever overwrite the host disk,

Virtual Machine hosts have had security holes that let a guest break out of its VM, and history and experience tells us that this will happen again.

Once the guest breaks out of the VM, it can do whatever the host can do.

or a host a guest disk,

The host always has full control, it can do whatever it wants.

or a guest another guest disk?

Once a guest manages to break out of the VM, it can do whatever the host can do, so this reduces to #2.

Obviously, a simple configuration error where the same virtual disk is attached in writeable mode to multiple guest VMs, or where a physical disk of the host is attached in passthrough mode to a guest VM breaks down all protection as well, without needing a somewhat esoteric security bug.

Improve this answer
0
11

It really depends on how you configure things on the host side to know if there's going to be trouble down the road.

By default, if you create a VM with storage, a file is created that hosts the storage for this VM. In these cases, the guest cannot make any changes to the host, and in case of a dynamically sized disk, once the disk wants to write data that is larger than the allocated space because the host's disk is full, a write error occurs within the guest, that's it.

The problem here is that writing fails but doesn't give a clear meaning in the guest. It can be harder to troubleshoot, but it will be something like: "Error writing to file. Make sure the disk is writable. Even if your disk says enough space is full it will just not allow any writes. If you then inspect the host, you'll find out the disk is full. On the host side, you get a clear message that the disk is full because the host can actually see it, just not the guest.

Now, in which situation can a guest actually destroy data on a host's drive?

It is possible to assign a physical disk as storage medium for a VM. If this physical disk is also used by the system itself, you basically grant the guest access to the host in a way that was not intended. It is not what anyone should do, but I'm just naming it because it actually is possible.

Guest space to the guest

Even though the guest thinks its on a normal computer, it is all a virtual environment. Because the guest cannot actually tell it is inside a virtual environment, the messages you see on screen will not reflect that either. If it says: I'm going to delete all your data on your disk, it is only all the data the guest has access to which is what you defined in the host. Whether this is a virtual disk or physical disk as pass through, to the guest it is exactly the same.

Improve this answer
11
  • 3
    @jpaugh "grant [the guest] access to the host in a way that was not intended"
    – Herohtar
    Dec 18, 2020 at 5:51
  • 2
    If you were to assign a physical disk to a VM while at the same time using it with the host system, then I would say you're very much intending to let the VM use the full disk. It's not that different from having multiple operating systems installed and dual booting between them, except that without the VM in between you have to take care to configure them not to trash each other and really have no other option. With a VM there's no reason to give that kind of shared access to the guests, unless you want them to have it.
    – ilkkachu
    Dec 18, 2020 at 12:30
  • 3
    @ilkkachu oh, I totally agree with you, the reason why I mention this, is in case someone else setup the VM system and you assume, because its a VM you cannot damage it, and then find out someone else set it up using a physical disk for whatever reason and now destroyed all data. I wrote it more as "better mention something that most likely won't cause issues than to not mention it at all".
    – LPChip
    Dec 18, 2020 at 12:32
  • 1
    @LPChip, I would probably still only give the VM some partitions of the whole, at least if the host system is also installed on the same disk. Of course if it's just all data the VM needs, then that's not an issue, and if you can pass it through on a lower level than a virtual disk would be, there might be speed gains. Maybe you meant exactly that sort of passthrough anyway.
    – ilkkachu
    Dec 18, 2020 at 13:30
  • 3
    @ilkkachu I did. ;)
    – LPChip
    Dec 18, 2020 at 14:13
4

Short answer is no, the virtual machine can't overwrite the host system. Where the virtual machine sees a hard drive, the host computer just sees a file. The VM and its files are under control from the host. If the VM drive is allowed to grow without bound and the VM drive got too big, then eventually the host would complain that its drive is full but it's not going to start overwriting your host. You can share a folder or a drive between the host and the VM and then technically it could overwrite some things but you would have to set that up intentionally. So go ahead and format the virtual drive of your virtual machine. One tip if you need to be on the absolute safe side is to make a backup of your host first, this is always a good practice anyway because you never know when a drive just crashes and is forever lost.

Improve this answer
1
  • 2
    Usually it can't happen, but mistakes take place sometimes. Not too long ago, qemu had an autodetect feature so it could figure out if something was a raw disk vs a qcow2 or vmdk. But that means that if you take over a VM, you can write a qcow2 header describing it as containing differences from a different file on the host you want to read. Reboot the guest after writing that header, and volia, you can read the backing store.
    – Charles Duffy
    Dec 18, 2020 at 16:41
2

Maybe - it thoroughly depends on your environment and how you set it up.

At work we had some Dell Compellent 4020 SANs acting as storage for a pool of Xenservers. There were 8 servers running around 60 VMs with 2x 10 Gb links to the twin controllers on the SAN. The SAN had around 20TB of fast disk, offering around 17 TB usable. Decent quality enterprise gear.

We'd fumbled our way through the setup, and naively permitted the SAN to report more free space than it really had. All those VMs had more than 17TB allocated, but they weren't using it all; we're good. This is thin-provisioning.

When we hit that limit of 17TB in use, every running VM failed to write. Normally that would make the VM crash or act like its disk was unplugged.

But on this dippy SAN it decided to corrupt every disk for every running and stopped VM. We had to crash-rebuild about 40 virtual machines immediately, and there was no chance of recovering any files.

So its eminently possible for a VM to stuff up things outside its allocated resources, depending on how you chose to set it up and what protections/traps your solution offers.

In an ideal world, your VM disk would get allocated 100%, so a 20GB disk would immediately occupy 20GB of your real disk space and not be able to go over that.

Improve this answer
2
  • 1
    Oracle VirtualBox is protected from this to happen though, but yes I have seen the above happen in other solutions. I think its a good answer, just not applicable to this particular question. Given that not everyone seeking answers will be using VirtualBox, I'm not going to down-vote you.
    – LPChip
    Dec 18, 2020 at 22:07
  • 1
    @LPChip This question was not meant to be restricted to VirtualBox. Sorry for being unclear, it was meant as a general question, with VirtualBox just as the triggering example to ask it. I thought the question to be independent from a VM program. If it is not, that is also an answer, but I did not expect it at the time of asking. That is why I have probably already received a couple of downvotes. The question is edited.
    – questionto42
    Dec 19, 2020 at 19:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .