[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [et-mgmt-tools] [PATCH] virtinst - virt-convert vmware output

John Levon wrote:
On Mon, Sep 29, 2008 at 03:28:04PM -0400, Joey Boggs wrote:

+import virtinst.ImageParser as ImageParser
+from virtinst.cli import fail

Surely this isn't right - this code is "library" code and shouldn't be
using fail() ? It should be re-raising the exception...
Not sure about this, all the other apps in virtinst use fail() now in exceptions even virt-convert, or am I misunderstanding something?

I just grepped and didn't see that. The only fail() usages are in
virtinst/cli.py. That's right and proper: library code like that in
virtconv/ (or most of virtinst/) should raise exceptions to allow the
caller to decide the correct behaviour (if I'm a daemon, I'd better keep
running; a GUI, I'd better bring up a dialog box, etc.).
Cole updated it only a few days ago, here's what I'm seeing at least:

grep -r "fail(" virt-convert

       fail("Couldn't clean up output directory \"%s\": %s" %
       fail("Couldn't import file \"%s\": %s" %
       fail("Couldn't import file \"%s\": %s" % (options.input_file, e))
           fail("Could not create directory %s: %s" %

diff -r 58a909b4f71c virtconv/parsers/vmx.py
--- a/virtconv/parsers/vmx.py	Mon Sep 22 11:32:11 2008 -0400
+++ b/virtconv/parsers/vmx.py	Mon Sep 29 07:17:09 2008 -0400
+# IDE disk
+ide%(dev)s.present = "TRUE"
+ide%(dev)s.fileName = "%(disk_filename)s"
+ide%(dev)s.mode = "persistent"
+ide%(dev)s.startConnected = "TRUE"
+ide%(dev)s.writeThrough = "TRUE"

Hmm, above we're importing virt-image as SCSI disks, but exporting as
IDE - can you clarify this?
We can't export as scsi without qemu-img vmdk scsi support. It's in the

What does this do? I had no idea that vmdk format was specific to either
SCSI or IDE - how does that work?

It's specific within the disk image file itself, not just the configuration. I have no specifics other than that, but I believe it is just a block tag on the device, from looking at the qemu-img vmdk scsi support patch

It's a fine restriction, but it seems inconsistent: why are we assuming
that virt-image import is using SCSI? Wouldn't a better default be IDE?

Never caught that, I always assumed the disks were scsi, are they not? virt image isn't specific so I'm guessing we will need someone else to chime in and clarify this.

et-mgmt-tools mailing list
et-mgmt-tools redhat com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]