FWN/Beats/Virtualization

Virtualization

In this section, we cover discussion on the @et-mgmnt-tools-list, @fedora-xen-list, @libvirt-list and @ovirt-devel-list of Fedora virtualization technologies.

Contributing Writer: Dale Bewley

Enterprise Management Tools List

This section contains the discussion happening on the et-mgmt-tools list

New Release virt-manager 0.7.0

Cole Robinson announce^[1] a new virt-manager^[2] release, version 0.7.0.

Virtual Machine Manager provides a graphical tool for administering virtual machines for KVM, Xen, and QEmu. Start, stop, add or remove virtual devices, connect to a graphical or serial console, and see resource usage statistics for existing VMs on local or remote machines. Uses libvirt as the backend management API.

New features:

Redesigned 'New Virtual Machine' wizard (Jeremy Perry, Tim Allen, Cole Robinson)
Option to remove storage when deleting a virtual machine.
File browser for libvirt storage pools and volumes, for use when attaching storage to a new or existing guest.
Physical device assignment (PCI, USB) for existing virtual machines.
Bug fixes and minor improvements.

New Release virtinst 0.4.3

Cole Robinson announce^[1] a new python-virtinst release, version 0.400.3.

virtinst is a module that helps build and install libvirt based virtual machines. It currently supports KVM, QEmu and Xen virtual machines. Package includes several command line utilities, including virt-install (build and install new VMs) and virt-clone (clone an existing virtual machine).

This is largely a bug fix release.

↑ http://www.redhat.com/archives/et-mgmt-tools/2009-March/msg00057.html

Fedora Virtualization List

This section contains the discussion happening on the fedora-virt list.

Serial Console Support in virt-manager

Jan ONDREJ tested^[1] the new virt-manager 0.7.0 on Fedora 10, and had some suggestions.

TODO

Starting an domain starts my serial console owned by root and is not
accesssible from virt-manager (virt-viewer). After changing ownership it's
immediatelly available. Is it possible to change this in time of virtual
machine creation? (in libvirt or where?)

  Another feature enhacement can be adding "Serial 0" tab automatically,
when there is no Console available for guest. Message "Console not
configured for guest" can be sometimes misinterpretated, because I can have
serial console for my guest. I prefer to use serial consoles, because they
do not need to install graphical environment on host. They have multiple
advantages, like access from another machine using serial or ipmi console,
viewing crash status, when host crashes, ...

  And last possible enhancement: when pressing F10 key in guest's serial
console, is it possible to avoid opening of "File menu" and send this key to
serial 0, as it is done in VGA console?

Cole ^[2]

Yes, this is one of the drawbacks of not running virt-manager as root:
since the qemu:///system libvirt connection will launch your guests as
root, a regular user won't be able to access ptys.

I don't know of a proper solution to it all, other then running the app
as root or changing the the pty permissions as you did.

>   Another feature enhacement can be adding "Serial 0" tab automatically,
> when there is no Console available for guest. Message "Console not
> configured for guest" can be sometimes misinterpretated, because I can have
> serial console for my guest. 

I see what you mean. The wording could certainly be better, and It would
make sense to try to connect to the serial console if no graphics device
is attached. Thanks for the idea.

> 
>   And last possible enhancement: when pressing F10 key in guest's serial
> console, is it possible to avoid opening of "File menu" and send this key to
> serial 0, as it is done in VGA console?
> 

We would probably need some sort of keygrab process like we do for VNC
to get this right. Not sure if that's even an option for the VTE widget
though.

Fedora Xen List

This section contains the discussion happening on the fedora-xen list.

dom0 Kernel: Better, Still Not Ready

Itamar Reis Peixoto reported^[1] success with Michael Young's latest kernel build^[2] and wondered when it could be released.

Michael explained, "The current plan is to wait until basic dom0 support makes it into the vanilla kernel, which should happen for 2.6.30, and then decide if dom0 can be enabled and if the patches for full dom0 support can safely be added without affecting ordinary operation."

"At the moment there are still things that are broken such as X support in some cases, and there are also Fedora patches that have been omitted because they were tricky to merge, so it is too early to start adding dom0 support to official Fedora kernels."

Missing Hypervisor Capabilities Restored

There was progress on a bug discovered^[1] last week. This missing file /sys/hypervisor/properties/capabilities has been restored^[2], however a bug^[3] remained^[4] in libvirt or virt-install.

Libvirt List

This section contains the discussion happening on the libvir-list.

Snapshot Support

Template:Note/admon Matt McCowan http://www.redhat.com/archives/libvir-list/2009-March/msg00177.html

"Another run at producing a function that helps the likes of me
backup my kvm Windows servers.
'virsh checkpoint domain file [script]' is what the following patch set
(against cvs) enables. Modelled on the virDomainSave function it takes
an optional script which it will execute (and pass the name of the
domain as an argument) while the domain is paused, then resume the
domain.
"

Daniel Veillard http://www.redhat.com/archives/libvir-list/2009-March/msg00199.html

"I think this can help administrators in a controlled situation,
but I'm hoping a real snapshotting API will be possible at some point
where libvirt goes though the list of storage resources used by the
domain and properly make a snapshot using a storage API or return
an error if that's not possible."

"I really hope we will have one day a real checkpointing
API in libvirt, but that requires making more progresses on the storage
management side."

Daniel P. Berrange http://www.redhat.com/archives/libvir-list/2009-March/msg00205.html

"In terms of API I think I'd like to see snapshotting available as part
of a more generic save/restore API. I tend to think of the current API
as providing 'unmanaged save/restore', in so much as libvirt / users
of libvirt have no way of knowing whether there is a saved image for 
the guest available currently.  As an example of why this is a problem,
consider the often requested ability to save/restore guests across
host reboot.

When libvirtd starts, it looks at the autostart flag for a guest, and
decides may thus automatically boot the guest at that time. libvirtd
has no way of knowing whether there was an existing saved image of the
guest available to restore, since it doesn't track saved images.

Thus I think the first step towards a general snapshot facility would
be to provide an API for 'managed save/restore' where we explicitly
track saved images.


- To save a guest:

    enum {
       VIR_DOMAIN_SAVE_LIVE, /* Don't shutdown guest after saving */
    } virDomainSaveFlags;

    virDomainCreateSaveImage(virDomainPtr dom,
                             const char *imagename,
                             unsigned int flags);

  By default, imagename would be NULL, and flags would be zero. In this
  case we'd simply be saving to

      /var/lib/libvirt/saved/qemu/$VMNAME.img

  Providing equivalence to current virDomainSave(dom, filename), but
  with libvirt deciding the actual filename used.

  Now to do snapshots in this scenario, you'd pass a 'imagename' for
  the snapshot - give each snapshot you take some meaningful name as
  you desire. And if VIR_DOMAIN_SAVE_LIVE is set then the guest will
  be allowed to continue running after the snapshot is saved.
 
  Obviously this capability would require some way to take a snapshot
  of the storage, as well as the memory image. We could allow a script
  to do this, or implement it directly for a handful of storage types
  we know can do this (eg, LVM, qcow2).

 - Next, we'd need a way to list saved images
       
        virDomainListSaveImages(virDomainPtr dom,
                                const char **imagenames,
                                unsigned int *numimagenames);

   This would just give back a list of all known imagenames for
   the VM.

 - Then a way to restore from an image

        enum {
           VIR_DOMAIN_RESTORE_DELETE
        } virDomainRestoreFlags;

        virDomainRestoreSaveImage(virDomainPtr dom,
                                  const char *imagename,
                                  unsigned int flags);

    This would restore from the named image. If the VIR_DOMAIN_RESTORE_DELETE
    flag was given, the named image would be deleted after restore (eg to 
    prevent accidental duplicated restore attempts)

 - Perhaps also need a way to delete saved imaged


         virDomainDeleteSaveImage(virDomainPtr dom,
                                  const char *imagename);

  If VIR_DOMAIN_SAVE_LIVE is set, the guest won't be shutdown after
  saving its state. 


 - Perhaps also need a wa yto get more metaata about the save image

           struct virDomainSaveImageInfo {
                 int savedDate;
                 unsigned long long imageSize;
           };
           virDomainGetSaveImgeInfo(virDomainptr dom,
                                    const char *imagename,
                                    virDomainSaveImageInfoPtr info);

   Then again, perhaps the virDomainListSaveImages should just return
   a list of virDomainSaveImageInfoPtr instances directly, instead of
   requiring this extra API call - it'd be faster for remote usage
   in particular because it'd have less round-trips.

With this, you could configure libvirtd, so that when starting up, it
used virDomainListSaveImages to see if the guest was suspended before
the previous host shutdown, and if so, then restore from that saved
image automatically. Or make it skip autostart completely, if any save
images exist, and allow an admin defined initscript to do auto restore
from the save image.
"

Search

Contents