Xen ballooning problem.
Locked
 
|
Hello.
Is it true that "Xen ballooning" has some problems? For example, when it dedicate memory to VMs then it can't release it and back it to the host and it is a reason for migrate from Xen to KVM. Thank you. _______________________________________________ Xen-users mailing list [hidden email] https://lists.xenproject.org/mailman/listinfo/xen-users |
|
|
Hi,
On Fri, Dec 15, 2017 at 01:28:22PM +0000, Jason Long wrote: > Hello. > Is it true that "Xen ballooning" has some problems? For example, when it dedicate memory to VMs then it can't release it and back it to the host and it is a reason for migrate from Xen to KVM. > > Thank you. I have found a few combinations of xen/kernel which don't work well but otherwise I find it works for my case. Currently xen 4.9.1, 4.1.47 dom0 kernel, mix of Ubuntu 16.04 4.4 and 4.14 kernels in pv guests. I use the tmem module to automatically balloon the guest up/down as memory pressure changes. James _______________________________________________ Xen-users mailing list [hidden email] https://lists.xenproject.org/mailman/listinfo/xen-users |
|
|
In reply to this post by Jason Long
Can it work well? I mean is release the memory and back it to host.
-------------------------------------------- On Fri, 12/15/17, James Dingwall <[hidden email]> wrote: Subject: Re: [Xen-users] Xen ballooning problem. To: "Jason Long" <[hidden email]> Cc: [hidden email] Date: Friday, December 15, 2017, 5:29 PM Hi, On Fri, Dec 15, 2017 at 01:28:22PM +0000, Jason Long wrote: > Hello. > Is it true that "Xen ballooning" has some problems? For example, when it dedicate memory to VMs then it can't release it and back it to the host and it is a reason for migrate from Xen to KVM. > > Thank you. I have found a few combinations of xen/kernel which don't work well but otherwise I find it works for my case. Currently xen 4.9.1, 4.1.47 dom0 kernel, mix of Ubuntu 16.04 4.4 and 4.14 kernels in pv guests. I use the tmem module to automatically balloon the guest up/down as memory pressure changes. James -----Inline Attachment Follows----- _______________________________________________ Xen-users mailing list [hidden email] https://lists.xenproject.org/mailman/listinfo/xen-users |
|
|
Jason, Yes, I'm afraid it's true. This does in your case constitute a reason to migrate from Xen to KVM. If along with this you decide to migrate from the Xen-users mailing list to somewhere else, we'll all certainly be sorry to see you go, but we understand that it's a sacrifice you might be willing to make and wish you all the best of luck with your transition. Regards, On Fri, Dec 15, 2017 at 10:18 PM, Jason Long <[hidden email]> wrote: Can it work well? I mean is release the memory and back it to host. _______________________________________________ Xen-users mailing list [hidden email] https://lists.xenproject.org/mailman/listinfo/xen-users |
|
|
In reply to this post by Jason Long
Hi Jason,
On Fri, Dec 15, 2017 at 09:18:14PM +0000, Jason Long wrote: > Can it work well? I mean is release the memory and back it to host. If I understand correctly you want to take memory from one running guest and then assign it to another? Yes, this is works. The tmem module helps you do this automatically but as an example you can also do: You want to start guest 3 but you only have 512M free memory, you are happy to take 256M from guests 1 & 2: guest 1: memory = 1024 guest 2: memory = 1024 guest 3: memory = 1024 xl mem-set guest1 768 xl mem-set guest2 768 xl create guest3 James > -------------------------------------------- > On Fri, 12/15/17, James Dingwall <[hidden email]> wrote: > > Subject: Re: [Xen-users] Xen ballooning problem. > To: "Jason Long" <[hidden email]> > Cc: [hidden email] > Date: Friday, December 15, 2017, 5:29 PM > > Hi, > > On Fri, Dec 15, 2017 at > 01:28:22PM +0000, Jason Long wrote: > > > Hello. > > Is it true that "Xen > ballooning" has some problems? For example, when it > dedicate memory to VMs then it can't release it and back > it to the host and it is a reason for migrate from Xen to > KVM. > > > > Thank > you. > > I have found a > few combinations of xen/kernel which don't work well but > otherwise I find it works for my case. > Currently xen 4.9.1, 4.1.47 dom0 kernel, mix of > Ubuntu 16.04 4.4 and 4.14 kernels in pv guests. I use the > tmem > module to automatically balloon the > guest up/down as memory pressure changes. > > James > > -----Inline Attachment Follows----- > > > > _______________________________________________ > Xen-users mailing list > [hidden email] > https://lists.xenproject.org/mailman/listinfo/xen-users _______________________________________________ Xen-users mailing list [hidden email] https://lists.xenproject.org/mailman/listinfo/xen-users |
|
|
Thank you for your reply but I mean is "KVM is also the better option for memory ballooning according to most users who accuse XEN of not returning unused RAM that has been previously shared with other VMs. KVM, unlike XEN is close to dedicated servers and users claim that KVM is way faster. Many users also admire the fact that KVM is more frequently updated which in turn leads to firmer security."
On Tuesday, December 19, 2017, 2:04:58 AM PST, James Dingwall <[hidden email]> wrote:
Hi Jason,
On Fri, Dec 15, 2017 at 09:18:14PM +0000, Jason Long wrote: > Can it work well? I mean is release the memory and back it to host. If I understand correctly you want to take memory from one running guest and then assign it to another? Yes, this is works. The tmem module helps you do this automatically but as an example you can also do: You want to start guest 3 but you only have 512M free memory, you are happy to take 256M from guests 1 & 2: guest 1: memory = 1024 guest 2: memory = 1024 guest 3: memory = 1024 xl mem-set guest1 768 xl mem-set guest2 768 xl create guest3 James > -------------------------------------------- > On Fri, 12/15/17, James Dingwall <[hidden email]> wrote: > > Subject: Re: [Xen-users] Xen ballooning problem. > To: "Jason Long" <[hidden email]> > Cc: [hidden email] > Date: Friday, December 15, 2017, 5:29 PM > > Hi, > > On Fri, Dec 15, 2017 at > 01:28:22PM +0000, Jason Long wrote: > > > Hello. > > Is it true that "Xen > ballooning" has some problems? For example, when it > dedicate memory to VMs then it can't release it and back > it to the host and it is a reason for migrate from Xen to > KVM. > > > > Thank > you. > > I have found a > few combinations of xen/kernel which don't work well but > otherwise I find it works for my case. > Currently xen 4.9.1, 4.1.47 dom0 kernel, mix of > Ubuntu 16.04 4.4 and 4.14 kernels in pv guests. I use the > tmem > module to automatically balloon the > guest up/down as memory pressure changes. > > James > > -----Inline Attachment Follows----- > > > > _______________________________________________ > Xen-users mailing list > [hidden email] > https://lists.xenproject.org/mailman/listinfo/xen-users _______________________________________________ Xen-users mailing list [hidden email] https://lists.xenproject.org/mailman/listinfo/xen-users _______________________________________________ Xen-users mailing list [hidden email] https://lists.xenproject.org/mailman/listinfo/xen-users |
Plans to require CPU VT flag?
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512 Out of curiosity, are there any plans to *require* the VT CPU flag in Xen at any point in the foreseeable future? The reason I ask is because my server at home doesn't support them, so I want to beware of any version that would break my current setup. Right now I've got four PV VMs running on my Xen box (4.8.3 on Debian Stretch,) and am perfectly content with its performance :) Thanks! Chris -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEE7GM/Dul8WSWn72odQ1nEo4DFCIUFAlo5i5QACgkQQ1nEo4DF CIXrPwf9Gk9BlGLnyn2Yn+lWxIfrDJQZhzlAagr4/6VBC9IYM6KfD1WNqpAYT639 bIUVx6Rv//yqV116VYCWPuHcGau67pZk9NXVebu9VVI7m388BCt6U2CDWEjOBv7m zJpEZBC0QoYeyhAOTWKv8e8NlQ3NrYEVH2aR/LGH93b+0R2dWKXhPS10EdsU6xBV q43CHbcidsPYFJGM9mXos/HDzZffTwb9CH0sZlBc115Vj9O7NlFStfzX4nhdjQzG m0WcUK6Y/MDTTd0hGtkci2QntKZbEUgWZex+oQebnZ50Utt607BiprUyhmXQbYzE 1/hFixx/hMG/9v3An8kIPl6TocJEPw== =1EEJ -----END PGP SIGNATURE----- _______________________________________________ Xen-users mailing list [hidden email] https://lists.xenproject.org/mailman/listinfo/xen-users |
Re: Plans to require CPU VT flag?
|
|
On Tue, Dec 19, 2017 at 9:58 PM, Christopher Myers <[hidden email]> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Out of curiosity, are there any plans to *require* the VT CPU flag in > Xen at any point in the foreseeable future? The reason I ask is because > my server at home doesn't support them, so I want to beware of any > version that would break my current setup. > > Right now I've got four PV VMs running on my Xen box (4.8.3 on Debian > Stretch,) and am perfectly content with its performance :) At the moment it's not possible to boot Xen without a PV domain 0 (on x86). :-) We are working on allowing PVH dom0 (which requires HVM* support), but that won't be ready until 4.11 or 4.12; even if we were planning on phasing it out, it wouldn't be possible for several years. But, there is no intention at this point of phasing out PV. As you say, there continues to be lots of x86 hardware (even new hardware) that doesn't have HVM support; for those platforms Xen will be basically the only option. This is speaking of the upstream XenProject of course; individual downstream vendors may of course make different strategic decisions. Peace, -George * VT is the Intel-specific name; HVM is the generic term fro hardware virtualization support on either Intel or AMD. _______________________________________________ Xen-users mailing list [hidden email] https://lists.xenproject.org/mailman/listinfo/xen-users |
|
|
In reply to this post by Jason Long
On Tuesday, December 19, 2017 5:22:39 PM CET Jason Long wrote:
> Thank you for your reply but I mean is "KVM is also the better option for > memory ballooning according to most users who accuse XEN of not returning > unused RAM that has been previously shared with other VMs. KVM, unlike XEN > is close to dedicated servers and users claim that KVM is way faster. Many > users also admire the fact that KVM is more frequently updated which in > turn leads to firmer security." Please see > "https://cloudcone.com/blog/kvm-vs-xen-knowing-the-differences-and-picking-> the-best/". I think the " not returning " part comes from people who don't fully understand how Xen works. With Xen, even the "host" is a guest. (Dom0) In most default installations, the dom0 starts with all the memory. When you start a new VM, the required memory is removed from the dom0 and given to the VM. When the VM is stopped, the memory is not automagically handed back to the dom0. You need to do this yourself (or add it to your management toolkit). I set up my Dom0's to a fixed amount of memory and disable the ballooning part as this makes more sense in this context. KVM works ontop of the host, which means that when memory is released by a VM, it does go back to the host. KVM is not closer to the hardware than Xen is. But with KVM, the host is closer than the dom0. Which does mean that any benchmarking on the host itself is likely showing a slight performance benefit. When looking at the VMs, however, I would doubt KVM to be better performing. The main reason why I am preferring Xen over KVM is the ability to create true snapshots (eg. including RAM) and being able to create a seperate storage domain. I have not seen a similar option in KVM. -- Joost _______________________________________________ Xen-users mailing list [hidden email] https://lists.xenproject.org/mailman/listinfo/xen-users |
|
|
In reply to this post by Jason Long
On Tuesday, December 19, 2017 5:22:39 PM CET Jason Long wrote:
> "https://cloudcone.com/blog/kvm-vs-xen-knowing-the-differences-and-picking-> the-best/". After reading this, I am still wondering about the actual reasons. It sounds like Cloudcone based their decision on some random remarks and nothing substantial. There is no mention of actual differences and why either of the 2 would be best. (Apart from mentioning Xen is proven technology and KVM is catching up) -- Joost _______________________________________________ Xen-users mailing list [hidden email] https://lists.xenproject.org/mailman/listinfo/xen-users |
Re: Plans to require CPU VT flag?
|
|
In reply to this post by George Dunlap
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512 On Wed, 2017-12-20 at 09:58 +0000, George Dunlap wrote: > On Tue, Dec 19, 2017 at 9:58 PM, Christopher Myers <[hidden email] > du> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > Out of curiosity, are there any plans to *require* the VT CPU flag > > in > > Xen at any point in the foreseeable future? The reason I ask is > > because > > my server at home doesn't support them, so I want to beware of any > > version that would break my current setup. > > > > Right now I've got four PV VMs running on my Xen box (4.8.3 on > > Debian > > Stretch,) and am perfectly content with its performance :) > > At the moment it's not possible to boot Xen without a PV domain 0 (on > x86). :-) > > We are working on allowing PVH dom0 (which requires HVM* support), > but > that won't be ready until 4.11 or 4.12; even if we were planning on > phasing it out, it wouldn't be possible for several years. > > But, there is no intention at this point of phasing out PV. As you > say, there continues to be lots of x86 hardware (even new hardware) > that doesn't have HVM support; for those platforms Xen will be > basically the only option. Awesome, thanks very much :) It really is amazing how much you can do with Xen. My setup is an Aaeon EMB CV1 A11 industrial motherboard (Atom D2550 processor) with 4GB of memory. On that I'm able to run four Debian Stretch PV DomU's without issue -- - asterisk VOIP server - nginx reverse proxy - dedicated bind9 VM - "the everything" vm, running the usual LAMP stack, minecraft server, rsyslog aggregator, nextcloud, secondary bind9 instance, email server, mantisbt, and about a half dozen other applications. When you think about the fact that this is, in reality, running off of two (not overly powerful) CPU cores, and performs very smoothly on top of all that... (At work we have slightly more powerful hardware running the software ;) But all of those VMs are HVM.) > > This is speaking of the upstream XenProject of course; individual > downstream vendors may of course make different strategic decisions. > > Peace, > -George > > * VT is the Intel-specific name; HVM is the generic term fro hardware > virtualization support on either Intel or AMD. > iQEzBAEBCgAdFiEE7GM/Dul8WSWn72odQ1nEo4DFCIUFAlo6cI0ACgkQQ1nEo4DF CIVSlwf/RQtKs+lRZusPAI5UgaQGsvRPwpdgCvtvKD+CqubkqACwSg/zIlyyWw7K PsgPC00tU04WHRA/3KEhK0etHDaYN/YfJuZPC5m0194TTqIVf+Avy6otO8O9RCIN bcwdM6hChgDSF6qxSM8lqBCed3zLq0mQ6YoNfb4Jej6G5guPUUatYeyHweEbWoZc BXiCjjVjRcDuMwFDuS+KdPzdpAtpKKAFRWQdQ5Y83lCODY4JfSTxrI+IG1QqpcAH jkHWncNCxf8X6o2e3kjiwlBi0Kwr2xFNQCMGf3S90v6IKPzHBPz9F69lbl/VVhpR mLNriATz76qbDat5j13rknSy5tYGQQ== =hZU9 -----END PGP SIGNATURE----- _______________________________________________ Xen-users mailing list [hidden email] https://lists.xenproject.org/mailman/listinfo/xen-users |
|
|
In reply to this post by Jason Long
On Tue, Dec 19, 2017 at 4:22 PM, Jason Long <[hidden email]> wrote:
> Thank you for your reply but I mean is "KVM is also the better option for > memory ballooning according to most users who accuse XEN of not returning > unused RAM that has been previously shared with other VMs. KVM, unlike XEN > is close to dedicated servers and users claim that KVM is way faster. Many > users also admire the fact that KVM is more frequently updated which in turn > leads to firmer security." Jason, A more helpful way of asking your original question would probably have been something like this: --- I read a blog post [1] about KVM vs Xen, which claimed that Xen doesn't return a VM's RAM to dom0 after the VM is destroyed. Is that true? [1] http://blah-blah-blah --- As someone else has said, that claim is in part based on a misunderstanding of how Xen works. Domain 0 is a guest like any other guest. If you're running in 'autoballoon' mode (which is the default), when you create a guest, domain 0 may give up RAM to Xen to create the guest. When the guest is destroyed, that memory is given back to Xen, but not given back to domain 0 unless it asks for it back. You can tell domain 0 to ask for it back by using the following command: xl mem-set 0 [target megabytes] Arguably autoballoon should do that automatically. But nobody has ever complained *to the developers* about this before, and so it hasn't occurred to anybody to fix it. Most of us disable autoballoon, and assign dom0 a fixed amount of memory instead (e.g., by adding dom0_mem=1024M to the Xen command line). I would agree that if you just want to start a few toy VMs on your desktop, KVM is a better choice than Xen. I have no idea what "close to dedicated servers" is supposed to mean, but the argument about security is completely bogus. One of the most important things for security is to be told about security issues so you can update, and KVM as a project doesn't do this at all. -George _______________________________________________ Xen-users mailing list [hidden email] https://lists.xenproject.org/mailman/listinfo/xen-users |
Re: Plans to require CPU VT flag?
|
|
In reply to this post by Christopher Myers
On Wed, Dec 20, 2017 at 2:15 PM, Christopher Myers <[hidden email]> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > > > On Wed, 2017-12-20 at 09:58 +0000, George Dunlap wrote: >> On Tue, Dec 19, 2017 at 9:58 PM, Christopher Myers <[hidden email] >> du> wrote: >> > -----BEGIN PGP SIGNED MESSAGE----- >> > Hash: SHA512 >> > >> > Out of curiosity, are there any plans to *require* the VT CPU flag >> > in >> > Xen at any point in the foreseeable future? The reason I ask is >> > because >> > my server at home doesn't support them, so I want to beware of any >> > version that would break my current setup. >> > >> > Right now I've got four PV VMs running on my Xen box (4.8.3 on >> > Debian >> > Stretch,) and am perfectly content with its performance :) >> >> At the moment it's not possible to boot Xen without a PV domain 0 (on >> x86). :-) >> >> We are working on allowing PVH dom0 (which requires HVM* support), >> but >> that won't be ready until 4.11 or 4.12; even if we were planning on >> phasing it out, it wouldn't be possible for several years. >> >> But, there is no intention at this point of phasing out PV. As you >> say, there continues to be lots of x86 hardware (even new hardware) >> that doesn't have HVM support; for those platforms Xen will be >> basically the only option. > > Awesome, thanks very much :) > > It really is amazing how much you can do with Xen. My setup is an Aaeon > EMB CV1 A11 industrial motherboard (Atom D2550 processor) with 4GB of > memory. On that I'm able to run four Debian Stretch PV DomU's without > issue -- > - asterisk VOIP server > - nginx reverse proxy > - dedicated bind9 VM > - "the everything" vm, running the usual LAMP stack, minecraft server, > rsyslog aggregator, nextcloud, secondary bind9 instance, email server, > mantisbt, and about a half dozen other applications. > > When you think about the fact that this is, in reality, running off of > two (not overly powerful) CPU cores, and performs very smoothly on top > of all that... That's good feedback, thanks. Intel Atom always comes up in discussions about why we need to keep PV, but I think until now it was always theoretical ("someone may want to do X"). Having at least one concrete user who has actually used X makes it a lot easier to justify supporting X. :-) -George _______________________________________________ Xen-users mailing list [hidden email] https://lists.xenproject.org/mailman/listinfo/xen-users |
Re: Plans to require CPU VT flag?
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512 On Wed, 2017-12-20 at 16:21 +0000, George Dunlap wrote: > On Wed, Dec 20, 2017 at 2:15 PM, Christopher Myers <[hidden email] > du> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > > > > > On Wed, 2017-12-20 at 09:58 +0000, George Dunlap wrote: > > > On Tue, Dec 19, 2017 at 9:58 PM, Christopher Myers <cmyers@millik > > > in.e > > > du> wrote: > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > Hash: SHA512 > > > > > > > > Out of curiosity, are there any plans to *require* the VT CPU > > > > flag > > > > in > > > > Xen at any point in the foreseeable future? The reason I ask is > > > > because > > > > my server at home doesn't support them, so I want to beware of > > > > any > > > > version that would break my current setup. > > > > > > > > Right now I've got four PV VMs running on my Xen box (4.8.3 on > > > > Debian > > > > Stretch,) and am perfectly content with its performance :) > > > > > > At the moment it's not possible to boot Xen without a PV domain 0 > > > (on > > > x86). :-) > > > > > > We are working on allowing PVH dom0 (which requires HVM* > > > support), > > > but > > > that won't be ready until 4.11 or 4.12; even if we were planning > > > on > > > phasing it out, it wouldn't be possible for several years. > > > > > > But, there is no intention at this point of phasing out PV. As > > > you > > > say, there continues to be lots of x86 hardware (even new > > > hardware) > > > that doesn't have HVM support; for those platforms Xen will be > > > basically the only option. > > > > Awesome, thanks very much :) > > > > It really is amazing how much you can do with Xen. My setup is an > > Aaeon > > EMB CV1 A11 industrial motherboard (Atom D2550 processor) with 4GB > > of > > memory. On that I'm able to run four Debian Stretch PV DomU's > > without > > issue -- > > - asterisk VOIP server > > - nginx reverse proxy > > - dedicated bind9 VM > > - "the everything" vm, running the usual LAMP stack, minecraft > > server, > > rsyslog aggregator, nextcloud, secondary bind9 instance, email > > server, > > mantisbt, and about a half dozen other applications. > > > > When you think about the fact that this is, in reality, running off > > of > > two (not overly powerful) CPU cores, and performs very smoothly on > > top > > of all that... > > That's good feedback, thanks. Intel Atom always comes up in > discussions about why we need to keep PV, but I think until now it > was > always theoretical ("someone may want to do X"). Having at least one > concrete user who has actually used X makes it a lot easier to > justify > supporting X. :-) You're very welcome! I very much appreciate all the work that's gone into this spectacular project over the years! Personally, I think it's the perfect combination for a small environment. I used to do the whole raspberry pi route, but it became more cumbersome and didn't offer nearly enough flexibility. But doing XEN on that tiny little board, combined with an SSD and LVM, gives me an awesome environment for my family's use. I think that a setup like this would be equally well-suited for small offices. Performance is quite good too; I just recently switched the NextCloud install over from my old environment, and shoved around 100GB of data down its gullet through HTTPS transactions (with the nginx VM serving up the SSL offloading,) and it didn't miss a beat. I'm most amazed about memory usage though, this totally blows my mind - -- full linux VMs, actually doing stuff, using in the tens of megabytes?! I've even got 384MB of memory that hasn't even been allocated to anything yet. dom0: $ free -h total used free shared buff/cache avail able Mem: 424M 103M 179M 1.6M 140M 306M Swap: 1.9G 1.3M 1.9G The nginx VM: $ free -h total used free shared buff/cache available Mem: 365M 37M 158M 4.3M 168M 313M Swap: 511M 0B 511M The primary DNS VM: $ free -h total used free shared buff/cache available Mem: 365M 59M 8.3M 4.1M 297M 292M Swap: 511M 12K 511M The asterisk VM: $ free -h total used free shared buff/cache available Mem: 365M 77M 127M 1.7M 160M 276M Swap: 511M 0B 511M The everything VM: $ free -h total used free shared buff/cache available Mem: 1.9G 817M 28M 264M 1.1G 882M Swap: 511M 32M 479M ((NOTE that this includes a 256MB ram disk for the Minecraft server.)) > > -George > -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEE7GM/Dul8WSWn72odQ1nEo4DFCIUFAlo6lC4ACgkQQ1nEo4DF CIVimAf/Thj9siKdzqXqs+hhy89dX1MZiBIi6YQnfK7p/kpkrOP7g2cBgv85f26p IlbjcqD37Vw05HWX2r2W9hQ6R1Z/oMGAvIcxrrCYYHLGi8PqTQZ+ietYKO7l+TbZ Imf6Ta9D8mDBteLuzO/yfTUS7QyydBPw0R9FO+QW0sSDqQWp1KaYk9EDXT0y+il3 T5Fn6zz5V1pmfWLmaLf1EfUhOYOe5/E/Y/2xz3AY8TgY+itkfQHRUjMLXvGEBTnW g6NDQc6fwJW3MtzWGPdkg/ckhMUG3lPAJ3y/4RS3/sdjDXFZulf579HuSwX0+KXc XyhJlMOLWln1+2qrBYzK4EvIh82Pbg== =cIft -----END PGP SIGNATURE----- _______________________________________________ Xen-users mailing list [hidden email] https://lists.xenproject.org/mailman/listinfo/xen-users |
«
Return to Xen - User
|
1 view|%1 views
| Free forum by Nabble | Edit this page |