GNOME Bugzilla – Bug 664294
Inability to launch multiple VMs
Last modified: 2016-03-31 13:59:08 UTC
While you can 'create' multiple VMs from boxes already, currently: 1. While the first VM will be started/launched correctly, the subsequent VMs will only be created but not launched/run. 2. Clicking on the icon/box of 'unlaunched' VM will full-screen the first (running) VM. Its probably a bug in libvirt(-glib) but before investigating further, I thought I should put it here.
Turns out that main culprit libvirt, which choosing the same SPICE port for all VMs.
Created attachment 201628 [details] [review] Make App.collection public
Created attachment 201629 [details] [review] Add Collection.list_items()
Created attachment 201630 [details] [review] Allocate unique SPICE port If we leave this for libvirt, it will allocate same port for every domain. This patch ensures every domain created gets a new port.
These patches ensures allocation of unique spice port for VMs but still not across all boxes using spice.
Review of attachment 201628 [details] [review]: no need to make it a seperate patch really, micro-commits with 0 clear benefits aren't helping, quite the contrary.
Review of attachment 201629 [details] [review]: without explanation, I find it useless. Please explain why you can't just iterate of Collection GenericArray<CollectionItem> items (assuming it's made public)
Review of attachment 201630 [details] [review]: Ok, I would prefer we teach libvirt to allocate ports but that approach sounds fine for me atm.
(In reply to comment #6) > Review of attachment 201628 [details] [review]: > > no need to make it a seperate patch really, micro-commits with 0 clear benefits > aren't helping, quite the contrary. The goal is not to achieve micro-commits, thats a side-affect. The goal is to try to always keep separate changes into separate commits for following two reaons: 1. Its easy to later revert 'individual' changes. 2. It keeps the history clear/clean. Also its easier to just follow this rule without wasting time on measuring benefits.
(In reply to comment #7) > Review of attachment 201629 [details] [review]: > > without explanation, I find it useless. Please explain why you can't just > iterate of Collection GenericArray<CollectionItem> items (assuming it's made > public) 1. GenericArray is not iteratable. 2. This is in line with you: a. keeping this private b. providing a method to add items (the same can go for that too, no?)
- I want to know why a commit makes something public. If there is no user, the commit has no meaning. - GenericArray can be iterated foreach (var e in array.data) - Adding and removing items needs to be signaled and processed, listing no.
ho, and if I revert the "public" patch it breaks. If I revert the whole patch (assuming no further changes has been made), it still works. Also it makes bisect faster. (so please, don't do it just because you can)
(In reply to comment #11) > - I want to know why a commit makes something public. If there is no user, the > commit has no meaning. Sure but there is a user as you can see in later commit. > - GenericArray can be iterated foreach (var e in array.data) > > - Adding and removing items needs to be signaled and processed, listing no. Didn't know/notice that. I'll change accordingly, then.
(In reply to comment #12) > ho, and if I revert the "public" patch it breaks. If I revert the whole patch > (assuming no further changes has been made), it still works. Commits always depend on other commits, thats normal. The dependencies change over time. > Also it makes bisect faster. I imagine lesser commits will always make most git operations faster. > (so please, don't do it just because you can) Actually its more difficult to divide them more. I have learnt to follow this golden rule over the years but if you don't like it, I guess I can make exception to this one as well.
If you ask me, I tell you what I dislike. I think I made you arguments moot. If you think you don't need review or do not appreciate my comments, well.. don't ask :)
(In reply to comment #15) > If you ask me, I tell you what I dislike. I think I made you arguments moot. If > you think you don't need review or do not appreciate my comments, well.. don't > ask :) I certainly do need your review and appreciate your input, just can't guarantee I always will. :)
Pushed fix with review comments addressed.