Xen ballooning problem.

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Xen ballooning problem.

Jason Long
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
Reply | Threaded
Open this post in threaded view
|

Re: Xen ballooning problem.

James Dingwall-3
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
Reply | Threaded
Open this post in threaded view
|

Re: Xen ballooning problem.

Jason Long
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
Reply | Threaded
Open this post in threaded view
|

Re: Xen ballooning problem.

Erlend Hoel
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.
--------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|

Re: Xen ballooning problem.

James Dingwall
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
Reply | Threaded
Open this post in threaded view
|

Re: Xen ballooning problem.

Jason Long
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
Reply | Threaded
Open this post in threaded view
|

Plans to require CPU VT flag?

Christopher Myers
-----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
Reply | Threaded
Open this post in threaded view
|

Re: Plans to require CPU VT flag?

George Dunlap
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
Reply | Threaded
Open this post in threaded view
|

Re: Xen ballooning problem.

J. Roeleveld
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
Reply | Threaded
Open this post in threaded view
|

Re: Xen ballooning problem.

J. Roeleveld
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
Reply | Threaded
Open this post in threaded view
|

Re: Plans to require CPU VT flag?

Christopher Myers
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.
>
-----BEGIN PGP SIGNATURE-----

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
Reply | Threaded
Open this post in threaded view
|

Re: Xen ballooning problem.

George Dunlap
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
Reply | Threaded
Open this post in threaded view
|

Re: Plans to require CPU VT flag?

George Dunlap
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
Reply | Threaded
Open this post in threaded view
|

Re: Plans to require CPU VT flag?

Christopher Myers
-----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