LinuxQuestions.org
Did you know LQ has a Linux Hardware Compatibility List?
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Virtualization and Cloud
User Name
Password
Linux - Virtualization and Cloud This forum is for the discussion of all topics relating to Linux Virtualization and Linux Cloud platforms. Xen, KVM, OpenVZ, VirtualBox, VMware, Linux-VServer and all other Linux Virtualization platforms are welcome. OpenStack, CloudStack, ownCloud, Cloud Foundry, Eucalyptus, Nimbus, OpenNebula and all other Linux Cloud platforms are welcome. Note that questions relating solely to non-Linux OS's should be asked in the General forum.

Notices

Reply
 
Search this Thread
Old 06-08-2011, 12:45 PM   #16
Skaperen
Senior Member
 
Registered: May 2009
Location: WV, USA
Distribution: Slackware, CentOS, Ubuntu, Fedora, Timesys, Linux From Scratch
Posts: 1,777
Blog Entries: 20

Rep: Reputation: 115Reputation: 115

The command "virsh list" doesn't list any of my virtual machines. I have one running now but it doesn't list it.
 
Old 06-08-2011, 02:14 PM   #17
dyasny
Member
 
Registered: Dec 2007
Location: Canada
Distribution: RHEL,Fedora
Posts: 836

Rep: Reputation: 91
Quote:
Originally Posted by Skaperen View Post
Desktop systems put up a prompt asking to shutdown
This is what we've started with! I'm no desktop expert, but I'm pretty sure this prompt can be handled, timeout set to 0 or disabled completely.


Quote:
The real issue is getting that signal to the QEMU process at the time init is sending SIGTERM to other processes.
so what you want, is to automate VM shutdown when the host goes down? I'd start by looking at K$(num)libvirt in /etc/rcX.d

---------- Post added 06-08-11 at 07:14 PM ----------

Quote:
Originally Posted by Skaperen View Post
The command "virsh list" doesn't list any of my virtual machines. I have one running now but it doesn't list it.
were they started with libvirt or manually?
 
Old 06-08-2011, 02:25 PM   #18
Skaperen
Senior Member
 
Registered: May 2009
Location: WV, USA
Distribution: Slackware, CentOS, Ubuntu, Fedora, Timesys, Linux From Scratch
Posts: 1,777
Blog Entries: 20

Rep: Reputation: 115Reputation: 115
Quote:
Originally Posted by dyasny View Post
This is what we've started with! I'm no desktop expert, but I'm pretty sure this prompt can be handled, timeout set to 0 or disabled completely.



so what you want, is to automate VM shutdown when the host goes down? I'd start by looking at K$(num)libvirt in /etc/rcX.d

---------- Post added 06-08-11 at 07:14 PM ----------



were they started with libvirt or manually?
They were started by a script that figures out which instance is needed for the current batch request, and other things like where to get and place the image files, and such. Using virsh to start them isn't an option for multiple reasons, like its requirement for root (in many cases using virtual machines was a direction meant to avoid running as root).

Hey, I have an idea. Why not just add some code to each VM engine to allow specifying that a power down will be emulated on a signal? By default not requesting the feature would keep the previous behavior (so no change to those not expecting any). The default signal would be SIGTERM so it works consistently with existing init shutdown processes. This should be quite simple to do (details vary by engine internals).
 
Old 06-08-2011, 02:56 PM   #19
dyasny
Member
 
Registered: Dec 2007
Location: Canada
Distribution: RHEL,Fedora
Posts: 836

Rep: Reputation: 91
Quote:
Originally Posted by Skaperen View Post
They were started by a script that
explains why virsh list doesn't see them. libvirt serves as a wrapper for kvm-qemu after all.

Quote:
Hey, I have an idea. Why not just add some code to each VM engine to allow specifying that a power down will be emulated on a signal?
How do you see this happening? When you run the VM in a wrapper, like you would with libvirt or vdsm, you have an API command to send an ACPI shutdown, and the API also provides a way to send monitor commands, in case you need to. Without a wrapper, you're left with only the monitor to interface with _directly_ and nothing else. and since qemu is a process, it should react to sigterm and sigkill like any other process would.
You could add extra behaviour for the qemu process to react to a sigterm with an acpi shutdown in the guest, but right now this is not the case, and I'm not sure the qemu devs will set such a feature at a high priority, considering the large amount of wrappers that already do this anyway. doesn't mean you can't ask for it, or write it yourself of course
 
Old 06-09-2011, 07:52 AM   #20
Skaperen
Senior Member
 
