Custom Query (16363 matches)
Results (1156 - 1158 of 16363)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #2000 | fixed | Optional rollbackwards when deleting a snapshot | ||
| Description |
This scenario comes up quite a lot when discussing backup strategies for VMs, where the end users require minimum downtime. A small change to the algo for deletion of middle snapshots will allow effective non-stop backups. Consider the scenario where we have a running VM: Snapshot 1 BaseSystem.vdi R/O 10,356 blocks (1MB allocation blocks)
Current {xxxxxxx1}.vdi R/W 1,340 blocks
We now do a live snapshot with hangs the VM for ~20sec. (I am omitting the SAV files from this discussion for simplicity, but these don't materially impact timings): Snapshot 1 BaseSystem.vdi R/O 10,356 blocks
Snapshot 2 {xxxxxxx1}.vdi R/0 1,340 blocks
Current {xxxxxxx2}.vdi R/W 0 blocks
We can do a D/R restore from Snapshot 1 + 2, and since the BaseVDI has already been backed up, the (only large file) {xxxxxxx1}.vdi that needs to be gzipped (say) which will take less than a minute, so in a reasonably quiescent system Current ({xxxxxxx2}.vdi) will only have perhaps 10 blocks in it. So now we wish to delete Snapshot 2 to restore our status quo: Snapshot 1 BaseSystem.vdi R/O 10,356 blocks
Snapshot 2 {xxxxxxx1}.vdi R/0 1,340 blocks <=== To be deleted.
Current {xxxxxxx2}.vdi R/W 10 blocks
Currently to do this you need to do 3 steps:
My point is two fold:
This approach of allowing dynamic backwards deletion of snapshots will allow VMs to be backed up on the fly with two pauses of perhaps 15 + a few seconds, which for most systems can be considered non-stop. If we allow a savestate -nomemory option (that is recovery to this snapshot will force a reboot -- which is probably fine for recovery purposes, the pause will fall to seconds. The current functionality requires stopping the system for an number of minutes. It is also fairly trivial to do this back copy in three steps to ensure that the VDI is always maintains integrity. PS. You should allow Host and Guest types N/A |
|||
| #2001 | fixed | Virtualbox 1.6.4 segfault when displayed via ssh/X11forward => Fixed in 2.0.4 | ||
| Description |
During my testing of Virtualbox 1.6.4 (binary edition) I have noticed a problem when connecting to the virtualbox host via ssh with X11 forwarding active. Let's say machine "Ahost" is where I'm sitting and "Bhost" is the machine with virtualbox installed. On Ahost I do ssh -Y Bhost which gets me a prompt on Bhost. DISPLAY is set to "localhost:11.0" which is the proxy set up by ssh. I then start Virtualbox which runs as expected. I select the desired VM and "start" it. At this point it *might* run - if not, the VM status becomes "Aborted" and dmesg reports VirtualBox[23317]: segfault at 0 ip 00000000 sp bfb37bac error 4 in VirtualBox[8048000+20f000] If the VM starts then everything runs apparently without trouble until I do a shutdown/poweroff of the VM. The guest OS shuts down normally and the window disappears, but the VM status is again reported as "Aborted". This time dmesg reports VirtualBox[23511]: segfault at b28db1c8 ip b5d67440 sp bfdd21d0 error 4 in libSDL-1.2.so.0.11.2[b5d4f000+66000] None of these segfaults occur if I run Virtualbox directly from an xsession running on Bhost (DISPLAY set to ":0.0"). However, curiously enough if I do xhost + ssh Bhost on Ahost, and then do export DISPLAY=Ahost:0.0 Virtualbox in the resulting shell running on Bhost the segfaults do not occur and everything seems to perform as expected. Finally, doing ssh -Y Bhost *on Bhost* and then running "Virtualbox" gives rise to the problems. So in other words, it is not the remote display itself which causes the problem, but simply the act of displaying on an X display created by ssh's X11 forwarding feature. Has anyone else seen this? Are there any known fixes? I'm willing to run tests to assist tracking this down. Both Ahost and Bhost are running Slackware 12.1 with a 2.6.26 kernel.
Regards
|
|||
| #2003 | fixed | VirtualBox VM terminates using Seamless Mode - Ubuntu GUEST - Mac OS X HOST | ||
| Description |
Mac OS X.5.4 HOST Ubuntu GUEST Using Seamless mode kills the VirtualBox VM.app ie. resize a window... *Poof* |
|||

