VirtualBox

Custom Query (16363 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (1507 - 1509 of 16363)

Ticket Resolution Summary Owner Reporter
#11344 fixed Extending VDI size destroys XFS filesystem => fixed in svn Grimeton
Description

Hello,

after resizing a VDI image, while the VM was offline, from 1TB to 1.3TB, the XFS filesystem inside has been destroyed. I talked to Eric Sandeen, from the XFS people, and we ran some tests and in the end the filesystem will always be destroyed.

We're testing on 4.2.4 and 4.2.6 on Linux (amd64) and OS X (10.8.x) hosts with this procedure:

  • Power off the VM
  • Create a virtual harddisk with 1TB space as VDI
  • Attach the virtual harddisk to a port on the sata controller
  • Power up the VM
  • Create an XFS filesystem on top of the drive (NO PARTITIONS)
  • Mount the filesystem and create some directories/files on it like this:

cd /mntpoint && for i in {1..30}; do mkdir $i; cd $i; for j in {a..z}; do touch $j; done; cd ..; done

  • Unmount the fs
  • Power down the machine
  • Change the VDI size like this: vboxmanage modifyhd /path/to/vdi --resize 1331000
  • Power the VM on again
  • Mount the fs again (no error yet!)
  • do a "ls /mountpoint"
  • see lots of errors
  • run xfs_repair -n and see lots of errors.

So far we can't say if it is a Virtualbox or an XFS issue or a result of the combination of the two. We tested with different image sizes and always got a destroyed filesystem in the end.

Eric will look into this and keep me updated on it.

So far just the warning: DO NOT RESIZE the Virtualbox VDI image if you have XFS inside it.

Happy new year!

KR,

Grimeton

#11481 duplicate Weird behaviour Grimeton
Description

Hello,

I know the topic isn't very clear, but that's what this whole thing is:

Sometimes processes in the guest are producing segfaults or exit without any reasons and fail. I can see this on Linux and on OS X hosts. Windows XP (guest) is sometimes affected, Windows 7 (guest) doesn't make it past the Windows Update installs without having the update service killed multiple times. It sometimes even produces a blue screen when you activate the guest (Windows license activation).

The main reason I didn't report the problem earlier was that I am unable to reproduce it. A few days ago someone else reported similar behaviour of his VMs on a Windows 7 Host, which could be solved by the same procedure I'm going to write about later, so I decided to file a bug report.

What happens is that the processes inside the guests fail. If you power the guest down and start it again (no reboot, new instance of Virtualbox), you still get the same error inside the guest. The only way around it, ist to power down the "broken" guest, start another VM, so that it allocates memory on the host, and then start the guest again (while the other VM is still running). After doing this, the guest starts to work properly again, as it now uses a different part of the host's memory (afaik).

In Windows 7 the update service fails, or .NET assemblies stop working from one second to another. On Linux guest you get all kinds of segfaults in all processes. Interesting is that you don't get a kernel core dump, all processes reside in user land. It's also independent of the memory the guest can use. I see it from machines with less than 256mb of Memory and up to 8GB and more of Memory.

The memory on my machines has been checked and everything is fine.

I'm sorry that I don't have any further information. If you have questions feel free to contact me.

Attachements: IRC log of #vbox

KR,

Oliver

#12779 worksforme BLKCACHE_IOERR on Fedora Linux F20 3.13.5-200.fc20.x86_64 Groovie
Description

Dear sirs,

after upgrading to 3.13.5-200.fc20.x86_64 i ran into problems with my USP3 mounted SSD drive. This did not happened before, so it should be a problem with the recent kernel update.

[configuration]: Host: Fedora Linux F20 VM: Windows 7 with

  • a mapped C: drive vmdk file
  • a mounted c:\usp device over usb3 as a map device

Before you ask: why this configuration: The portable ssd device contains my development environment, that i share between home and my office. It worked good before the recent kernel update.

After some time, i'll get a:

Während der Ausführung der virtuellen Maschine ist ein Fehler aufgetreten. Einzelheiten werden unten gezeigt. Sie können versuchen, den angezeigten Fehler zu beheben und mit der Ausführung fortzufahren.

The I/O cache encountered an error while updating data in medium "ahci-0-1" (rc=VERR_DEV_IO_ERROR). Make sure there is enough free space on the disk and that the disk is working properly. Operation can be resumed afterwards.

Fehler ID: BLKCACHE_IOERR Dringlichkeit:Normaler Fehler

There is enough disk space on all devives (approx 16 to 30% usage).

Batch Modify
Note: See TracBatchModify for help on using batch modify.
Note: See TracQuery for help on using queries.

© 2024 Oracle Support Privacy / Do Not Sell My Info Terms of Use Trademark Policy