Registered: May 2009
Location: WV, USA
Distribution: Slackware, CentOS, Ubuntu, Fedora, Timesys, Linux From Scratch
Posts: 1,777
Blog Entries: 20

Rep: Reputation: 115Reputation: 115
Quote:
Originally Posted by dyasny View Post
explains why virsh list doesn't see them. libvirt serves as a wrapper for kvm-qemu after all.
But someone said this, earlier:

Quote:
Originally Posted by dyasny View Post
you have it completely wrong.
Every VM running with QEMU maintains a socket, through which the host communicates with the QEMU process.
That sure didn't sound like a wrapper. It sounded like someone thought QEMU created a socket to which I could connect and send a message to QEMU. Ironically, that might have been workable if it existed. Of course, a script would have to know how to find all of these sockets wherever they are placed.

Another alternative would have been a message bus feature programs can connect to so they can find out when the system goes down (or other important events). Oh, wait, the kernel people already did a simpler form of this long long ago. I think they call it signals.

Quote:
Originally Posted by dyasny View Post
How do you see this happening? When you run the VM in a wrapper, like you would with libvirt or vdsm, you have an API command to send an ACPI shutdown, and the API also provides a way to send monitor commands, in case you need to. Without a wrapper, you're left with only the monitor to interface with _directly_ and nothing else. and since qemu is a process, it should react to sigterm and sigkill like any other process would.
It would normally be expected for a process to do a graceful shutdown for SIGTERM. Of course, it can't for SIGKILL. This seems to be a difference of opinion about what is meant by "graceful". I think it should mean to carry out steps to at least try to let other running components in the process shut down gracefully, too.
Quote:
Originally Posted by dyasny View Post
You could add extra behaviour for the qemu process to react to a sigterm with an acpi shutdown in the guest, but right now this is not the case, and I'm not sure the qemu devs will set such a feature at a high priority, considering the large amount of wrappers that already do this anyway. doesn't mean you can't ask for it, or write it yourself of course
I really don't know why it didn't have it. I'm only now wanting to have that ability. But I can't use a wrapper that requires root. Why isn't virsh itself installed as suid root so it can get that root permission with code that properly manages the original user's access rights?

Does vdsm also require root access? If so, that's a show stopper for it, too. Remember, an important cause for using virtual machines is for users that specifically do not have root access. Of course, some programs do run as root for non-root users. But those programs know the user context they are running under and manage the access rights correctly (supposedly). They get installed with the SUID bit on, owned by root. Can virsh/libvirt and/or vdsm handle the context correctly so they are not security breakage vectors? If they could, there would be no reason to not install it "suid root". But it isn't, so I suspect it isn't coded with that grade of security, and thus limits itself to just the actual root user (fine for the shutdown scripts, but not fine for normal running of the VM).

The really sad part of this is that handling SIGTERM so it also does the power down emulation would not be that hard. If the function that carries that out can't actually be called directly in the signal handler context, then the signal handler can set a flag that the main tasks in the process can check on periodically.
 
Old 06-09-2011, 11:20 AM   #21
dyasny
Member
 
Registered: Dec 2007
Location: Canada
Distribution: RHEL,Fedora
Posts: 836

Rep: Reputation: 91
[QUOTE]
Quote:
Originally Posted by Skaperen View Post
But someone said this, earlier:

That sure didn't sound like a wrapper. It sounded like someone thought QEMU created a socket to which I could connect and send a message to QEMU. Ironically, that might have been workable if it existed. Of course, a script would have to know how to find all of these sockets wherever they are placed.
right, well, that was my mistake, and without a wrapper to do this - no easy to access socket. moreover - no accounted for and maintained socket.

Quote:
Another alternative would have been a message bus feature programs can connect to so they can find out when the system goes down (or other important events). Oh, wait, the kernel people already did a simpler form of this long long ago. I think they call it signals.
you really think virtualization is the same as running a simple forked process?

Quote:
It would normally be expected for a process to do a graceful shutdown for SIGTERM. Of course, it can't for SIGKILL. This seems to be a difference of opinion about what is meant by "graceful". I think it should mean to carry out steps to at least try to let other running components in the process shut down gracefully, too.
qemu has no way of being aware of the processes running in the guest OS and vice versa. Using the hypercall, with drivers and agents can be done, but hey, if you need it so much - why don't you write it? sure would be nicer than complaining.

Quote:
I really don't know why it didn't have it. I'm only now wanting to have that ability. But I can't use a wrapper that requires root. Why isn't virsh itself installed as suid root so it can get that root permission with code that properly manages the original user's access rights?
again, this is open source, what is stopping you from patching a package that doesn't work the way you want it to?

