Re: [et-mgmt-tools] Re: [libvirt] RE: [Qemu-devel] [ANNOUNCE] virt-mem tools version 0.2.8 released
On 12/08/2008, at 10:30 PM, Daniel P. Berrange wrote: Oh, that means the version of libvirt you are using is too old - it predates us adding support for the -drive argument, which is required in order to use SCSI disks. THis was added in libvirt 0.4.3 Regards, Daniel Ah - the penny drops. :-) I'm running Ubuntu 8.04 which seems to be using libvirt 0.4.0. I'm not really fussed about doing source build/installs so looks like I will have to wait until Intrepid is out which has libvirt 0.4.4 as part of it. Thanks heaps for clearing that up for me, much appreciated. --James. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [et-mgmt-tools] Re: [libvirt] RE: [Qemu-devel] [ANNOUNCE] virt-mem tools version 0.2.8 released
On Tue, Aug 12, 2008 at 10:25:34PM +1200, james wrote:
>
> On 11/08/2008, at 8:42 PM, Daniel P. Berrange wrote:
> >Configuring SCSI disks with VMs in libvirt is no different to
> >configuring
> >any other kind of block based storage. The general description is
> >here:
> >
> > http://libvirt.org/formatdomain.html#elementsDisks
> >
> >Specifically though you'd want a disk section looking like
> >
> >
> >
> >
> >
> >
> >NB, there is no restriction on mapping to the target bus -ie a SCSI
> >disk in
> >the host can be mapped to a IDE disk in the guest, and vica-verca.
> >Also
> >note that the 'dev' attribute on the target isn't a guarenteed
> >device name
> >in the guest - it is merely used for ordering of devices when
> >spawning QEMU.
> >
> >Now, the main fun you'll have is actually outside of libvirt -
> >namely that
> >on Linux SCSI disk names are not guarenteed stable across reboots. So
> >rather than using /dev/sdf1 you may want to consider one of the udev
> >created
> >stable paths under the directories /dev/disk/by-{id,path,uuid}, or
> >if you are
> >using a multipath enabled SAN, then a name under /dev/multipath/
> >
> >Regards,
> >Daniel
>
> To be clear I have not tried to use block devices but 5 image files as
> I am experimenting. I have tried to create VMs using raw image files
> under libvirt via the nice Virtual Machine Manager 0.5.3 and through
> hand crafted xml files. Neither method will register the images as
> scsi disks, it fails with an error. Getting the same disk images to be
> regarded as scsi disks via the kvm command line is fine or if I fall
> back to ide and limit. The ide test proves that the rest of the xml
> file is correct.
>
> Trying to define a domain using virsh using a disk section defined as:
>
>
>
>
>
>
> fails with this error:
> libvir: QEMU error : Invalid harddisk device name: sda
Oh, that means the version of libvirt you are using is too old - it
predates us adding support for the -drive argument, which is required
in order to use SCSI disks. THis was added in libvirt 0.4.3
Regards,
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [et-mgmt-tools] Re: [libvirt] RE: [Qemu-devel] [ANNOUNCE] virt-mem tools version 0.2.8 released
On 11/08/2008, at 8:42 PM, Daniel P. Berrange wrote:
On Mon, Aug 11, 2008 at 09:18:19AM +0100, Richard W.M. Jones wrote:
On Mon, Aug 11, 2008 at 07:39:34PM +1200, james wrote:
This is what libvirt gives you (and lots more, eg. secure remote
access to hypervisors, bindings to Perl & many other languages,
etc.).
Can you be more specfic about what you couldn't do with libvirt?
I can give you such an example although I confess it could be due
to my
lack of understanding of the libvirt config. I have tried and
tried to
use libvirt to configure VMs within KVM using scsi disk images.
Usually
when tinkering/experimenting with RAID setups. It just will not
take it.
Starting a KVM based VM from the command line with the appropriate
settings and I have no problems. This inability to use scsi within
libvirt has been extremely frustrating until I took the plunge and
went
to to kvm command line.
However if you can point out an example xml config for a VM using
scsi
disk images that works then that would be very cool
Configuring SCSI disks with VMs in libvirt is no different to
configuring
any other kind of block based storage. The general description is
here:
http://libvirt.org/formatdomain.html#elementsDisks
Specifically though you'd want a disk section looking like
NB, there is no restriction on mapping to the target bus -ie a SCSI
disk in
the host can be mapped to a IDE disk in the guest, and vica-verca.
Also
note that the 'dev' attribute on the target isn't a guarenteed
device name
in the guest - it is merely used for ordering of devices when
spawning QEMU.
Now, the main fun you'll have is actually outside of libvirt -
namely that
on Linux SCSI disk names are not guarenteed stable across reboots. So
rather than using /dev/sdf1 you may want to consider one of the udev
created
stable paths under the directories /dev/disk/by-{id,path,uuid}, or
if you are
using a multipath enabled SAN, then a name under /dev/multipath/
Regards,
Daniel
To be clear I have not tried to use block devices but 5 image files as
I am experimenting. I have tried to create VMs using raw image files
under libvirt via the nice Virtual Machine Manager 0.5.3 and through
hand crafted xml files. Neither method will register the images as
scsi disks, it fails with an error. Getting the same disk images to be
regarded as scsi disks via the kvm command line is fine or if I fall
back to ide and limit. The ide test proves that the rest of the xml
file is correct.
Trying to define a domain using virsh using a disk section defined as:
fails with this error:
libvir: QEMU error : Invalid harddisk device name: sda
Heck if I have missed the wood for the trees and there is a simple
correction to this definition that will make it work I would be one
happy camper.
Cheers.
-- James.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [et-mgmt-tools] Re: [libvirt] RE: [Qemu-devel] [ANNOUNCE] virt-mem tools version 0.2.8 released
On Mon, Aug 11, 2008 at 09:18:19AM +0100, Richard W.M. Jones wrote:
> On Mon, Aug 11, 2008 at 07:39:34PM +1200, james wrote:
> >> This is what libvirt gives you (and lots more, eg. secure remote
> >> access to hypervisors, bindings to Perl & many other languages, etc.).
> >> Can you be more specfic about what you couldn't do with libvirt?
> >
> > I can give you such an example although I confess it could be due to my
> > lack of understanding of the libvirt config. I have tried and tried to
> > use libvirt to configure VMs within KVM using scsi disk images. Usually
> > when tinkering/experimenting with RAID setups. It just will not take it.
> > Starting a KVM based VM from the command line with the appropriate
> > settings and I have no problems. This inability to use scsi within
> > libvirt has been extremely frustrating until I took the plunge and went
> > to to kvm command line.
> >
> > However if you can point out an example xml config for a VM using scsi
> > disk images that works then that would be very cool
Configuring SCSI disks with VMs in libvirt is no different to configuring
any other kind of block based storage. The general description is here:
http://libvirt.org/formatdomain.html#elementsDisks
Specifically though you'd want a disk section looking like
NB, there is no restriction on mapping to the target bus -ie a SCSI disk in
the host can be mapped to a IDE disk in the guest, and vica-verca. Also
note that the 'dev' attribute on the target isn't a guarenteed device name
in the guest - it is merely used for ordering of devices when spawning QEMU.
Now, the main fun you'll have is actually outside of libvirt - namely that
on Linux SCSI disk names are not guarenteed stable across reboots. So
rather than using /dev/sdf1 you may want to consider one of the udev created
stable paths under the directories /dev/disk/by-{id,path,uuid}, or if you are
using a multipath enabled SAN, then a name under /dev/multipath/
Regards,
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [et-mgmt-tools] Re: [libvirt] RE: [Qemu-devel] [ANNOUNCE] virt-mem tools version 0.2.8 released
On Mon, Aug 11, 2008 at 07:39:34PM +1200, james wrote: >> This is what libvirt gives you (and lots more, eg. secure remote >> access to hypervisors, bindings to Perl & many other languages, etc.). >> Can you be more specfic about what you couldn't do with libvirt? > > I can give you such an example although I confess it could be due to my > lack of understanding of the libvirt config. I have tried and tried to > use libvirt to configure VMs within KVM using scsi disk images. Usually > when tinkering/experimenting with RAID setups. It just will not take it. > Starting a KVM based VM from the command line with the appropriate > settings and I have no problems. This inability to use scsi within > libvirt has been extremely frustrating until I took the plunge and went > to to kvm command line. > > However if you can point out an example xml config for a VM using scsi > disk images that works then that would be very cool Dan's probably the best one to help here, but our example configs are here: http://libvirt.org/formatstorage.html Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [et-mgmt-tools] Re: [libvirt] RE: [Qemu-devel] [ANNOUNCE] virt-mem tools version 0.2.8 released
On Sun, Aug 10, 2008 at 11:07:32AM +0100, Richard W.M. Jones wrote: > Libvirt deliberately doesn't expose the full > feature set of any one hypervisor which it supports, but instead > exposes common features. Judging by one private reply I got, I don't want this to be misinterpreted. Libvirt DOESN'T expose the minimum subset of all hypervisors (because that would be very small and useless). It exposes general virtualization features, even if those features only apply to one or two hypervisors. For example: migration - only works with Xen & KVM, but could be applicable to other hypervisors in the future when we support them and they support migration scheduler tuning - only for Xen, but generally applicable adding/dropping interfaces from live guests - a general feature supported by many but not all of the backends Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 60 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [et-mgmt-tools] Re: [libvirt] RE: [Qemu-devel] [ANNOUNCE] virt-mem tools version 0.2.8 released
On Sun, Aug 10, 2008 at 02:28:27AM +0100, Jamie Lokier wrote: > Javier Guerra wrote: > > On Thu, Aug 7, 2008 at 8:06 AM, Richard W.M. Jones <[EMAIL PROTECTED]> > > wrote: > > > I think the message here is, install libvirt & be happy :-) > > > > nice as this tool sounds, i would need far more than this to make me > > switch from a simple, easily scriptable command-line to a generic, > > 'lowest common', solution like libvirt. > > > > of course, i hope it keeps getting better. who knows? maybe in a year > > or so it would be comparable to the CLI. > > Regrettably I agree for the moment. > > I ended up writing a Perl management script for my KVM VMs because > libvirt was just too muddled and limited for my needs, and because the > config file format confused me, didn't handle everything I needed, and > I didn't find clear documentation on it. The configuration format is documented here: http://libvirt.org/formatdomain.html You can also print out the configuration from any existing guest using 'virsh dumpxml ' if you need examples. I'm intrigued by what your Perl management script needed that isn't exposed by libvirt. Libvirt deliberately doesn't expose the full feature set of any one hypervisor which it supports, but instead exposes common features. The reason for this is so that you can switch hypervisor technologies later on. Clearly, we all love KVM, but people have different needs from hypervisors and KVM won't fit all of them. For example, lightweight container-based approaches are better for some virtualization problems (particularly where you really need to run 100s or 1000s of guests on a single machine), and people will still be running Xen and VMWare for many years to come. [...] > What would be nicer is a VM management protocol build in to QEMU, KVM > and XEN, which is a bit like the monitor, but supports multiple client > connections and overlapping operations (where reasonable), and is a > bit more structured, so e.g. you can get the state of anything whose > state you can set, you can wait for events, etc. The somewhat > object-based config file work that's been discussed not long ago would > be a good thing to structure it around. This is what libvirt gives you (and lots more, eg. secure remote access to hypervisors, bindings to Perl & many other languages, etc.). Can you be more specfic about what you couldn't do with libvirt? Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [et-mgmt-tools] Re: [libvirt] RE: [Qemu-devel] [ANNOUNCE] virt-mem tools version 0.2.8 released
Javier Guerra wrote: > On Thu, Aug 7, 2008 at 8:06 AM, Richard W.M. Jones <[EMAIL PROTECTED]> wrote: > > I think the message here is, install libvirt & be happy :-) > > nice as this tool sounds, i would need far more than this to make me > switch from a simple, easily scriptable command-line to a generic, > 'lowest common', solution like libvirt. > > of course, i hope it keeps getting better. who knows? maybe in a year > or so it would be comparable to the CLI. Regrettably I agree for the moment. I ended up writing a Perl management script for my KVM VMs because libvirt was just too muddled and limited for my needs, and because the config file format confused me, didn't handle everything I needed, and I didn't find clear documentation on it. Also, I wanted to import existing guests from another VM, and libvirt's tools seemed strongly geared around creating new VMs to use with libvirt. So I had to write config files for it - see above. I like the idea of libvirt a lot and wish it well. My own Perl script was a nightmare to write even though it's not so long (synchronisation & monitor issues especially), so I respect what's done. It's a good goal. But I just found it too confusing to use in the ways I needed to use KVM, that I gave up on libvirt for now rather than spend the considerable time to get to grips with what it's doing, and it's config format. What would be nicer is a VM management protocol build in to QEMU, KVM and XEN, which is a bit like the monitor, but supports multiple client connections and overlapping operations (where reasonable), and is a bit more structured, so e.g. you can get the state of anything whose state you can set, you can wait for events, etc. The somewhat object-based config file work that's been discussed not long ago would be a good thing to structure it around. -- Jamie -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [et-mgmt-tools] Re: [libvirt] RE: [Qemu-devel] [ANNOUNCE] virt-mem tools version 0.2.8 released
On Thu, Aug 7, 2008 at 8:06 AM, Richard W.M. Jones <[EMAIL PROTECTED]> wrote: > I think the message here is, install libvirt & be happy :-) nice as this tool sounds, i would need far more than this to make me switch from a simple, easily scriptable command-line to a generic, 'lowest common', solution like libvirt. of course, i hope it keeps getting better. who knows? maybe in a year or so it would be comparable to the CLI. -- Javier -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [et-mgmt-tools] Re: [libvirt] RE: [Qemu-devel] [ANNOUNCE] virt-mem tools version 0.2.8 released
On Thu, Aug 07, 2008 at 11:47:39AM +0100, Daniel P. Berrange wrote: > On Thu, Aug 07, 2008 at 07:40:58PM +0900, Jun Koi wrote: > > One of the problem is that these tools work via libvirt, so on a VM is > > not managed by libvirt, these tools no longer work. > > That's not a problem - that's a reason to use libvirt :-) It allows the > same tools to work whether using Xen, QEMU, KVM or any other full machine > virtualization suported by libvirt, rather than being tied to one particular > hypervisor. Not to mention ability to run them remotely, with authentication > and encryption, etc We also support running the tools from memory images which you can capture using the QEMU "memsave" command (see the '-t' option). No libvirt required for that, _but_ to see any interesting stuff you'd need to capture the entire guest memory which could obviously be quite large. You could do 'virt-mem capture' which captures just the bits of memory that contain interesting data, and that reduces the amount of data you need to capture substantially. Unfortunately I broke 'virt-mem capture' in the latest release by accident, and in any case it requires libvirt to do the capturing. I think the message here is, install libvirt & be happy :-) Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
