[Qemu-devel] wake-on-lan & IPMI implementation; real power-off and -no-shutdown

[Qemu-devel] wake-on-lan & IPMI implementation; real power-off and -no-shutdown

[François Revol]

Hello,
while working on a demonstrator for a green-IT project, to show
scheduled machine shutdown and powering depending on various
conditions, I wondered if I could use QEMU with wake-on-lan
transparently, but it seems it's not implemented at all.

I though I could try to add support for it, and with -S it theorically
should be doable at least for the first boot, but the network packets
do not go much further until the NIC is actually initialized, as most
network layers use qemu_can_send_packet() which returns 0 if the
machine is stopped.
Hacking this function to return 1 seems to push the packet upward, but
I couldn't find a single point where I could check for WOL packets,
different -net subsystems using different code paths.

Also, it seems -no-shutdown doesn't actually "stop the emulation" as
said in the manual, it actually keeps the vm running (and using cpu),
despite the OS trying to shutdown via ACPI. At least I tested so with
Haiku (and acpi=true in kernel config), which properly exits QEMU
without -no-shutdown.

Ideally this would evolve into supporting IPMI, which would allow
managing VMs exactly like physical servers without concern, appart
launching the actual process first.
cf.
http://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface
http://openipmi.sourceforge.net/

Anyone interested in this ?
Anyone tried already ?

François.

Re: [Qemu-devel] wake-on-lan & IPMI implementation; real power-off and -no-shutdown

[Paul Brook]

> Ideally this would evolve into supporting IPMI, which would allow
> managing VMs exactly like physical servers without concern, appart
> launching the actual process first.
> cf.
> http://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface
> http://openipmi.sourceforge.net/
> 
> Anyone interested in this ?
> Anyone tried already ?

TBH I don't really see the point.

This definitely seems like something that should be handled by your your 
mangement app (via libvirt, or whatever). i.e. have that implement whatever 
remote protocol you want, and just talk to qemu over the normal monitor 
interface.

Paul

Re: [Qemu-devel] wake-on-lan & IPMI implementation; real power-off and -no-shutdown

[François Revol]

Le Mon, 15 Mar 2010 15:26:24 +0000, Paul Brook a écrit :
> > Ideally this would evolve into supporting IPMI, which would allow
> > managing VMs exactly like physical servers without concern, appart
> > launching the actual process first.
> > cf.
> > http://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface
> > > > http://openipmi.sourceforge.net/
> >
> > Anyone interested in this ?
> > Anyone tried already ?
>
> TBH I don't really see the point.
>
> This definitely seems like something that should be handled by your
> your
> mangement app (via libvirt, or whatever). i.e. have that implement
> whatever
> remote protocol you want, and just talk to qemu over the normal
> monitor
> interface.

Hmm for IPMI that might probably indeed be a better way, moreover since
they use a parallel subnet on the primary ethernet card...
Though it would require the implementation to listen to the same
virtual card, which are mapped differently to the host depending on the
VM (-net user, ...).

As for WOL, it would still be handy to have I think... btw, do we
support suspending the emulation via ACPI ? VirtualBox has something
called "Pause" mode, which I'm not sure actually if it's reflected to
ACPI, which allows to avoid wasting cpu when not usign the guest,
though it requires support from the Guest Additions to avoid clock
drifts.

François.

Re: [Qemu-devel] wake-on-lan & IPMI implementation; real power-off and -no-shutdown

[Anthony Liguori]

On 03/15/2010 10:37 AM, François Revol wrote:
> Le Mon, 15 Mar 2010 15:26:24 +0000, Paul Brook a écrit :
>    
>>> Ideally this would evolve into supporting IPMI, which would allow
>>> managing VMs exactly like physical servers without concern, appart
>>> launching the actual process first.
>>> cf.
>>> http://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface
>>>        
>>>>> http://openipmi.sourceforge.net/
>>>>>            
>>> Anyone interested in this ?
>>> Anyone tried already ?
>>>        
>> TBH I don't really see the point.
>>
>> This definitely seems like something that should be handled by your
>> your
>> mangement app (via libvirt, or whatever). i.e. have that implement
>> whatever
>> remote protocol you want, and just talk to qemu over the normal
>> monitor
>> interface.
>>      
> Hmm for IPMI that might probably indeed be a better way, moreover since
> they use a parallel subnet on the primary ethernet card...
> Though it would require the implementation to listen to the same
> virtual card, which are mapped differently to the host depending on the
> VM (-net user, ...).
>
> As for WOL, it would still be handy to have I think... btw, do we
> support suspending the emulation via ACPI ? VirtualBox has something
> called "Pause" mode, which I'm not sure actually if it's reflected to
> ACPI, which allows to avoid wasting cpu when not usign the guest,
> though it requires support from the Guest Additions to avoid clock
> drifts.
>    

