After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 760890 - Allow "exporting" a VM
Allow "exporting" a VM
Status: RESOLVED WONTFIX
Product: gnome-boxes
Classification: Applications
Component: general
unspecified
Other Linux
: Normal enhancement
: --
Assigned To: GNOME Boxes maintainer(s)
GNOME Boxes maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2016-01-20 15:10 UTC by Emmanuele Bassi (:ebassi)
Modified: 2016-09-20 08:15 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Emmanuele Bassi (:ebassi) 2016-01-20 15:10:25 UTC
Boxes copies all VMs under $HOME by default.

This means that, on modern systems, you'll get a bunch of VMs on a file system running on a SSD.

While this is all well and good for mostly "read only" VMs, it's not so well for VMs with highly changing file systems; for instance, developers VMs.

Sure, I could use virt-manager and then connect Boxes to it; but I thoroughly consider launching virt-manager a complete defeat of the purpose, and I'd rather run VirtualBox than that, if I have to deal with an unforgiving and cryptic UI.

One way to work around this issue would be for Boxes to allow "exporting" a VM to a separate location on disk; and then use that location instead of XDG_DATA_HOME/gnome-boxes. Internally, the "exporting" could be done by moving the VM to a desired folder, and then creating a symlink into the application's data directory. If the link is broken, the VM is hidden or disabled.
Comment 1 Zeeshan Ali 2016-01-20 19:12:36 UTC

*** This bug has been marked as a duplicate of bug 677691 ***
Comment 2 Zeeshan Ali 2016-01-20 19:15:55 UTC
(In reply to Zeeshan Ali (Khattak) from comment #1)
> 
> *** This bug has been marked as a duplicate of bug 677691 ***

Actually this is different and I don't see this as a compelling use case. This sounds very much like an advanced use case. Surely such advanced users can move the image file(s) and symlink themselves?
Comment 3 Emmanuele Bassi (:ebassi) 2016-01-20 20:15:29 UTC
(In reply to Zeeshan Ali (Khattak) from comment #2)
> (In reply to Zeeshan Ali (Khattak) from comment #1)
> > 
> > *** This bug has been marked as a duplicate of bug 677691 ***
> 
> Actually this is different and I don't see this as a compelling use case.
> This sounds very much like an advanced use case. Surely such advanced users
> can move the image file(s) and symlink themselves?

Sure. I can also use a magnet and a steady hand, and move the bits myself from the disk platter. Or use a butterfly, air current, and cosmic rays, for that matter. I thought we were trying to make a more user friendly system, tho.

Since Boxes hides the VM on the file system (for a good reason), Boxes should provide a way to get to those files in the first place.
Comment 4 Zeeshan Ali 2016-01-21 12:53:20 UTC
(In reply to Emmanuele Bassi (:ebassi) from comment #3)
> (In reply to Zeeshan Ali (Khattak) from comment #2)
> > (In reply to Zeeshan Ali (Khattak) from comment #1)
> > > 
> > > *** This bug has been marked as a duplicate of bug 677691 ***
> > 
> > Actually this is different and I don't see this as a compelling use case.
> > This sounds very much like an advanced use case. Surely such advanced users
> > can move the image file(s) and symlink themselves?
> 
> Sure. I can also use a magnet and a steady hand, and move the bits myself
> from the disk platter. Or use a butterfly, air current, and cosmic rays, for
> that matter. I thought we were trying to make a more user friendly system,
> tho.

Friendly, yes but that doesn't mean we need to support all advanced use cases. The use case needs to be helpful to enough people and preferably not expose internal details, like disk images and where they are stored.

> Since Boxes hides the VM on the file system (for a good reason), Boxes
> should provide a way to get to those files in the first place.

I'm not even sure what you are asking for here. If you need exporting, bug#677691 is what you want.
Comment 5 Emmanuele Bassi (:ebassi) 2016-01-26 14:15:28 UTC
(In reply to Zeeshan Ali (Khattak) from comment #4)
> (In reply to Emmanuele Bassi (:ebassi) from comment #3)
> > (In reply to Zeeshan Ali (Khattak) from comment #2)
> > > (In reply to Zeeshan Ali (Khattak) from comment #1)
> > > > 
> > > > *** This bug has been marked as a duplicate of bug 677691 ***
> > > 
> > > Actually this is different and I don't see this as a compelling use case.
> > > This sounds very much like an advanced use case. Surely such advanced users
> > > can move the image file(s) and symlink themselves?
> > 
> > Sure. I can also use a magnet and a steady hand, and move the bits myself
> > from the disk platter. Or use a butterfly, air current, and cosmic rays, for
> > that matter. I thought we were trying to make a more user friendly system,
> > tho.
> 
> Friendly, yes but that doesn't mean we need to support all advanced use
> cases. The use case needs to be helpful to enough people and preferably not
> expose internal details, like disk images and where they are stored.

This is only an internal detail because of a choice made by Boxes; there are valid reasons to have your VMs on a removable hard drive, or on a separate, spinning rust drive — as I discovered when using VMs to develop for my day job was a determining factor in eating my SSD.

I'm suggesting to have a UI that lets you "migrate" the location of the VM on a separate volume. It does not have to be fancy, or complicated. Just a file chooser button that lets you set the location of the VM after it has been created.

Anyway, yes: bug 667691 seems to be what I want.