Quote:
Does vdsm also require root access? If so, that's a show stopper for it, too.
no it doesn't.

Quote:
Remember, an important cause for using virtual machines is for users that specifically do not have root access.
those users can be provided a simple start/stop functionality, without access to libvirt. libvirt provides it's own API, remember?


Quote:
Of course, some programs do run as root for non-root users. But those programs know the user context they are running under and manage the access rights correctly (supposedly). They get installed with the SUID bit on, owned by root. Can virsh/libvirt and/or vdsm handle the context correctly so they are not security breakage vectors? If they could, there would be no reason to not install it "suid root". But it isn't, so I suspect it isn't coded with that grade of security, and thus limits itself to just the actual root user (fine for the shutdown scripts, but not fine for normal running of the VM).
actually, there's an entire part of selinux that deals in virtualization and libvirt specifically. if you're that concerned with security - http://selinuxproject.org/page/SVirt

Quote:
The really sad part of this is that handling SIGTERM so it also does the power down emulation would not be that hard. If the function that carries that out can't actually be called directly in the signal handler context, then the signal handler can set a flag that the main tasks in the process can check on periodically.
I think you're really confused about what is happening inside qemu. When you call a sigterm on a normal process, that's one flow. calling a sigterm on qemu (or qemu-kvm) will try to erform a sigterm on the process itself. This process is not one of the processes running inside the guest, but the process that emulates the CPU of the guest. and this process, when accessed from the host side, cannot provide access to the entire structure of processes running in the guest OS and using this virtual CPU, which from the host side, looks like a process. this is why a sigkill sent to qemu's process is roughly equivalent to pulling the plug on the VM.

qemu performs a graceful shutdown by emulating an acpi shutdown request sent to it's virtual BIOS. Whether ACPI shutdowns are respected by the guest OS is entirely up to the guest OS.
 
Old 06-09-2011, 01:13 PM   #22
Skaperen
Senior Member
 
Registered: May 2009
Location: WV, USA
Distribution: Slackware, CentOS, Ubuntu, Fedora, Timesys, Linux From Scratch
Posts: 1,777
Blog Entries: 20

Rep: Reputation: 115Reputation: 115
Quote:
Originally Posted by dyasny View Post
you really think virtualization is the same as running a simple forked process?
In what context are you asking this? No two processes are the same. And if they are different executables running, they are very different.

Quote:
Originally Posted by dyasny View Post
qemu has no way of being aware of the processes running in the guest OS and vice versa. Using the hypercall, with drivers and agents can be done, but hey, if you need it so much - why don't you write it? sure would be nicer than complaining.
It doesn't need to be aware of what the guest OS does. It only need to present the hardware interface in some context. The suggested context in this case is to emulate the ACPI action when shutting down.

It's far easier for the original developers to add this than for someone like me, who, despite nearly 3 decades experience with C and nearly 4 decades experience programming, knows nothing about the internal organization of qemu. The time cost of adding that in could be very high for me because of the need to spend lots of time reading the source code to come up to speed. It would be lower for them because they already should have some idea about how qemu's execution flow works, its contexts, and basic organization.

But, this is just a low level thought at the moment, triggered to talking about it because of this thread. If the need for this escalates enough, it might be worth doing it.

Quote:
Originally Posted by dyasny View Post
again, this is open source, what is stopping you from patching a package that doesn't work the way you want it to?
See above.


Quote:
Originally Posted by dyasny View Post
no it doesn't.
So I should look at vdsm instead of virsh/libvirt? No mention of "vdsm" in any Ubuntu package description. An independent project somewhere?

Quote:
Originally Posted by dyasny View Post
those users can be provided a simple start/stop functionality, without access to libvirt. libvirt provides it's own API, remember?
So it's really not a ready-to-go turn-key tool for managing virtualization.

Quote:
Originally Posted by dyasny View Post
actually, there's an entire part of selinux that deals in virtualization and libvirt specifically. if you're that concerned with security - http://selinuxproject.org/page/SVirt
So we need yet another tool to manage security for something that was previously reasonably secure, but became broken by a wrapper for which the only need I have is something that could have been done by handling a signal. How many more wrappers are going to be added to make this nice?