It's just "stop".

It won't cause time drift in qemu when using pvclock but you will get 
soft lockups in Linux.  I presume you get that with Virtual Box too.

Regards,

Anthony Liguori

> François.
>
>
>    

Re: [Qemu-devel] wake-on-lan & IPMI implementation; real power-off and -no-shutdown

[François Revol]

> > As for WOL, it would still be handy to have I think... btw, do we
> > support suspending the emulation via ACPI ? VirtualBox has
> > something
> > called "Pause" mode, which I'm not sure actually if it's reflected
> > to
> > ACPI, which allows to avoid wasting cpu when not usign the guest,
> > though it requires support from the Guest Additions to avoid clock
> > drifts.
> >
>
> It's just "stop".
>
> It won't cause time drift in qemu when using pvclock but you will get
> soft lockups in Linux.  I presume you get that with Virtual Box too.

Hmm yeah I didn't try playing with the various clock options, since
Haiku doesn't support them anyway, only TSC, and HPET but it's in
progress.

François.

Re: [Qemu-devel] wake-on-lan & IPMI implementation; real power-off and -no-shutdown

[Daniel P. Berrange]

On Mon, Mar 15, 2010 at 04:01:27PM +0100, Fran?ois Revol wrote:
> Hello,
> while working on a demonstrator for a green-IT project, to show
> scheduled machine shutdown and powering depending on various
> conditions, I wondered if I could use QEMU with wake-on-lan
> transparently, but it seems it's not implemented at all.
> 
> I though I could try to add support for it, and with -S it theorically
> should be doable at least for the first boot, but the network packets
> do not go much further until the NIC is actually initialized, as most
> network layers use qemu_can_send_packet() which returns 0 if the
> machine is stopped.
> Hacking this function to return 1 seems to push the packet upward, but
> I couldn't find a single point where I could check for WOL packets,
> different -net subsystems using different code paths.
> 
> Also, it seems -no-shutdown doesn't actually "stop the emulation" as
> said in the manual, it actually keeps the vm running (and using cpu),
> despite the OS trying to shutdown via ACPI. At least I tested so with
> Haiku (and acpi=true in kernel config), which properly exits QEMU
> without -no-shutdown.

Hmm, I think -no-shutdown should at least stop the CPUs executing. It is
not really useful on its own though. The app managing QEMU would want to
use the new JSON based monitor to listen for the SHUTDOWN event to be
emitted, so it can detect the shutdown completing & then take action it
wants either reset the guest, or kill QEMU, etc

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

Re: [Qemu-devel] wake-on-lan & IPMI implementation; real power-off and -no-shutdown

[Anthony Liguori]

On 03/15/2010 10:55 AM, Daniel P. Berrange wrote:
> On Mon, Mar 15, 2010 at 04:01:27PM +0100, Fran?ois Revol wrote:
>    
>> Hello,
>> while working on a demonstrator for a green-IT project, to show
>> scheduled machine shutdown and powering depending on various
>> conditions, I wondered if I could use QEMU with wake-on-lan
>> transparently, but it seems it's not implemented at all.
>>
>> I though I could try to add support for it, and with -S it theorically
>> should be doable at least for the first boot, but the network packets
>> do not go much further until the NIC is actually initialized, as most
>> network layers use qemu_can_send_packet() which returns 0 if the
>> machine is stopped.
>> Hacking this function to return 1 seems to push the packet upward, but
>> I couldn't find a single point where I could check for WOL packets,
>> different -net subsystems using different code paths.
>>
>> Also, it seems -no-shutdown doesn't actually "stop the emulation" as
>> said in the manual, it actually keeps the vm running (and using cpu),
>> despite the OS trying to shutdown via ACPI. At least I tested so with
>> Haiku (and acpi=true in kernel config), which properly exits QEMU
>> without -no-shutdown.
>>      
> Hmm, I think -no-shutdown should at least stop the CPUs executing. It is
> not really useful on its own though. The app managing QEMU would want to
> use the new JSON based monitor to listen for the SHUTDOWN event to be
> emitted, so it can detect the shutdown completing&  then take action it
> wants either reset the guest, or kill QEMU, etc
>    

The semantics of -no-shutdown are awful.

I'd personally prefer to see the option deprecated and a new set of 
options introduced with clearer semantics.

Currently, -no-shutdown does too many things.  It affects reboot 
behaviour, shutdown behaviour, the behavior of the SDL close button.  
Each of these things should be individual tunables.

Regards,

Anthony Liguori

> Daniel
>    

Re: [Qemu-devel] wake-on-lan & IPMI implementation; real power-off and -no-shutdown

[François Revol]

> >> Also, it seems -no-shutdown doesn't actually "stop the emulation"
> > > as
> >> said in the manual, it actually keeps the vm running (and using
> > > cpu),
> >> despite the OS trying to shutdown via ACPI. At least I tested so
> > > with
> >> Haiku (and acpi=true in kernel config), which properly exits QEMU
> >> without -no-shutdown.
> >>
> > Hmm, I think -no-shutdown should at least stop the CPUs executing.
> > It is
> > not really useful on its own though. The app managing QEMU would
> > want to
> > use the new JSON based monitor to listen for the SHUTDOWN event to
> > be
> > emitted, so it can detect the shutdown completing&  then take
> > action it
> > wants either reset the guest, or kill QEMU, etc
> >
>
> The semantics of -no-shutdown are awful.
>
> I'd personally prefer to see the option deprecated and a new set of
> options introduced with clearer semantics.
>
> Currently, -no-shutdown does too many things.  It affects reboot
> behaviour, shutdown behaviour, the behavior of the SDL close button.
> Each of these things should be individual tunables.

Indeed, it both means "do not allow user to close the vm" and "do not
allow the guest to stop (or reboot ?)" it seems...

François.

Re: [Qemu-devel] wake-on-lan & IPMI implementation; real power-off and -no-shutdown

[Jamie Lokier]

> The semantics of -no-shutdown are awful.
> 
> I'd personally prefer to see the option deprecated and a new set of 
> options introduced with clearer semantics.
> 
> Currently, -no-shutdown does too many things.  It affects reboot 
> behaviour, shutdown behaviour, the behavior of the SDL close button.  
> Each of these things should be individual tunables.

I'm not sure about -no-shutdown, but I've had some problems with -no-reboot,
which I use for semi-automated OS installations.

I use -no-reboot so that when the guest does a reboot during
installation, as they invariably do one or more times, QEMU exits, my
scripts does things eject the CD/floppy, or change it for the next in
sequence, and modify the guest's installed files to add virtio
drivers, install extra fiels, edit boot scripts and whatever else is
useful, and then restart QEMU.

The guest thinks it's just rebooted, but it has the virtualisation
goodies in place to run better.

Unfortunately with an MS-DOS 5.00 guest, -no-reboot does not
work.  It fails to exit QEMU; instead it just reboots.  I guess that
means a QJSON event would not be sent either.

For my use case, it would be even better if guest reboot paused the
guest and sent a QJSON event instead of having to use -no-reboot.
Then I wouldn't have to close and restart the VNC client repeatedly
during installs.

Now that we have ways to choose what kind of events and actions are
triggered by the QEMU watchdog device, it would be nice to fit guest
reboot (perhaps even the different types of reboot) / host-forced
reboot / guest powerdown / host-forced powerdown (like holding down
the power button for 5 seconds on a real PC) into the same/similar
framework as the watchdog, with same/similar event types and action
choices.

-- Jamie

Re: [Qemu-devel] wake-on-lan & IPMI implementation; real power-off and -no-shutdown

[Daniel P. Berrange]

On Tue, Mar 16, 2010 at 05:28:51PM +0000, Jamie Lokier wrote:
> > The semantics of -no-shutdown are awful.
> > 
> > I'd personally prefer to see the option deprecated and a new set of 
> > options introduced with clearer semantics.
> > 
> > Currently, -no-shutdown does too many things.  It affects reboot 
> > behaviour, shutdown behaviour, the behavior of the SDL close button.  
> > Each of these things should be individual tunables.
> 
> I'm not sure about -no-shutdown, but I've had some problems with -no-reboot,
> which I use for semi-automated OS installations.
> 
> I use -no-reboot so that when the guest does a reboot during
> installation, as they invariably do one or more times, QEMU exits, my
> scripts does things eject the CD/floppy, or change it for the next in
> sequence, and modify the guest's installed files to add virtio
> drivers, install extra fiels, edit boot scripts and whatever else is
> useful, and then restart QEMU.
> 
> The guest thinks it's just rebooted, but it has the virtualisation
> goodies in place to run better.

That's the way libvirt / virt-manager does provisioning too.

> Unfortunately with an MS-DOS 5.00 guest, -no-reboot does not
> work.  It fails to exit QEMU; instead it just reboots.  I guess that
> means a QJSON event would not be sent either.
> 
> For my use case, it would be even better if guest reboot paused the
> guest and sent a QJSON event instead of having to use -no-reboot.
> Then I wouldn't have to close and restart the VNC client repeatedly
> during installs.

That would be nice!

> Now that we have ways to choose what kind of events and actions are
> triggered by the QEMU watchdog device, it would be nice to fit guest
> reboot (perhaps even the different types of reboot) / host-forced
> reboot / guest powerdown / host-forced powerdown (like holding down
> the power button for 5 seconds on a real PC) into the same/similar
> framework as the watchdog, with same/similar event types and action
> choices.

Agreed, it'd be good to have a more generalized method of controlling
the lifecycle actions in QEMU.

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

Re: [Qemu-devel] wake-on-lan & IPMI implementation; real power-off and -no-shutdown

[François Revol]

> I use -no-reboot so that when the guest does a reboot during
> installation, as they invariably do one or more times, QEMU exits, my
> scripts does things eject the CD/floppy, or change it for the next in
> sequence, and modify the guest's installed files to add virtio
> drivers, install extra fiels, edit boot scripts and whatever else is
> useful, and then restart QEMU.
>
> The guest thinks it's just rebooted, but it has the virtualisation
> goodies in place to run better.
>
> Unfortunately with an MS-DOS 5.00 guest, -no-reboot does not
> work.  It fails to exit QEMU; instead it just reboots.  I guess that
> means a QJSON event would not be sent either.

I suppose it uses a weird way to reboot, there are many (PS/2
controller, calling the BIOS entry point...).

François.

Re: [Qemu-devel] wake-on-lan & IPMI implementation; real power-off and -no-shutdown

[Luiz Capitulino]

On Mon, 15 Mar 2010 15:55:26 +0000
"Daniel P. Berrange" <berrange@redhat.com> wrote:

> On Mon, Mar 15, 2010 at 04:01:27PM +0100, Fran?ois Revol wrote:
> > Hello,
> > while working on a demonstrator for a green-IT project, to show
> > scheduled machine shutdown and powering depending on various
> > conditions, I wondered if I could use QEMU with wake-on-lan
> > transparently, but it seems it's not implemented at all.
> > 
> > I though I could try to add support for it, and with -S it theorically
> > should be doable at least for the first boot, but the network packets
> > do not go much further until the NIC is actually initialized, as most
> > network layers use qemu_can_send_packet() which returns 0 if the
> > machine is stopped.
> > Hacking this function to return 1 seems to push the packet upward, but
> > I couldn't find a single point where I could check for WOL packets,
> > different -net subsystems using different code paths.
> > 
> > Also, it seems -no-shutdown doesn't actually "stop the emulation" as
> > said in the manual, it actually keeps the vm running (and using cpu),
> > despite the OS trying to shutdown via ACPI. At least I tested so with
> > Haiku (and acpi=true in kernel config), which properly exits QEMU
> > without -no-shutdown.
> 
> Hmm, I think -no-shutdown should at least stop the CPUs executing. It is
> not really useful on its own though. The app managing QEMU would want to
> use the new JSON based monitor to listen for the SHUTDOWN event to be
> emitted, so it can detect the shutdown completing & then take action it
> wants either reset the guest, or kill QEMU, etc

 If I'm not missing something, -no-shutdown calls vm_stop(), which calls
pause_all_vcpus().

Re: [Qemu-devel] wake-on-lan & IPMI implementation; real power-off and -no-shutdown

[François Revol]

> > > Also, it seems -no-shutdown doesn't actually "stop the emulation"
> > > as
> > > said in the manual, it actually keeps the vm running (and using
> > > cpu),
> > > despite the OS trying to shutdown via ACPI. At least I tested so
> > > with
> > > Haiku (and acpi=true in kernel config), which properly exits QEMU
> > > without -no-shutdown.
> >
> > Hmm, I think -no-shutdown should at least stop the CPUs executing.
> > It is
> > not really useful on its own though. The app managing QEMU would
> > want to
> > use the new JSON based monitor to listen for the SHUTDOWN event to
> > be
> > emitted, so it can detect the shutdown completing & then take
> > action it
> > wants either reset the guest, or kill QEMU, etc
>
>  If I'm not missing something, -no-shutdown calls vm_stop(), which
> calls
> pause_all_vcpus().

Oh indeed, "info status" shows the VM as "paused".
I was misled because the GUI window was still open...

François.