Re: [kvm-devel] [Qemu-devel] Re: [PATCH] Add support for a configuration file
On Thu, May 15, 2008 at 11:04:47AM +0300, Avi Kivity wrote: Daniel P. Berrange wrote: With this kind of syntax, now tools generating config files need to make up unique names for each drive. So you'll probably end up with them just naming things based on the class name + a number appended. I would hope that tools don't have to resort to reading and writing these config files. Usually a management system would prefer storing parameters in its own database, and writing a temporary config file just to pass the data seems awkward. I would much prefer to see the command line and monitor retain full control over every configurable parameter. I expect that libvirt will create config files - it is only a matter of time before we hit the command line ARGV length limits - particularly with the -net and -drive syntax. People already requesting that we support guests with 16 disks, and 8 network cards so command lines get very long. I wouldn't write out the config file to disk though - I'd just send it on the fly on stdin -, eg 'qemu -config -' to tell it to read the config on its stdin. Regards, Daniel. -- |: Red Hat, Engineering, Boston -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 :| - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] Re: [PATCH] Add support for a configuration file
On Wed, May 14, 2008 at 02:26:40PM +0200, Fabrice Bellard wrote: Avi Kivity wrote: Fabrice Bellard wrote: I prefer: drive.file=foo.img drive.if=scsi That doesn't support multiple drives very well. Right, I realized it afterwards ! I suggested it because my original plan for the configuration file was based on this syntax with a strong inspiration from the OpenFirmware device tree. The idea was that the object name (drive here) had no hardcoded meaning, except for some predefined object names in order to keep a kind of backward compatibility with the current QEMU options. In order to create a new drive for example, you just have to do: mydrive.class=drive mydrive.if=scsi mydrive.file=abc.img With this kind of syntax, now tools generating config files need to make up unique names for each drive. So you'll probably end up with them just naming things based on the class name + a number appended. drive0.class=drive drive0.if=scsi drive0.file=foo.img drive1.class=drive drive1.if=scsi drive1.file=bar.img drive2.class=drive ... Which suggests it'd be better to take your original previous syntax example and using an explicit numeric component to represent lists of drives, eg drive.0.file=foo.img drive.0.if=scsi drive.1.file=bar.img drive.1.if=scsi drive.2.file=wiz.img drive.2.if=scsi Thus avoiding the need for adding the 'class' setting at all Dan. -- |: Red Hat, Engineering, Boston -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 :| - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] Re: [PATCH] Add support for a configuration file
On Wed, May 14, 2008 at 05:52:56PM +0300, Dor Laor wrote: On Wed, 2008-05-14 at 17:41 +0300, Avi Kivity wrote: Daniel P. Berrange wrote: That's very nearly YAML format[1], which is attractive because parsers are available in every major programming language, and it is still pretty human friendly. So my preference would be to go with the last option and make sure it really is YAML compliant so people can use standard tools for generating and parsing the format. Using a standard format has the added benefit that things like quoting are taken care of. Filenames with leading and trailing spaces, anyone? Embedded control characters? Please don't jump over me but I think it is worth mentioning OVF, at least for to know what's you opinions. OVF is insanely overcomplicated. It is also addressing a different problem space, that of virtual machine applinance interchange / distribution. And it is a disgusting format for users to deal with. Open Virtualization Format - http://www.vmware.com/appliances/learn/ovf.html It's xml based, supported by all major hypervisors, so qemu/kvm/xen users might eventually use a product that support OVF. Since its a new format it is open for changes and has lots of flexibility. As a start we don't have to be completely compatible with it. It is a 'open' format defined in secret invitation only cabal by a bunch of proprietry software vendors. No thanks. Dan. -- |: Red Hat, Engineering, Boston -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 :| - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] Re: [PATCH] Add support for a configuration file
On Wed, May 14, 2008 at 09:45:02AM -0500, Javier Guerra wrote: What about Lua? (http://www.lua.org) it started up as a configuration language, and evolved into a full programming language, while remaining _very_ light (less than 200K with all libraries), and wonderfully easy to embed into C programs. Config files are data, not programs. Xen made this mistake originally too just having python config files that were eval'd, but thankfully they've defined a sensible data format now. Dan. -- |: Red Hat, Engineering, Boston -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 :| - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Add support for a configuration file
On Tue, May 13, 2008 at 06:07:08PM -0500, Anthony Liguori wrote:
Anthony Liguori wrote:
I think this is pretty useful as-is. I think it also gives us a reasonable
way to move forward that will keep everyone pretty happy.
Here's a short example:
qemu-system-x86_64 -hda ~/images/linux.img -snapshot -vnc :2
Would become `foo.qemu':
# Main disk image
hda=/home/anthony/images/linux.img
# Redirect disk writes to a temporary image
snapshot
# Make the graphical display available on port 5902
vnc=:2
With:
qemu-system-x86_64 -config foo.qemu
One thought I had, is that it would be very nice to break up the -drive
file=foo.img,if=scsi syntax within the config file. In general, I'm
thinking something like:
Yes, that would be the main concern I have with the plain conversion
of existing command line args. It would essentially be limiting the
expressiveness of the config file to that of the command line - flat
key,value pairs. All we'd be gaining is avoidance of command line
length limits and persistent storage. Two worthy goals, but IMHO it
could be worth striving for more structure, so the config can explicitly
represent arrays and hashes as concepts.
[drive]
file=foo.img
if=scsi
This just feels like a bad 1/2 house compromise. Adds the complexity
of a more structured config file without giving the full benefits of
a more expressive format such as the 2 you show below.
drive {
file=foo.img
if=scsi
}
I like both this the next format because they're very expressive.
or even:
drive:
file=foo.img
if=scsi
That's very nearly YAML format[1], which is attractive because parsers
are available in every major programming language, and it is still
pretty human friendly.
So my preference would be to go with the last option and make sure
it really is YAML compliant so people can use standard tools for
generating and parsing the format.
Regards,
Daniel
[1] http://yaml.org/spec/1.2/
--
|: Red Hat, Engineering, Boston -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 :|
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] QEMU drive_init() Disk Format Security Bypass
On Thu, May 08, 2008 at 05:02:28PM +0300, Eren T?rkay wrote: Hello, An advisory about $subject was released today by secunia. The security flaw was fixed in QEmu SVN repository. Kvm uses some of the old version of qemu that I can't backport patch I grabbed from qemu svn repository. Could you look at this issue and provide a patch? KVM is synced to latest CVS version of QEMU on a regular basis. http://secunia.com/advisories/30111/ Svn commit: http://svn.savannah.gnu.org/viewvc/?view=revroot=qemurevision=4277 If you look at the KVM userspace code you'll see this patch is already included: http://git.kernel.org/?p=virt/kvm/kvm-userspace.git;a=commit;h=ce486fc1116eb53d40635be926bfa147ad520908 Regards, Daniel -- |: Red Hat, Engineering, Boston -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 :| - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] PATCH: Put QEMU Psuedo-TTY in raw mode
I'm forwarding this patch from upstream QEMU because its impotant to get
this fixed in KVM to make serial console installs usable now libvirt can
talk to KVM serial ports over PTYs.
It was reported in this thread:
http://lists.gnu.org/archive/html/qemu-devel/2008-05/msg00014.html
With the final verson of the patch here:
http://lists.gnu.org/archive/html/qemu-devel/2008-05/msg00135.html
Recently committed to SVN
http://svn.savannah.nongnu.org/viewvc?view=revroot=qemurevision=4338
[quote]
If running a QEMU instance with a serial/parallel device connected to a
Psuedo-TTY, eg '-serial pty', every \r\n sequence output by the guest
is getting translated into a \n\n sequence by the TTY layer. So clients
interacting with the serial port via a TTY done get the correct \r\n
sequence and text marches to the right and wraps. This is because the
TTY is not put into rawmode when QEMU sets it up.
The following patch is a re-diff of a patch applied to Xen's QEMU code.
It uses cfmakeraw() to ensure the TTY is put into rawmode, thus avoiding
the incorrect \r\n translations. It also switches to tcsetattr() on the
slave_fd instead of master_fd - although this is effectively the same on
Linux, only slave_fd works on Solaris. Finally it stops using the 'name'
arg to openpty() which is a security risk because its buffer size is
undefined. Instead it makes use of the ptsname() function.
[/quote]
I'm attaching a patch re-diff for KVM. Technically the #iddef _sun__
bit is useless for KVM, but better to keep 100% in sync with QEMU code
for easier future merges
Signed-off-by: Daniel P. Berrange [EMAIL PROTECTED]
Regards
Daniel.
diff --git a/qemu/vl.c b/qemu/vl.c
index 74be059..b6b1c58 100644
--- a/qemu/vl.c
+++ b/qemu/vl.c
@@ -2301,28 +2301,78 @@ static CharDriverState *qemu_chr_open_stdio(void)
return chr;
}
+#ifdef __sun__
+/* Once Solaris has openpty(), this is going to be removed. */
+int openpty(int *amaster, int *aslave, char *name,
+struct termios *termp, struct winsize *winp)
+{
+const char *slave;
+int mfd = -1, sfd = -1;
+
+*amaster = *aslave = -1;
+
+mfd = open(/dev/ptmx, O_RDWR | O_NOCTTY);
+if (mfd 0)
+goto err;
+
+if (grantpt(mfd) == -1 || unlockpt(mfd) == -1)
+goto err;
+
+if ((slave = ptsname(mfd)) == NULL)
+goto err;
+
+if ((sfd = open(slave, O_RDONLY | O_NOCTTY)) == -1)
+goto err;
+
+if (ioctl(sfd, I_PUSH, ptem) == -1 ||
+(termp != NULL tcgetattr(sfd, termp) 0))
+goto err;
+
+if (amaster)
+*amaster = mfd;
+if (aslave)
+*aslave = sfd;
+if (winp)
+ioctl(sfd, TIOCSWINSZ, winp);
+
+return 0;
+
+err:
+if (sfd != -1)
+close(sfd);
+close(mfd);
+return -1;
+}
+
+void cfmakeraw (struct termios *termios_p)
+{
+termios_p-c_iflag =
+~(IGNBRK|BRKINT|PARMRK|ISTRIP|INLCR|IGNCR|ICRNL|IXON);
+termios_p-c_oflag = ~OPOST;
+termios_p-c_lflag = ~(ECHO|ECHONL|ICANON|ISIG|IEXTEN);
+termios_p-c_cflag = ~(CSIZE|PARENB);
+termios_p-c_cflag |= CS8;
+
+termios_p-c_cc[VMIN] = 0;
+termios_p-c_cc[VTIME] = 0;
+}
+#endif
+
#if defined(__linux__) || defined(__sun__)
static CharDriverState *qemu_chr_open_pty(void)
{
struct termios tty;
-char slave_name[1024];
int master_fd, slave_fd;
-#if defined(__linux__)
-/* Not satisfying */
-if (openpty(master_fd, slave_fd, slave_name, NULL, NULL) 0) {
+if (openpty(master_fd, slave_fd, NULL, NULL, NULL) 0) {
return NULL;
}
-#endif
-/* Disabling local echo and line-buffered output */
-tcgetattr (master_fd, tty);
-tty.c_lflag = ~(ECHO|ICANON|ISIG);
-tty.c_cc[VMIN] = 1;
-tty.c_cc[VTIME] = 0;
-tcsetattr (master_fd, TCSAFLUSH, tty);
+/* Set raw attributes on the pty. */
+cfmakeraw(tty);
+tcsetattr(slave_fd, TCSAFLUSH, tty);
-fprintf(stderr, char device redirected to %s\n, slave_name);
+fprintf(stderr, char device redirected to %s\n, ptsname(master_fd));
return qemu_chr_open_fd(master_fd, master_fd);
}
--
|: Red Hat, Engineering, Boston -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 :|
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel
Re: [kvm-devel] Feedback and errors
On Fri, May 02, 2008 at 01:52:18PM +0300, Avi Kivity wrote: nadim khemir wrote: Hi, great work. While playing with kvm-qemu I noticed a few points that might be of interrest: 1/ -loadvm and -snapshot don't work together. It works as if -loadvm wasn't passed as argument 2/ two instances of kvm can be passed the same -hda. There is no locking whatsoever. This messes up things seriously. That depends entirely on what you are doing with the disk in the guest OS. The disk could be hosting a cluster filesystem. The guest OS could be running on a read-only root FS. The disk could be application raw data storage which can be shared (eg Oracle RAC). And if the disk is backed by a physical volume which is accessible to multiple hosts, locking on the VM's host won't provide any safety against VMs on another host accessing it. These two are upstream qemu problems. Copying qemu-devel. I guess using file locking by default would improve the situation, and we can add a -drive ...,exclusive=no option for people playing with cluster filesystems. Turning on file locking by default will break existing apps / deployments using shared disks. IMHO this is a policy decision that should be solved at ahigher level in the management stack where a whole world view is available rather than QEMU which only knows about its own VM host. Dan. -- |: Red Hat, Engineering, Boston -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 :| - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] performance with guests running 2.4 kernels (specifically RHEL3)
On Wed, Apr 30, 2008 at 07:39:53AM -0600, David S. Ahern wrote: Avi Kivity wrote: David S. Ahern wrote: Another tidbit for you guys as I make my way through various permutations: I installed the RHEL3 hugemem kernel and the guest behavior is *much* better. System time still has some regular hiccups that are higher than xen and esx (e.g., 1 minute samples out of 5 show system time between 10 and 15%), but overall guest behavior is good with the hugemem kernel. Wait, the amount of info here is overwhelming. Let's stick with the current kernel (32-bit, HIGHMEM4G, right?) Did you get any traces with bypass_guest_pf=0? That may show more info. My preference is to stick with the standard, 32-bit RHEL3 kernel in the guest. My point in the last email was that the hugemem kernel shows a remarkable difference (it uses 3-levels of page tables right?). I was hoping that would ring a bell with someone. IIRC, the RHEL-3 hugemem kernel is using the 4g/4g split patches which give userspace and kernelspace their own independant pagetables http://lwn.net/Articles/39925/ http://lwn.net/Articles/39283/ Dan. -- |: Red Hat, Engineering, Boston -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 :| - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Make virtio devices multi-function
On Tue, Apr 22, 2008 at 02:26:45PM -0300, Marcelo Tosatti wrote: On Tue, Apr 22, 2008 at 11:31:11AM -0500, Anthony Liguori wrote: Avi Kivity wrote: Anthony Liguori wrote: I think we need to decide what we want to target in terms of upper limits. With a bridge or two, we can probably easily do 128. If we really want to push things, I think we should do a PCI based virtio controller. I doubt a large number of PCI devices is ever going to perform very well b/c of interrupt sharing and some of the assumptions in virtio_pci. If we implement a controller, we can use a single interrupt, but multiplex multiple notifications on that single interrupt. We can also be more aggressive about using shared memory instead of PCI config space which would reduce the overall number of exits. We should increase the number of interrupt lines, perhaps to 16. Using shared memory to avoid exits sounds very good idea. We could easily support a very large number of devices this way. But again, what do we want to target for now? I think that for networking we should keep things as is. I don't see anybody using 100 virtual NICs. The target was along the lines of 20 nics + 80 disks. Dan? I've already had people ask for ability to as many as 64 disks and 32 nics with Xen, so to my mind, the more we support the better. 100's if possible. Dan. -- |: Red Hat, Engineering, Boston -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 :| - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 1/3] Refactor AIO interface to allow other AIO implementations
On Thu, Apr 17, 2008 at 02:26:50PM -0500, Anthony Liguori wrote: Posix AIO, especially as used by QEMU, is not very efficient for disk IO. This patch introduces an AIO abstract to allow multiple AIO implements to be used. We can't simply replace posix-aio by linux-aio because linux-aio only works on some filesystems and only with files opened with O_DIRECT. This patch adds a command line option (-aio) to select the AIO implementation to be used. It avoids code motion to allow for easy review. The next patch separates out the posix-aio implementation. This is not a very pleasant user experiance. They can not should not be expected to figure out which AIO impl works with their particular filesystem. If the linux-aio impl doesn't work in some cases, then the code should detect these and automatically fallback to posix-aio. The user should not have to use a -aio flag to make it work. Dan. -- |: Red Hat, Engineering, Boston -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 :| - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 1/3] Refactor AIO interface to allow other AIO implementations
On Thu, Apr 17, 2008 at 02:41:32PM -0500, Anthony Liguori wrote: Daniel P. Berrange wrote: On Thu, Apr 17, 2008 at 02:26:50PM -0500, Anthony Liguori wrote: Posix AIO, especially as used by QEMU, is not very efficient for disk IO. This patch introduces an AIO abstract to allow multiple AIO implements to be used. We can't simply replace posix-aio by linux-aio because linux-aio only works on some filesystems and only with files opened with O_DIRECT. This patch adds a command line option (-aio) to select the AIO implementation to be used. It avoids code motion to allow for easy review. The next patch separates out the posix-aio implementation. This is not a very pleasant user experiance. They can not should not be expected to figure out which AIO impl works with their particular filesystem. If the linux-aio impl doesn't work in some cases, then the code should detect these and automatically fallback to posix-aio. The user should not have to use a -aio flag to make it work. Those cases aren't always discoverable. Linux-aio just falls back to using synchronous IO. It's pretty terrible. We need a new AIO interface for Linux (and yes, we're working on this). Once we have something better, we'll change that to be the default and things will Just Work for most users. If QEMU can't discover cases where it won't work, what criteria should the end user use to decide between the impls, or for that matter, what criteria should a management api/app like libvirt use ? If the only decision logic is 'try it benchmark your VM' then its not a particularly useful option. I've basically got a choice of making libvirt always ad '-aio linux' or never add it at all. My inclination is to the latter since it is compatible with existing QEMU which has no -aio option. Presumably '-aio linux' is intended to provide some performance benefit so it'd be nice to use it. If we can't express some criteria under which it should be turned on, I can't enable it; where as if you can express some criteria, then QEMU should apply them automatically. Pushing this choice of AIO impls to the app or user invoking QEMU just does not seem like a win here. Dan. -- |: Red Hat, Engineering, Boston -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 :| - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 1/1] direct mmio for passthrough - kernel part
On Tue, Apr 01, 2008 at 08:03:14PM +0300, Avi Kivity wrote: Anthony Liguori wrote: Avi Kivity wrote: [EMAIL PROTECTED] wrote: From: Ben-Ami Yassour [EMAIL PROTECTED] Enable a guest to access a device's memory mapped I/O regions directly. Userspace sends the mmio regions that the guest can access. On the first page fault for an access to an mmio address the host translates the gva to hpa, and updates the sptes. Can you explain why you're not using the regular memory slot mechanism? i.e. have userspace mmap(/dev/mem) and create a memslot containing that at the appropriate guest physical address? /dev/mem is often restricted in what memory can be mapped. Please elaborate. The /dev/mem, /dev/kmem devices have a special SELinux context memory_device_t and very few application domains are allowed to access them. THe KVM/QEMU policy will not allow this for example. Basically on the X server, HAL and dmidecode have access in current policy. It would be undesirable to have to all KVM guests full access to /dev/mem, so a more fine grained access method would have benefits here. Dan. -- |: Red Hat, Engineering, Boston -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 :| - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 1/1] direct mmio for passthrough - kernel part
On Tue, Apr 01, 2008 at 08:10:31PM +0200, Andrea Arcangeli wrote: On Tue, Apr 01, 2008 at 06:18:07PM +0100, Daniel P. Berrange wrote: and very few application domains are allowed to access them. THe KVM/QEMU policy will not allow this for example. Basically on the X server, HAL and dmidecode have access in current policy. It would be undesirable to have to all KVM guests full access to /dev/mem, so a more fine grained access method would have benefits here. But pci-passthrough can give a root on the host even to the ring0 guest, just like /dev/mem without VT-d, so there's no muchx difference with using /dev/mem as far as security is concerned. Only on the CPUs including VT-d it's possible to retain a mostly equivalent security level despite pci-passthrough. Clearly it is a loosing battle without VT-d. That doesn't mean we should design it to loose in general. So we should design to that when we do have VT-D it will have the maximum security possible. VT-d will only become more widespread over time. Dan. -- |: Red Hat, Engineering, Boston -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 :| - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [ANNOUNCE] kvm-guest-drivers-windows-1
On Tue, Mar 18, 2008 at 05:01:09PM +0200, Avi Kivity wrote: This is the first release of network drivers for Windows guests running on a kvm host. The drivers are intended for Windows 2000 and Windows XP 32-bit. kvm-61 or later is needed in the host. At the moment only binaries are available. There's no license file inside the ZIP file - what license are the binaries re-distributed under ? Regards, Dan. -- |: Red Hat, Engineering, Boston -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 :| - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] [PATCH] use a thread id variable
On Sun, Mar 09, 2008 at 11:26:43AM +0200, Gilad Ben-Yossef wrote: Glauber Costa wrote: This patch introduces a thread_id variable to CPUState. It's duty will be to hold the process, or more generally, thread id of the current executing cpu env-nb_watchpoints = 0; +#ifdef __WIN32 +env-thread_id = GetCurrentProcessId(); +#else +env-thread_id = getpid(); +#endif *penv = env; hmm... maybe I'm missing something, but in Linux at least I think you would prefer this to be gettid() rather then getpid as each CPU has it's own thread, not a different process. No, this patch is the generic QEMU code, which is single threaded, so using getpid() is correct. Glauber has a separate patch in this series which implements the equivalent for KVM which does indeed use gettid() Regards, Dan. -- |: Red Hat, Engineering, Boston -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 :| - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0/8] RFC: vcpu pinning at qemu start
On Tue, Mar 04, 2008 at 01:28:24PM -0600, Anthony Liguori wrote: Glauber Costa wrote: My main interest is in management tools being able to specify pinning set ups at VM creation time. As I said, it can be done through tools like taskset, but then you'd have to know: * when are the threads created * which thread ids corresponds to each cpu And of course, for an amount of time, the threads will be running in a wrong cpu, which may affect workloads running there. (which is a case cpu pinning usually tries to address) A management tool can start QEMU with -S to prevent any CPUs from running, query the VCPU=thread id relationship (modifying info cpus would be a good thing to do for this), taskset, and then run 'cont' in the monitor if they desperately need this functionality. However, I don't think the vast majority of people need this particular functionality. I fully expected to have to run QEMU with -S and then use cont if I were todo CPU pinning from libvirt. The only info I'd need to get is the PID - vCPU mapping data. Then I can use regular Linux taskset capabilities from libvirt to assign the initial pCPU - vCPU mapping and finally run 'cont'. My feeling is that adding an interface to do this in QEMU encourages people to not use the existing Linux tools for this or worse yet, to think they can do a better job than Linux. The whole reason this exists in Xen is that Xen's schedulers were incapable of doing CPU migration historically (which is no longer true since the credit scheduler). It was necessary to specify pinning upon creation or you were stuck with round-robin placement. So libvirt has APIs for this because they were part of the Xen API because it was needed to get reasonable performance at some point in time on Xen. I don't think this behavior is useful for KVM though. Just because Xen does it doesn't imply that we should do it. I agree that adding QEMU commands for stuff which Linux already has APIs and tools is a bad idea. QEMU/KVM is much nicer to manage than Xen, precisely because I can already use Linux APIs process management tools. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [patch 14/23] QEMU/KVM: device hot-add
On Tue, Mar 04, 2008 at 01:30:42PM -0600, Anthony Liguori wrote:
Daniel P. Berrange wrote:
On Tue, Mar 04, 2008 at 03:34:33PM -0300, Marcelo Tosatti wrote:
Add monitor command to hot-add PCI devices (nic and drive).
[snip]
Index: kvm-userspace.hotplug/qemu/monitor.c
===
--- kvm-userspace.hotplug.orig/qemu/monitor.c
+++ kvm-userspace.hotplug/qemu/monitor.c
@@ -1354,6 +1354,7 @@ static term_cmd_t term_cmds[] = {
{ migrate_set_speed, s, do_migrate_set_speed,
value, set maximum speed (in bytes) for migrations },
{ cpu_set, is, do_cpu_set_nr, cpu [online|offline], change
cpu state },
+{ pci_add, ss, device_hot_add, nic|drive
[vlan=n][,macaddr=addr][,model=type]
[[file=file][,if=type][,bus=n][,unit=m][,media=d][index=i]], hotadd PCI
device },
This syntax is not very nice IMHO. We should have explicit commands
for the different types of device,
ie
nic_add [vlan=n][,macaddr=addr][,model=type]
drive_add [[file=file][,if=type][,bus=n][,unit=m][,media=d][index=i]]
ie, follow naming of the command line args -nic, and -drive.
This also keeps 'pci_add' as a command name available for future use to
do generic host-guest pci device pass-through.
There is symmetry with pci_add and usb_add since usb_add takes either a
USB device identifier or the name of an emulated device along with
parameters. So I prefer the pci_add syntax just to maintain consistency
with the rest of QEMU.
This is true, but the usb_add/remove syntax is horrible to work with. One
of the reasons I've not added USB hotplug/remove to libvirt yet is the
difficulty (perhaps even impossibility) of reliably finding out the USB
device number associated with the device that was added. I guess ideally
the add command would have to print out / return the number associated
with the device, which libvirt could record for use when it later comes
time to remove the device.
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [patch 23/23] QEMU/KVM: device hot-remove
On Tue, Mar 04, 2008 at 05:00:09PM -0300, Marcelo Tosatti wrote: On Tue, Mar 04, 2008 at 01:32:22PM -0600, Anthony Liguori wrote: Daniel P. Berrange wrote: nic_remove [vlan=n][,macaddr=addr][,model=type] drive_remove [[file=file][,if=type][,bus=n][,unit=m][,media=d][index=i]] Though, perhaps still allow removal based on the PCI device ID as an alternative for those who happen to have that data available. pci_remove is consistent with usb_del and things like stopcapture. The thing to add would be an info pci that let a user associate the slot number with higher level information about the device. Its there already: (qemu) info pci Bus 0, device 0, function 0: Host bridge: PCI device 8086:1237 Bus 0, device 1, function 0: ISA bridge: PCI device 8086:7000 Bus 0, device 1, function 1: IDE controller: PCI device 8086:7010 BAR4: I/O at 0xc000 [0xc00f]. Bus 0, device 1, function 3: Bridge: PCI device 8086:7113 IRQ 9. Bus 0, device 2, function 0: VGA controller: PCI device 1013:00b8 BAR0: 32 bit memory at 0xf000 [0xf1ff]. BAR1: 32 bit memory at 0xf200 [0xf2000fff]. Bus 0, device 3, function 0: Ethernet controller: PCI device 10ec:8139 IRQ 11. BAR0: I/O at 0xc100 [0xc1ff]. BAR1: 32 bit memory at 0xf2001000 [0xf20010ff]. And block,network: (qemu) info block ide0-hd0: type=hd removable=0 file=/root/images/marcelo5.img ro=0 drv=raw ide1-cd0: type=cdrom removable=1 locked=0 [not inserted] floppy0: type=floppy removable=1 locked=0 [not inserted] sd0: type=floppy removable=1 locked=0 [not inserted] scsi0-hd0: type=hd removable=0 file=/tmp/bigfile ro=0 drv=raw scsi0-hd1: type=hd removable=0 file=/tmp/bigfile.2 ro=0 drv=raw (qemu) info network VLAN 0 devices: tap: ifname=tap0 setup_script=qemu-ifup-tap0 rtl8139 pci macaddr=52:54:00:12:34:56 This is utterly horrible for a human to parse use if they're using the QEMU monitor, let alone something that libvirt could parse. In fact this doesn't let you map between the network device pci device if there is more than one device added because 'info pci' doesn't show the MAC address info, and 'info network' does not show any PCI device number info - the same for disks. Perhaps reporting the bus,slot pair for PCI devices on block and network info provides the necessary information that you need Dan? Oh, and unit,bus,media for block too. Yes, getting PCI (bus,slot,func) triple reported against each line in the 'info block' and 'info network' data would at least let you reliably map from NIC - PCI devs. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [FW: Announcing oVirt: web based VM management platform]
The announcement below may well be of interest to people involved in KVM. oVirt is using libvirt as its mnagement API, and the current builds use Fedora 9 + KVM to get a cutting edge virtualization platform / technology in combination with cutting edge Linux kernels :-) If anyone's interested, there's mailing list / IRC details below... Regards, Dan. - Forwarded message from Hugh O. Brock [EMAIL PROTECTED] - Date: Thu, 14 Feb 2008 17:04:56 -0500 From: Hugh O. Brock [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: [et-mgmt-tools] Announcing oVirt Announcing oVirt It is my pleasure to announce oVirt, the next step in open virtual machine management. oVirt is: * A small OS image that runs libvirt and hosts virtual machines * A Web-based virtual machine management console oVirt goals: * Empower virtual machine owners without giving up control of hardware * Automate virtual machine clustering, load balancing, and SLA maintenance * Simplify management of large numbers of machines * Work across platforms and architectures oVirt uses: * A kerberos/LDAP server for authentication and authorization (oVirt ships with FreeIPA) * DNS/DHCP services on the local LAN -- or provides them for oVirt hosts over a private network if desired * Libvirt for virtual machine management, storage management, and secure remote communication * collectd for stats gathering and monitoring * Rails for rapid, flexible development oVirt mailing list: http://www.redhat.com/mailman/listinfo/ovirt-devel oVirt IRC: irc.freenode.net/#ovirt oVirt website: http://ovirt.org We encourage anyone interested to download the source (git clone git://git.et.redhat.com/ovirt) or the prebuilt appliance (http://ovirt.org/download). Let us know what you think! Enjoy, --Hugh Brock [EMAIL PROTECTED] ___ et-mgmt-tools mailing list [EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/et-mgmt-tools - End forwarded message - -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Slow Kernel Boot
On Tue, Jan 08, 2008 at 11:13:08AM -0800, Dave Hansen wrote:
On Tue, 2008-01-08 at 12:12 +0530, Amit Shah wrote:
BIOS-provided physical RAM map:
BIOS-e820: - 0009fc00 (usable)
BIOS-e820: 0009fc00 - 000a (reserved)
BIOS-e820: 000e8000 - 0010 (reserved)
BIOS-e820: 0010 - fffbd000 (usable)
BIOS-e820: fffbd000 - (reserved)
Note that this is with '-m 1G'!! It looks to me like one of those
And there lies the problem. qemu doesn't understand suffixes like 'G'.
If you
pass -m 1024, you'll boot just fine.
This is really annoying of qemu (it should either accept that input
properly
or bail out); a patch is welcome!
OK. Here's a function stolen blatantly from the kernel. Seems to work
What license was this under originally ? The kernel is typically GPLv2,
while QEMU's core infrastructure is BSD (only some device emulation
is GPL). So not a good idea if you want this to go into upstream QEMU.
--- orig/qemu-0.9.1/vl.c 2008-01-06 11:38:42.0 -0800
+++ qemu-0.9.1/vl.c 2008-01-08 11:23:29.0 -0800
@@ -8052,6 +8052,47 @@
}
#endif
+/**
+ * memparse - parse a string with mem suffixes into a number of bytes
+ * @ptr: Where parse begins
+ *
+ * Parses a string into a number. The number stored at @ptr is
+ * potentially suffixed with %M (for megabytes, or 1048576 bytes)
+ * or %G (for gigabytes, or 1073741824). If the number is
+ * suffixed with M or G, then the return value is the number
+ * multiplied by one megabyte or one gigabyte, respectively. No
+ * suffix implies megabytes.
+ */
+
+unsigned long long memparse (const char *ptr)
+{
+ char *endptr;
+ unsigned long ret = strtoull(ptr, endptr, 0);
32-bit overflow here on i686. Should be unsigned long long if
you want to support 2 G on a 32-bit platform.
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 2/6] virtio block driver for QEMU (v2)
On Sat, Nov 10, 2007 at 09:20:36PM -0600, Anthony Liguori wrote: This patch implements a very naive virtio block device backend in QEMU. There's a lot of room for future optimization. We need to merge a -disk patch before we can provide a mechanism to expose this to users. The latest generation of -disk patches posted to upstream qemu-devel are looking quite promising with any luck should get accepted for merge in the very near future. Are these block net drivers able todo hot-plug/unplug after a domain has been created ? If so we'd also want to have disk_add/disk_remove and net_add/net_remove monitor commands (cf usb_add/usb_remove) for on-the-fly changes. Regards Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] modular dependencies for kvm's qemu
On Tue, Oct 16, 2007 at 04:22:14AM -0500, Carlo Marcelo Arenas Belon wrote: Greetings, kvm's configure calls qemu's configure with --enable-alsa, making the existence and use of alsa a dependency; with the import of the latest CVS qemu, a similar implicit dependency has been added for gnutls (required for TLS support for qemu's vnc server). the following proposed patch (which is a combined patch from a 2 patch series) allows kvm's configure to enable alsa or disable vnc tls conditionally. I am curious if the approach taken for alsa (which is the one that fits what qemu's configure allows for this case) is acceptable or not, as it will change the dependency on alsa from being required by default to optional and unless --enable-alsa is used. So why don't you use --disable-alsa in the patch instead. It seems like rather a bad idea to suddenly switch the configure script defaults in the way you suggest for alsa. It really wouldn't be much harder to set enable_alsa=1 in the top of configure, and then have the flag toggle it to off. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [ANNOUNCE] kvm-46 release
On Wed, Oct 10, 2007 at 10:28:24AM +0200, Avi Kivity wrote: We've now switched to allocating guest memory in userspace rather than in the kernel. This is important if you have a mainframe, but also if you want to share memory between guests and implement nice features like swapping. Is the memory allocation swappable by default, or still pinned in RAM by default ? Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [ kvm-Bugs-1802223 ] nics have same hw address (rtl8139)
On Wed, Sep 26, 2007 at 05:47:20PM +0200, Laurent Vivier wrote: Hi, I think there is a bug in qemu RTL8139. RTL8139 uses: cpu_register_physical_memory(addr + 0, 0x100, s-rtl8139_mmio_io_addr); But in the comment of cpu_register_physical_memory() we have: 'size' must be a multiple of the target page size. And I think 0x100 is not a multiple of target page size :-P Latest upstream QEMU has fixed its memory handling so that MMIO regions do not need to be a multiple of page size. Changing RTL8139 to use a block of size 0x1000 is a reasonable short term hack around the problem, but syncing with latest QEMU is the real solution, since there are other places in the code which will have similar issues. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] make kvm service script transfer dhclient settings correctly
On Sun, Sep 16, 2007 at 11:52:56AM +0200, Avi Kivity wrote: Ferry Huberts wrote: Avi Kivity wrote: Ferry Huberts wrote: I really recommend against using the kvm initscript... it is fragile is broken. On Fedora, you can use the standard initscripts (well, they are fragile and broken too, but they are more complete than the kvm initscript): I entirely agree with your recommendation against using the kvm initscript. We don't include in the Fedora KVM rpms, and the equivalent script shipped with Xen has inflicted untold misery bug report chaos. Using the distro specific initscripts for setting up bridges is a much more predictable and reliable approach. [EMAIL PROTECTED] ~]$ cat /etc/sysconfig/network-scripts/ifcfg-sw0 DEVICE=sw0 BOOTPROTO=dhcp HWADDR=00:0F:EA:6E:1E:F0 ONBOOT=yes TYPE=Bridge DHCP_HOSTNAME=blast [EMAIL PROTECTED] ~]$ cat /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=eth0 BRIDGE=sw0 HWADDR=00:0F:EA:6E:1E:F0 ONBOOT=yes TYPE=Ethernet This setup starts dhcp directly on the bridge, without the need to move things around. See especially the 'TYPE=Bridge' and 'BRIDGE=sw0' statements. This is similar to the way we document bridge setup in Fedora, although for the sake of consistent nomenculture with Xen, we have peth0 being the physical device eth0 being the bridge device. Either way its just naming, the end result is functionally the same. Libvirt also provides a 'virtual network' which is an isolated bridge device, connected to the physical devices using NAT as our 'out of the box' connectivity. There's a short blog post with recommendations for KVM networking on Fedora http://watzmann.net/blog/index.php/2007/04/27/networking_with_kvm_and_libvirt I'll remove the script unless anyone sees an objection? Gets my vote. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] expose host CPU features to guests
On Wed, Sep 05, 2007 at 10:34:45PM +0300, Avi Kivity wrote: Anthony Liguori wrote: On Wed, 2007-09-05 at 20:45 +0300, [EMAIL PROTECTED] wrote: Hi, It's a pity not to use a host CPU feature if it is available. This patch exposes host CPU features to guests. It allows fine-tuning the presented features from the command-line. The code could use some serious clean ups, but I think it is interesting enough right now. I'd be happy to hear your opinion and suggestions. The diff are done against qemu cvs. I tried it with kvm, but I thinkg it should be useful also for kqemu. I like this idea but I have some suggestions about the general approach. I think instead of defining another machine type, it would be better to just have a command line option like -cpuid that took a comma separate string of features with all meaning all features that the host has. I think qemu-cvs has a -cpu option for non-x86 which could be used for this. Agree machine types are the wrong approach. Yep, machine types are already used to switch between a different concept so using the new -cpu option would make sense. Could perhaps extend the syntax so that instead of '-cpu TYPE' it used '-cpu TYPE,FEATURES' where FEATURES was an optional list of CPU features to allow - though perhaps with some shortcut for specifying 'match the host cpu type features'. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] a (bad) kvm story from a plain user
On Wed, Aug 15, 2007 at 01:43:58AM -0300, Jorge Luc?ngeli Obes wrote: On 8/15/07, Daniel P. Berrange [EMAIL PROTECTED] wrote: On Tue, Aug 14, 2007 at 10:26:24PM -0500, Anthony Liguori wrote: On Wed, 2007-08-15 at 05:44 +0300, Avi Kivity wrote: Slohm Gadaburi wrote: How can I know if the qemu I ran took advantage of the kvm module ? No one mentioned my favorite: when kvm is in control, the title bar of the guest console window changes to QEMU/KVM. I ran /usr/bin/qemu as I didn't have /usr/local/kvm/bin/qemu like the HOWTO mentioned (as I didn't compiled the kvm bundle myself...). Well, the HOWTO assumes you did all the previous steps. We should have a HOWTO/Ubuntu for distro users (but really, Ubuntu should have a gui for this). virt-manager isn't currently packaged for Ubuntu (even in Gutsy). If there any Ubuntu devs out there, please consider packaging it! There are virt-manager packages for Debian so it shouldn't be hard to port them. Just today I was trying virt-manager and libvirt. I got this error when creating a VM: Unable to complete install: 'virDomainCreateLinux() failed Cannot find QEMU binary /usr/bin/qemu: No such file or directory' The KVM support in libvirt is just an extension to the generic QEMU support. So you have to have a plain QEMU installed, as well as the KVM-ified version. To avoid filename clashes it expects the KVM version of QEMU to be named /usr/bin/qemu-kvm. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] a (bad) kvm story from a plain user
On Tue, Aug 14, 2007 at 10:26:24PM -0500, Anthony Liguori wrote: On Wed, 2007-08-15 at 05:44 +0300, Avi Kivity wrote: Slohm Gadaburi wrote: How can I know if the qemu I ran took advantage of the kvm module ? No one mentioned my favorite: when kvm is in control, the title bar of the guest console window changes to QEMU/KVM. I ran /usr/bin/qemu as I didn't have /usr/local/kvm/bin/qemu like the HOWTO mentioned (as I didn't compiled the kvm bundle myself...). Well, the HOWTO assumes you did all the previous steps. We should have a HOWTO/Ubuntu for distro users (but really, Ubuntu should have a gui for this). virt-manager isn't currently packaged for Ubuntu (even in Gutsy). If there any Ubuntu devs out there, please consider packaging it! There are virt-manager packages for Debian so it shouldn't be hard to port them. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] web interface?
On Thu, Aug 02, 2007 at 02:25:46AM +1000, Paul J R wrote: Yeah, i did look at libvirt and it remains an option. Originally this was all going to be built around xen (I got xen running on two servers and had it changing the number of cpu's in a pv host on the fly as well as live-migrate guests and went oo). But then kvm got merged and so i went thru a phase of trying to decide which would be better suited to my little project. Around the same time frame, f7 came out and i had a good play with virt manager (as well as a few other things like the qemu virtualpc for webmin plugin). Libvirt was right after that and i wrote a bit of test code to see what i could do with it mostly because it solved part of the equation. After much agonizing though i settled on native kvm/qemu mostly for simplicity and its ability to run non-modified guests on non-hardware virt capable cpus. libvirt could help in reference to the points elsewhere in this thread about some people prefering to use a Web UI, and others preferring to automate with command line tools. The command line virsh tool would see exactly the same state as the Web UI they'd each see the results of the other's changes. We realize there are some things that libvirt doesn't support in its APIs yet, and so welcome feedback from any users developers about capabilites that they need so we can adapt prioritize future development plans. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Ways to exit from kvm on behalf of the quest system?
On Wed, Aug 01, 2007 at 12:48:51PM -0400, Dimitry Golubovsky wrote: OK, I'll try to summarize that. However I'd also like to make a feature request: a virtual character device (sort of a virtual serial line) that the guest OS might use to communicate with the QEMU monitor. That might solve many problems. Unless you whitelist which monitor commands it can run this would be a significant security hole. eg a guest could run 'usb_add disk /some/path' To get access to arbitrary files disks from the host. Dan, -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] web interface?
On Wed, Aug 01, 2007 at 01:52:39AM +1000, Paul J R wrote: Hi guys, I had a quick question. I was playing around writing a php-based web interface for KVM. Basically something that would allow you to use a tiny distro and let you manage disk/net etc via php (atm its crude to say the least). It all seems relatively straight forward except for one component - the console bits. I wanted to make it so you could click on your new vm, then click on a console link and *poof* your console appears on your web browser via an embedded java applet. The problem is security, Authenticating users on the page is simple enough, but i cant see a method by which i could put a password on the vnc port in qemu? Watch this space. I will be submitting patches to upstream QEMU either today or tomorrow which will enable password support in VNC. It will also provide for optional TLS encryption, and x509 certificates for both client and server validation authentication. Ideally, what i would like to be able to do is when someone accesses the console it sets the password randomly, then embed's it into the request. Once everyone disconnects it resets the password (but thats not quite so important at this point). My patches will cope with that scenario. They provide a monitor command to let you change the password on the fly. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] web interface?
On Wed, Aug 01, 2007 at 03:26:57AM +1000, Paul J R wrote: Wow, those are both pretty informative. Given both those replies, i'm wondering if i should continue? The kind of thing I had in mind was relatively simple, it'd be a miniture OS that would boot up (over pxe/usb/cdrom) into ram (its about 90mb of ram so far with kvm and a full kernel + kudzu and few small components such as a httpd+php). it searches for a configuration partition and away you go managing the rest via the web interface. I had clustering/multi-node sitting at the back of my head as well. FYI, libvirt also now provides secure remote access, so it can be used off-node from the box being managed. Access is either tunnelled over SSH, or directly connected using TLS + x509 certificates. http://libvirt.org/remote.html This would enable a single web service to manage multiple hosts securely. http://libvirt.org/remote.html I illustrated some very simple examples here, showing the same commands talking to Xen, and KVM/QEMU both locally and remotely over SSH, or TLS. http://berrange.com/personal/diary/2007/07/libvirt-remote-management-news Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] web interface?
On Tue, Jul 31, 2007 at 09:33:30AM -0700, Matthew Kent wrote: The problem is security, Authenticating users on the page is simple enough, but i cant see a method by which i could put a password on the vnc port in qemu? http://fedoraproject.org/wiki/Releases/FeatureVirtSecurity is a project tasked with improving VNC security among other things, right now qemu doesn't have many options in that regard. Yep, this is the code I'm just finishing off now in preparation for review on QEMU mailing lists. Ideally, what i would like to be able to do is when someone accesses the console it sets the password randomly, then embed's it into the request. Once everyone disconnects it resets the password (but thats not quite so important at this point). Xen has patches to qemu vnc for supporting passwords if you need a starting point. Though iirc they are pulled from the xenstore or whatever they call it, so it would need some work I'd imagine. The Xenstore integration made it pretty useless as a basis for password support in general QEMU codebase :-( Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] VM id in KVM?
On Mon, Jul 23, 2007 at 02:19:41PM +0300, Avi Kivity wrote: Avi Kivity wrote: Carsten Otte wrote: Avi Kivity wrote: From a Linux point of view, the pid identifies the VM. A management application can, however, use its own VM identifiers as it sees fit, and map the (possibly persistent, gloablly unique, and ridiculously long) VMID to the pid. It might be preferable to have something that is persistent over guest migration. Makes life easier for the management application as far as I see. It may make sense to add a vmid to qemu (or to keep it in the management application entirely). Certainly the kernel doesn't need to know about it. I take it back. The only entity that can enforce uniqueness is the management application, therefore that should be the entity that knows about them. When managing QEMU KVM guests, libvirt provides 3 identifiers with varying levels of uniqueness - ID - a integer unique amongst all active guests on a host - Name - a string uninque amongst all active inactive guests on a host - UUID - 32 byte hex string unique globally We don't expose the PID directly of the QEMU binary directly. Name and UUID are both stable across migration - the ID changes upon migration. As Avi says I dont't see how a individual QEMU process could provide any meaningful identifier itself aside from its PID whose uniqueness is guarenteed by the OS on its behalf. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] VM id in KVM?
On Mon, Jul 23, 2007 at 04:39:33PM +0300, Avi Kivity wrote: Daniel P. Berrange wrote: When managing QEMU KVM guests, libvirt provides 3 identifiers with varying levels of uniqueness - ID - a integer unique amongst all active guests on a host - Name - a string uninque amongst all active inactive guests on a host - UUID - 32 byte hex string unique globally Does libvirt also provide a lighter-weight interface that doesn't know about names and uuids? I imagine a cluster-wide management solutions will want to keep all configuration in a central database and just tell libvirt start a guest with this configuration. Name is mandatory, if you omit the UUID it will generate one for its own internal tracking purposes. You can also create a guest without having to pre-define a config file - it will disappear with no trace once the guest is shutdown. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC][PATCH 00/01]qemu VM entrypoints
On Fri, Jul 20, 2007 at 03:32:16PM -0400, David Windsor wrote:
Hi,
After a bit more discussion about integrating SELinux and KVM, it seems that
there is little interest in adding enforcement hooks to KVM as it stands.
Once KVM gets some type of inter-vm communication mechanism, MAC hooks will
probably be added in that space.
Until then, there seems to be interest in adding MAC controls to control VM
management operations, such as migrating VMs, or saving/resuming VMs.
One particular aspect of VM management which may be nice to control via
SELinux is the loading of a virtual hard disk into a VM. Currently,
administrators would have to rely on file permissions to control which files
could be used as a virtual hard disks. The semantics of file permissions do
not accomplish what is needed here. A domain needs to explicitly get
permission from the policy to both use a file as a virtual disk and to use
the contents of that virtual disk as an entrypoint to the new, virtual
machine of a different integrity level.
Since there is no SELinux permission for this, I have created the vm {
entrypoint } object class/permission pair to represent this type of access.
Policy for allowing domain user_t to load a virtual disk of type
qemu_virtdisk_t would look something like:
allow user_t qemu_virtdisk_t:file r_file_perms;
type_change user_t qemu_virtdisk_t:vm vm_user_t;
allow qemu_virtdisk_t user_vm_t:vm entrypoint;
Please note that this patch will only check the entrypoint permission, and
does not actually facilitate transitioning on the type of the virtual disk.
I want some comments before continuing with this approach.
When loading a virtual disk into a VM, qemu would consult the policy to see
essentially three things: if the current process is allowed to read the
virtual disk file, what the type of the VM should be after loading the disk,
and if the virtual disk is in fact allowed to serve as an entrypoint to the
target domain.
One problem with this approach is that loading a VM is not an exec-based
operation. Dynamic transitions could be used, but could possibly be avoided
by altering the patch to fork, then re-exec in the target domain.
It could be - if your put the policy at the control API layer instead of
in QEMU itself. One of the roadmap items for the libvirt API is fine grained
MAC on all virtual machine control APIs it exposes. SELinux is the most
likely technology we've thought about using for this task. libvirt itself
exec's the QEMU or KVM binary, so it may be possible to do a transition at
that point.
Regards,
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC][PATCH 00/01]qemu VM entrypoints
On Fri, Jul 20, 2007 at 04:30:22PM -0400, James Morris wrote: On Fri, 20 Jul 2007, Daniel P. Berrange wrote: It could be - if your put the policy at the control API layer instead of in QEMU itself. Then you can bypass MAC security by invoking qemu directly. Isn't that upto the policy - if its a targetted policy, then this is true of most apps where the local users can bypass MAC, since they're all in unconfined domains. I would have thought strict policy would prevent direct execution of qemu though ? Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC][PATCH 00/01]qemu VM entrypoints
On Fri, Jul 20, 2007 at 05:57:29PM -0400, David Windsor wrote: On 7/20/07, James Morris [EMAIL PROTECTED] wrote: On Fri, 20 Jul 2007, Daniel P. Berrange wrote: It could be - if your put the policy at the control API layer instead of in QEMU itself. I think that libvirt may be a bit too high in the virtualization stack for this control. What benefits are there for placing such a hook in libvirt vs qemu? libvirt could still use the vm:entrypoint permission for other types of VMs it manages. It is quite possible that we need policy at several layers of the virt stack. It also could be that we're thinking about different aspects of the access control for VMs. So here's a little background on what I've considered so far in the context of libvirt in particular how it deals with QEMU... Currently there are two ways to access libvirt. A local user may use the library directly. A remote user may use the library indirectly via the libvirt daemon. The libvirt daemon allows connections either via combination of an SSH tunnel to its UNIX domain socket, or a SSL/TLS encrypted channel. In the local, or SSH case permissions are coarse - root has full read-write, non-root has readonly. Potentially we could use peer credentials on unix domain sockets to do more per-user permissioning. In the TLS case, we each client user is identified based on their client SSL cert. We'd like to be able to have fine grained MAC, so one could allow rules like - client 'a' can start/stop guest 'X' - client 'b' can monitor stats of guest 'Y' - client 'c' can define new guests / delete existing guests We've not really investigated the SELinux side in much detail yet, but my current thoughts are based on knowledge of the way DBus integrates with SELinux to do MAC on its clients their API calls. In the local user case, obviously the UNIX user has a corresponding SELinux domain. In the remote case, one could map x509 certificate IDs (the remote user's identify) to appropriate local SELinux domains. The libvirt daemon/driver would need calls out to the SELinux APIs for any of the ACL checks it needs internally. Policy would ensure than when libvirtd started any VMs (ie qemu processes), the appropriate domain transition would take place on exec. Once QEMU is running in appropriate domain, policy would take care of ensuring it only accessed appropriate disks network interfaces defined by the config. The appealing thing to me about trying to get some form of policy at the libvirt layer is that to the outside (ie end users) it could provide a consistent policy for all the different virt platforms supported by libvirt. Of course the underlying policy for each virt platform is likely radically different - qemu we deal with directly, Xen we talk to Xend hypervisor, OpenVZ we run openvz command line tools. libvirt is all about providing a consistent management API for all virtualization platforms. Being able to provide a consistent MAC model alongside that is really desirable to me and as I see SELinux expand to apps like DBus, PostgreSQL it seems a no-brainer to also apply it to libvirt (for Linux platforms). Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] accessing USB disk-on-key from windows (under KVM)
On Wed, Jul 18, 2007 at 10:32:06PM +0300, Ian Brown wrote: Hello, Thanks, Anthony. I tried both #2 and #3. It does not say any error, but still I cannot access the USB disk on key. Maybe I miss something ? Here are few more details. When I ran: /usr/local/kvm/bin/qemu-system-x86_64 -usbdevice disk:/dev/sdb /work/kvm/win2003/vdisk.img -m 384 OR /usr/local/kvm/bin/qemu-system-x86_64 -hdb /dev/sdb /work/kvm/win2003/vdisk.img -m 384 windows started ok (it did not emit errors, as I said). But I expected that clicking on my computer (or right clicking and opening file explorer) will show me the USB storage disk, and it did not. (I can see there only the hard disk and the CD). IIRC you need to also give the '-usb' arg to actually turn on USB bus emulation, then the -usbdevice args will be used. Regards, Dan, -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm+virtmanager can't save machine state?
On Fri, Jun 29, 2007 at 04:05:22PM +0800, youhongyu wrote: hi all, i use: fc7, built in xen, kvm. i boot my machine into normal kernal and install a guest os by vir-manager, and i encounter a strange situation the save command from virtual- manager menu failed! it pop out a small windows seem want to tell me something, but it quickly disappeared. what's thing happens? The window shouldn't have disappeared like that - it should have told you that this isn't supported We can't support save/restore of KVM guests in virt-manager at this time. QEMU 0.9.0 was really very unhelpful and removed the ability specify a filename for saving VM state, assuming that everyone happens to be using a qcow file :-( Not much use if you are using raw files, or physical volumes, or LVM which are the primary storage types used in virt-manager currently. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH/RFC 7/9] Virtual network guest device driver
On Wed, May 16, 2007 at 12:28:00PM -0500, Anthony Liguori wrote: Eric Van Hensbergen wrote: On 5/11/07, Anthony Liguori [EMAIL PROTECTED] wrote: There's definitely a conversation to have here. There are going to be a lot of small devices that would benefit from a common transport mechanism. Someone mentioned a PV entropy device on LKML. A host=guest filesystem is another consumer of such an interface. I'm inclined to think though that the abstraction point should be the transport and not the actual protocol. My concern with standardizing on a protocol like 9p would be that one would lose some potential optimizations (like passing PFN's directly between guest and host). I think that there are two layers - having a standard, well defined, simple shared memory transport between partitions (or between emulators and the host system) is certainly a prerequisite. There are lots of different decisions to made here: What do you think about a socket interface? I'm not sure how discovery would work yet, but there are a few PV socket implementations for Xen at the moment. As a userspace apps service, I'd very much like to see a common sockets interface for inter-VM communication that is portable across virt systems like Xen KVM. I'd see it as similar to UNIX domain sockets in style. So basically any app which could do UNIX domain sockets, could be ported to inter-VM sockets by just changing PF_UNIX to say, PF_VIRT Lots of interesting details around impl security (what VMs are allowed to talk to each other, whether this policy should be controlled by the host, or allow VMs to decide for themselves). a) does it communicate with userspace, kernelspace, or both? sockets are usable for both userspace/kernespace. For userspace, it would be very easy to adapt existing sockets based apps using IP or UNIX sockets to use inter-VM sockets, which is a big positive. d) can all of these parameters be something controllable from userspace? e) I'm sure there are many others that I can't be bothered to think of on a Friday The biggest point of contention would probably be what goes in the sockaddr structure. Keeping it very simple would be some arbitrary 'path', similar to UNIX domain sockets in the abstract namespace ? Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Fwd: Re: KVM management and API
On Mon, Apr 30, 2007 at 07:01:55PM -0700, jd wrote: Does libvirt use ps -ef | grep qemu to find out qemu processes ? Or it manages only ones that are started using libvirt. Using some naming scheme. We only manage instances started by libvirt. We (briefly) considered 'ps ef' but this is not at all scalable, since getting a list of active domains is quite a frequently invoked operation. In latest CVS of QEMU there is a new option '-daemonize' and '-name string' which will make it leave a UNIX domain socket pid file in a predictable location, but since that's not in any release yet, we can't rely on it. There is also the issue of manage configs of instances which aren't running hence have no process. How do you know if a running process is using kvm kernel module or not ? Since libvirt only manages instances it invokes, it knows whether we launched the KVM version. Ideally a monitor command would be able to tell us what accelerator is in use. libvirt seems to be connecting to qemu console through qemud ? right ? You have done quite a bit of work to send command and parse. !! Isnt this error prone ? (will code for parsing work in different char set ? or qemu console is always guarenteed to be in english ?) The console is always in English even if it were translated in the future, we can control the environment the process is launched it to force it to be in the C/POSIX locale. Anthony Liguori has done some work in recent times to make some of the monitor commands easier / more predictable to parse, so I'm not really worried about it currently. The qemu monitor is really the recommended (and only) interface for management apps which need to control aspects of QEMU's operation on-the-fly. We use it for pause/resume, save/restore at this time. I expect we'll make further use of it in the future, for example to set the VNC password securely (passsing passwds on the command line or via environment vars is not good). How do you find out what % of allocated memory is actually used by VM ? Any app on the host can only ever tell how much memory was allocated to a VM. To determine whether an OS is actually using all of this allocation requires some form of agent in the guest OS to report back on info. For cpu /proc seems to be used.. which seems fine, but will not work for QEMU on Windows. Indeed not - it won't even work on non-Linux systems. There isn't any form of standard API in POSIX world for getting process CPU usage, so we're expecting to have to implement this for each OS ported to. The code is well isolated so porting it won't be hard. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] KVM management and API
On Fri, Apr 27, 2007 at 02:29:52PM -0700, jd wrote: Hi This is a great project with a lots and lots of potential. I have a bunch of questions related to managing kvm VMs. I would like to know what kind of options are available for doing effective management ot KVM/QEMU processes (VMs). And know more abut plans / roadmap /directions to get to a proper API. (similar to Xen-API) We are supporting QEMU / KVM management in libvirt since version 0.3.0 aiming to have feature parity for our management APIs between Xen, QEMU and KVM. This gives a C, Python Perl API. A command line tool virsh. And a couple of higher level tools virt-install virt-manager. I'll illustrate possible answers to your questions in terms of virsh... 1. Discovery : How does one find all processes running KVM vms ? ps -ef | grep qemu ? libvirt doesn't expose the PIDs to app developers, but you can get a list using # export VIRSH_DEFAULT_CONNECT_URI=qemu:///system # virsh list --all Id Name State -- 1 QEMUGuest1 running - wizz shut off How does one know if qemu is using the kvm or not ? # virsh dumpxml QEMUGuest1 | grep domain domain type='qemu' id='1' The 'type' attribute will be one of qemu, kqemu, kvm 2. Identity : I am assuming that each VM is a process and pid would be an identifier, is there any other more unique identifier available. libvirt provides 3 identifiers with different levels of uniqueness 1. 'id' - integer uniquely identifying amongst active guests on a host 2. 'name' - string uniquely identifying amongst active inactive guests on a host 3. 'uuid' - hex string uniquely identifying globally 3. Managing running processs : a. How does one connect to the manage the running vms ? I have read about screen and socat options. Both of these act as tty client, where success/failure and errors for a given command are very vague (parsing..). (A way to get return code for the operation would be great). Parsing ... command response and interpreting... is error prone. Say I choose socat, how do I gracefully detach from the console. ( other than just killing socat) virsh provides a set of commands for controlling lifecycle configuration of the guest from the host machine, eg shutdown, start, pause, resume, suspend, restore, dominfo, dumpxml, etc, etc The graphical console is typically exposed with VNC / SDL. You can find the VNC port with: # virsh vncdisplay QEMUGuest1 :0 If you configured a serial port setup the guest to start a getty on it you can also connect via the 'serial console' # virsh console QEMUGuest1 b. How does one get the stats for the running VM ? 1. status : running, stopped, *migrating*..? 2. Current use of the memory : example allocated 1 GB, used 512 MB. 3. CPU : Effective cpu used ? Are vcpus supported ? /proc can be used... what about windows ? (when and if we have kvm on windows) 4. How much I/O and Network I/O 5. Wait times to get to I/O or CPU. (contention measures) Can do the first 3 options # virsh dominfo QEMUGuest1 Id: 1 Name: QEMUGuest1 UUID: c7a5fdbd-edaf-9455-926a-d65c16db1809 OS Type:hvm State: running CPU(s): 1 CPU time: 98.8s Max memory: 219200 kB Used memory:219200 kB We don't currently have APIs to show disk network I/O stats. We also don't yet provide migration support. 6. What is kvm_stats ? How to interpret its output? No idea :-) c. Can one change memory, cpus, disks and networks on the fly for a running VM ? If so how ? This is critical for achiving dynamic resource management. Not AFAIK. To be precise, libvirt provides APIs for that, but it requires better guest support / paravirt device drivers. Also QEMU can do hot-add/remove of USB devices. 4. Shutdown : How does one send command to VM to shutdown normally. I see only reset and powerdown commands only. Also, after shutdown, the image running in the machine shuts down, but the VM keeps running. Shouldnt the process also die ? A controlled shutdown isn't provided by QEMU/KVM yet. One would need to simulate some kind of ACPI power management support in the guest so it saw a virtual software power button press i guess. 5. Snapshots : where are snapshots saved ? I tried savevm with /tmp/x, I was expecting a file containing memory image... do these work differrently ? Also, when one does loadvm, is the snapshot gone ? I mean can one restore the same snapshot multiple times ? libvirt has APIs for snapshotting, but we've not implement them for QEMU or KVM yet. You can save the file to any location you have write permissions for. Its not a plain memory image because it also contains info about the state of all the various virtual devices.
Re: [kvm-devel] QEMU / KVM support in libvirt virt-manager
On Sun, Feb 25, 2007 at 07:32:58AM +0200, Avi Kivity wrote: Daniel P. Berrange wrote: FYI, as of libvirt 0.2.0 and virt-manager 0.3.1 there is now (experimental!) support for managing virtual machines running under QEMU or KVM virtualization platforms, as well as the existing Xen support. Great; as I see it hit FC6-updates I'll give it a shot. One thing I saw is that it pulls in Xen as part of the dependencies; perhaps a libvirt-xen and libvirt-kvm subpackage split is called for? Yeah, we've not figured out exactly how to address that dependancy issue yet - the libvirt.so has to link to libxenstore as part of the Xen driver, so even if you only want to manage QEMU instances we still end up pulling in Xen. We're certainly going to make it possible to turn off the Xen stuff at compile time. Not clear how we'd address the RPM dep issue though because the Fedora builds of libvirt will include both Xen QEMU support. Perhaps we'll have to try a dlopen() approach. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] QEMU / KVM support in libvirt virt-manager
On Sun, Feb 25, 2007 at 10:34:15AM +0200, Avi Kivity wrote: Avi Kivity wrote: Daniel P. Berrange wrote: FYI, as of libvirt 0.2.0 and virt-manager 0.3.1 there is now (experimental!) support for managing virtual machines running under QEMU or KVM virtualization platforms, as well as the existing Xen support. Great; as I see it hit FC6-updates I'll give it a shot. How is one supposed to use it? I tried entering 'qemu://' and 'kvm://' in the 'other hypervisor' thingy, but that didn't work. The virt-manager in Fedora Core 6 hasn't been updated to the newest 0.3.1 release yet - only the underling libvirt has been pushed to FC6 thus far. What follows is an example illustrating use of the low level 'virsh' command. First we create an XML file describing the VM we want to create, then create a file to serve as a disk image. Then we start virsh connecting to the QEMU hypervisor, define the domain, start it and dump the runtime info XML. Finally it connects to the VNC port to access the console $ cat newvm.xml EOF domain type='qemu' nameFedora/name uuidc7a5fdbdcdaf9455926ad65c16db1809/uuid os typehvm/type boot dev='cdrom'/ /os memory219200/memory vcpu2/vcpu devices disk type='file' device='disk' source file='/home/berrange/fedora.img'/ target dev='hda'/ /disk disk type='file' device='cdrom' source file='/home/berrange/boot.iso'/ target dev='hdc'/ /disk interface type='user' mac address='00:16:3e:62:a5:08'/ /interface graphics type='vnc' port='5900'/ /devices /domain EOF $ dd if=/dev/zero of=/home/berrange/fedora.img bs=1M seek=5000 count=0 $ virsh --connect qemu:///session Welcome to virsh, the virtualization interactive terminal. Type: 'help' for help with commands 'quit' to quit virsh define /home/berrange/qemu.xml Domain Fedora defined from /home/berrange/qemu.xml virsh list --all Id Name State -- - Fedora shut off virsh start Fedora Domain Fedora started virsh list Id Name State -- 4 Fedora running virsh dominfo Fedora Id: 4 Name: Fedora UUID: c7a5fdbd-cdaf-9455-926a-d65c16db1809 State: running CPU(s): 2 CPU time: 0.0s Max memory: 219200 kB Used memory:219200 kB virsh dumpxml Fedora domain type='qemu' id='4' nameFedora/name uuidc7a5fdbd-cdaf-9455-926a-d65c16db1809/uuid memory219200/memory currentMemory219200/currentMemory vcpu2/vcpu os type arch='i686' machine='pc'hvm/type boot dev='cdrom'/ /os devices emulator/usr/bin/qemu/emulator disk type='file' device='cdrom' source file='/home/berrange/boot.iso'/ target dev='hdc'/ readonly/ /disk disk type='file' device='disk' source file='/home/berrange/fedora.img'/ target dev='hda'/ /disk interface type='user' /interface graphics type='vnc' port='5900'/ /devices /domain virsh quit $ vncviewer :0 VNC Viewer Free Edition 4.1.2 for X - built ... The above illustrates creating a QEMU domain. The use of KVM is completely identical - still use qemu:///session as the hypervisor URL. The change is in the XML file describing the guest VM - in the top level 'domain' attribute use type='kvm' instead of type='qemu'. You can also use type='kqemu' if desired. NB you can create 'qemu' guests as an user, but if you want to create kvm/kqemu guests you must either be root, or chown the device nod.e Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] QEMU / KVM support in libvirt virt-manager
FYI, as of libvirt 0.2.0 and virt-manager 0.3.1 there is now (experimental!) support for managing virtual machines running under QEMU or KVM virtualization platforms, as well as the existing Xen support. Project sites: http://libvirt.org/ http://virt-manager.org/ Release announcements here: http://www.redhat.com/archives/libvir-list/2007-February/msg00033.html http://www.redhat.com/archives/et-mgmt-tools/2007-February/msg00121.html A little background info, since we've not updated any docs yet... (yes we suck, will do better with docs soon) The QEMU driver provides a spawn-on-demand daemon which manages all the QEMU instances, their monitor consoles, and config files for offline guest VMs. The KVM support is implemented as part of the generic QEMU driver in libvirt, and can be activated by setting the domain type to 'kvm' in the XML description of a guest being created. As an example description of a KVM guest with QEMUs slirp based user networking, a single harddisk and VNC graphics console, the XML would look like: domain type='kvm' namedemo/name uuidc7a5fdb0-3daf-9455-926a-d65c16db1809/uuid memory403456/memory currentMemory403456/currentMemory vcpu1/vcpu os type arch='i686' machine='pc'hvm/type boot dev='hd'/ /os devices emulator/usr/bin/qemu/emulator disk type='file' device='disk' source file='/home/berrange/q.img'/ target dev='hda'/ /disk interface type='user' /interface graphics type='vnc' port='-1'/ /devices /domain The 'virsh' tool can be used to interact with libvirt QEMU/KVM from the shell by specifying an explicit hypervisor URI. eg to list machines: virsh --connect qemu://session list The 'virt-install' tool has also been adapted to support provisioning of QEMU / KVM guests, for example: virt-install \ --connect qemu://session \ --name demo \ --ram 400 \ --file /home/berrange/q.img \ --cdrom /home/berrange/fedora-core-6-boot-x86_64.iso \ --accelerate \ --vnc \ --vncport 5905 Finally, 'virt-manager' has been adapted to support all its usual management capabilities for QEMU / KVM guests. Simply select 'QEMU' as the hypevisor type when it puts up the initial 'open connection' dialog. NB. These are the very first prototype releases to support QEM KVM and we know of many bugs[1] / limitations. We expect to have updated releases over the coming weeks/months which will make it much more robust / generally useful to regular users Regards, Dan. [1] The spawn-on-demand bit is broken, so requires /usr/libexec/libvirt_qemud to be run manually. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [ANNOUNCE] kvm-14 release
On Mon, Feb 19, 2007 at 01:01:36PM +0200, Avi Kivity wrote: The big news here is the update to qemu 0.9.0. Changes from kvm-13: - qemu 0.9.0 - too many goodies to list - kvm can no longer share qemu's bios on Intel hosts due to real mode trouble. use the supplied bios. - migration now based on Anthony Liguori's live migration patches (Uri Lublin) - currently, only non-live migration is supported under kvm - handle smi on host on AMD hosts (Joerg Roedel) - random fixes Note that if you use the modules from Linux 2.6.20, you need to use kvm-12. You can use kvm-14 with Linux 2.6.20, provided you use the external module included in kvm-14. Is there back-compatability in the reverse direction ? ie, will the new kmod from kvm-14 work with the older kvm-12 userspace ? Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] qemu vnc auth
On Tue, Jan 30, 2007 at 01:03:20PM +0100, Yellis Services wrote: Hello, I have adapted a xen path to kvm-qemu. This patch enable auth in vnc qemu ../.. -hda=/home/os.img -vnc -vncpasswd toto work with vncviewer on linux and Win. Don't work with vncviewer applet via http, must be fixed. Passing passwords around on the command line is not really a viable implementation because they can trivially be snooped by any user on the system. Likewise environment variables are not suitable. I suggest two approaches: 1. Pass the name of a file containing the password on the command line. QEMU can then read the password from this file. This is the approach taken by the regular VNC server - eg it stores a passwd in $HOME/.vnc/passwd. This passwd file can be chmod 0600 to secure it from other userseg. This is useful for a user who is laucnhing qemu process mannually and wants to make them all use a single passwd. qemu ../.. -hda=/home/os.img -vnc -vncpasswdfile /path/to/file 2. Allow the password to be passed to the QEMU process via a file descriptor. This is useful if the QEMU process is being launched by some form of management process, letting the parent process easily control the password per-QEMU process without writing out a great many files. qemu ../.. -hda=/home/os.img -vnc -vncpasswdfd 7 So in fact I think it would be very useful to implement both approaches, because they serve different use cases and I don't think there would be too much code overhead in having both supported. Aside from how you supply the initial password, the rest of the patch looks good to me. It would probably be worthwhile posting this to upstream qemu-devel too, to avoid the need for further KVM-specific fork of the codebae. Regards, Dan -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