Quote:
Originally Posted by dyasny View Post
I think you're really confused about what is happening inside qemu. When you call a sigterm on a normal process, that's one flow. calling a sigterm on qemu (or qemu-kvm) will try to erform a sigterm on the process itself. This process is not one of the processes running inside the guest, but the process that emulates the CPU of the guest. and this process, when accessed from the host side, cannot provide access to the entire structure of processes running in the guest OS and using this virtual CPU, which from the host side, looks like a process. this is why a sigkill sent to qemu's process is roughly equivalent to pulling the plug on the VM.
Have you even been reading what I suggested? I am not suggesting that the SIGTERM be passed to the inner processes of the guest OS. I am ONLY suggesting that when the qemu process itself receives a SIGTERM from the hosting OS, that qemu simply emulate what some real hardware would do for the case of pressing a soft power off button. In the case of modern PCs, that would be some kind of ACPI message/status (I don't know the specific details there, nor do I need to if I'm not the one to code this) indicating the shutdown/poweroff request. As to what the guest OS does, it shall do whatever it is designed to do for that kind of power off scenario. It might be a Unix/Linux/BSD system which will trigger something to start it's own shutdown sequence, which in turn sends its own SIGTERM signals to processes inside the guest OS. Or it might be some new fangled OS that has no concept of SIGTERM or of processes or whatever. But if such an OS is designed to run on a PC, it may be designed to understand ACPI. It can do with it whatever makes sense for it (and some form of graceful shutdown makes sense). If the OS doesn't do it, then it's an issue with that OS.

Again, I am not suggesting, and never have suggested, that the host OS somehow be able to send SIGTERM to the guest OS's processes (if even there are any).

Quote:
Originally Posted by dyasny View Post
qemu performs a graceful shutdown by emulating an acpi shutdown request sent to it's virtual BIOS. Whether ACPI shutdowns are respected by the guest OS is entirely up to the guest OS.
But it does this only by a command to the monitor (yes, I have done that). I am suggesting that receiving a SIGTERM from the host OS it runs under also be another means to do the very same thing, no more, no less. At present, it does not do this. It may be doing some things like flushing buffers, but this isn't close to being graceful.
 
Old 06-10-2011, 03:08 AM   #23
dyasny
Member
 
Registered: Dec 2007
Location: Canada
Distribution: RHEL,Fedora
Posts: 836

Rep: Reputation: 91
ok, it seems to me like you have two issues here:
1. a missing feature to sends an acpi shutdown when a sigterm is received - not sure what priority such a request would receive
2. libvirts' security not being what you expected

two different projects, two bugzillas to open.
 
Old 06-10-2011, 08:53 AM   #24
Skaperen
Senior Member
 
Registered: May 2009
Location: WV, USA
Distribution: Slackware, CentOS, Ubuntu, Fedora, Timesys, Linux From Scratch
Posts: 1,777
Blog Entries: 20

Rep: Reputation: 115Reputation: 115
Quote:
Originally Posted by dyasny View Post
ok, it seems to me like you have two issues here:
1. a missing feature to sends an acpi shutdown when a sigterm is received - not sure what priority such a request would receive
2. libvirts' security not being what you expected

two different projects, two bugzillas to open.
I would not consider either of these to be bugs. They are features. A feature request would seem to me to be more appropriate.
 
Old 06-11-2011, 08:02 AM   #25
dyasny
Member
 
Registered: Dec 2007
Location: Canada
Distribution: RHEL,Fedora
Posts: 836

Rep: Reputation: 91
afaik feature requests are normally filed in bugzilla with the appropriate "feature request" flags
 
Old 06-13-2011, 07:30 AM   #26
Skaperen
Senior Member
 
Registered: May 2009
Location: WV, USA
Distribution: Slackware, CentOS, Ubuntu, Fedora, Timesys, Linux From Scratch
Posts: 1,777
Blog Entries: 20

Rep: Reputation: 115Reputation: 115
Quote:
Originally Posted by dyasny View Post
afaik feature requests are normally filed in bugzilla with the appropriate "feature request" flags
For the projects that ask for their feature requests in a bugzilla somewhere they operate in, that makes sense. Elsewhere, email to the developer mailing list if it is open, or to the developers directly, or just make a formal mention of it a forum.
 
  


Reply

Tags
kvm, qemu


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
QEMU guest paused after starting on boot dhamilton Linux - Virtualization and Cloud 1 01-01-2011 11:43 PM
[SOLVED] qemu ping guest os Squall90 Linux - Virtualization and Cloud 1 12-07-2010 08:31 AM
Share between Qemu-Kvm host and guest Alexvader General 1 06-13-2010 03:07 PM
Solaris 10 guest endless reboot under KVM/Qemu green_dood Linux - Software 6 12-13-2009 01:20 AM
sound in qemu guest os on debian? zero79 Debian 2 10-16-2005 06:42 PM


All times are GMT -5. The time now is 03:41 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration