Re: [libvirt] PATCH: Support memory ballooning for QEMU

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Mar 10, 2009 at 02:25:56PM -0400, Cole Robinson wrote:
> Daniel P. Berrange wrote:
> > This patch implements full support for memory ballooning in the QEMU
> > driver.
> > 
> >  - Fix qemudBuildCommandLine() to set the initial boot time VM memory 
> >    allocation based off the 'maxmem' config field.
> >  - Add call to 'qemudDomainSetMemoryBalloon' immediately at startup
> >    to make the guest balloon to initial requested allocation.
> >  - In the qemudDomainGetInfo() and qemudDomainDumpXML calls, query
> >    the monitor to find current balloon allocation and update config
> >  - Implement qemudDomainSetMemory() for running guests using the
> >    monitor balloon command
> > 
> > In all of these scenarios, if the QEMU being used is too old to support
> > the memory balloon device, the user will get a suitable error or it'll
> > report the statically defined memory allocation from boot time.
> > 
> 
> Before we balloon the guest at startup, does QEMU actually claim the
> maxmem amount? As in, if maxmem is 4G, and mem is 512M, will qemu
> starting grabbing the 4G in its first few moments?

Yes & no :-)

QEMU/KVM doesn't actually pin all guest RAM in memory on startup. So 
if you boot a guest with maxmem=4G and memory=500 MB, even if the guest
OS takes a while before loading the virtio_balloon.ko module, the
guest won't be using all 4G of RAM. The host only pulls guest RAM
into memory when pages are touched by the guest OS.

> Also, if for some reason someone currently has different maxmem and mem
> values for a QEMU/KVM version that doesn't support ballooning, their
> guest will now use the maxmem amount? I don't think this is really a big
> deal (since it's not very likely to happen), just curious.

Yes, that is correct - it should have always been doing this because
that's the same semantics that other drivers have.

> > @@ -2473,8 +2572,15 @@ static int qemudDomainGetInfo(virDomainP
> >          }
> >      }
> >  
> > +    err = qemudDomainGetMemoryBalloon(dom->conn, vm, &balloon);
> > +    if (err < 0)
> > +        goto cleanup;
> > +
> >      info->maxMem = vm->def->maxmem;
> > -    info->memory = vm->def->memory;
> > +    if (err == 0) /* Balloon not supported */
> > +        info->memory = vm->def->memory;
> 
> If balloon isn't supported, won't this always be maxmem, since that's
> what we pass on the command line?

That is true - we should probably set that explicitly to be clear.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]