State of new hardware and nesting

[Fabian Deutsch]

Am Sonntag, den 15.09.2013, 05:06 -0400 schrieb Kiril Nesenko:
> In a case that nested VMs wont work because of the kernel bug, can you use fake hosts instead ?

Hey,
do you mean a container (lxc, ...) with "fake host"?

- fabian

> ----- Original Message -----
> > From: "Fabian Deutsch" <fabiand at redhat.com>
> > To: "Eyal Edri" <eedri at redhat.com>
> > Cc: infra at ovirt.org
> > Sent: Thursday, September 12, 2013 1:47:22 PM
> > Subject: Re: State of new hardware and nesting
> > 
> > Hey Eyal,
> > 
> > Am Donnerstag, den 12.09.2013, 06:22 -0400 schrieb Eyal Edri:
> > > Hardware is now setup, but might still be missing additional resources
> > > to spawn new vms.
> > 
> > First - Nice that the new hardware is up!
> > 
> > > So your code will create the vms it needs via restapi/sdk?
> > 
> > Currently our code can use libvirt to spawn additional VMs (and remove
> > them afterwards) for testing.
> > We could also look if we add an Engine backend to our code so we can
> > directly speak to engine and spawn the VMs there. (But see below).
> > 
> > As for the VMs: They are short-lived (~5min) and should be equipped with
> > ~2CPUs and ~2GB RAM.
> > We can also limit the number of concurrent VMs, e.g. we could limit it
> > to one VM at a time, so we don't exhaust all available resources.
> > 
> > > nested vms might be ready soon, after a major bug was fixed on kernel,
> > > we currently test its functionality again and we'll update once(if) it's
> > > verified and working.
> > 
> > That would be awesome! Is there a bug which tracking this I could
> > subscribe too?
> > (i) If nesting was possible I'd suggest that we run our own libvirt
> > instance inside our VM and use that libvirt instance to spawn the
> > additional VMs.
> > 
> > (ii) If that's not possible I would look into adding a additional
> > backend to Igor which then can speak directly to Engine to spawn the
> > additional VMs. But note that this will imply that Igor will create a
> > new for and is uploading an ISO to Engine for each test run. That's
> > basically not a bad thing (tm) but a lot of interaction with Engine.
> > 
> > (i) is IMHO safer and more practical as it is self-contained. Surely the
> > nested VMs won't be to powerful, but that's okay.
> > But (ii) is also a way to go if nesting is not possible.
> > 
> > fabian
> > 
> > > ----- Original Message -----
> > > > From: "Fabian Deutsch" <fabiand at redhat.com>
> > > > To: infra at ovirt.org
> > > > Sent: Thursday, September 12, 2013 12:05:07 PM
> > > > Subject: State of new hardware and nesting
> > > > 
> > > > Hey,
> > > > 
> > > > to run functional tests with ovirt-node we still need a possibility to
> > > > spawn VMs.
> > > > The solution which got discussed a couple of weeks (months?) back was to
> > > > enable nesting to allow a setup like:
> > > > 
> > > > Host
> > > >  +-> Test Automation (Igor) VM
> > > >       +-> Test Instance (spawned on demand by Igor)
> > > >       +-> Test Instance (spawned on demand by Igor)
> > > > 
> > > > Back then the new hardware wasn't setup and not ready.
> > > > My question is if the hardware is now setup?
> > > > And if it allow nesting?
> > > > 
> > > > Greetings
> > > > fabian
> > > > 
> > > > _______________________________________________
> > > > Infra mailing list
> > > > Infra at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/infra
> > > > 
> > 
> > 
> > _______________________________________________
> > Infra mailing list
> > Infra at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
> >