virt-clone/Fedora 8/Xen3.1 ... ERROR: Disk size must be an int or a float.

[Petrus B. van Bork]

Dear Fellow-List Members:

                                           I am running the latest, 
fully updated, F8 Xen kernel with F8, updated DomU on top.  I need to 
clone that DomU - indeed, a need to do rather a lot of cloning to 
fulfill our project's mission.  I tried to run virt-clone but it will 
not perform as per the man's examples and despite hours of searching on 
the 'net I cannot find any reason why not.

Here is the example from the man:

-EXAMPLES
-    Clone the guest called "demo" which has a single disk to copy
-
-      # virt-clone \
-           --original demo \
-           --name newdemo \
-           --file /var/lib/xen/images/newdemo.img

What I have tried:

Where:

HanoverGuest = name of functioning DomU (shut off for cloning...)
KohaHanoverConf_Gold = name of new DomU
New File Image: KohaHanoverConf_Gold.dsk

Here is the command sequence I issue:

#virt-clone --original HanoverGuest --name KohaHanoverConf_Gold --file
/var/lib/xen/images/KohaHanoverConf_Gold.dsk -d

I get:

Fri, 08 Feb 2008 14:57:31 DEBUG	start clone with HV Xen
Fri,   ditto		  DEBUG clone device list:
['/var/lib/xen/images/KohaHanoverConf_Gold.dsk']
Fri,   ditto		  DEBUG clone device size: [1048570000L]
Fri,   ditto		  DEBUG clone device type: [True]
ERROR:  Disk size must an int or a float.
What would you like to use as the disk (path)?

...I have tried many, many variants with no more luck and usually with the same error
message.  I have tried to run it 
without creating a disk image myself, with one of 0 bytes size and, as can be seen, one of
10gig size.  No joy!
Furthermore, I cannot find any information on the net on what those debug messages mean so
I have little to judge what is going on.

Apparently the ERROR msg. itself,likely, is generated by:

@@ -83,9 +77,13 @@ class VirtualDisk:
             if size is None and not os.path.exists(self.path):
                 raise ValueError, \
                     _("A size must be provided for non-existent disks")
-            if size is not None and size <= 0:
+            if size is not None and \
+               (__builtin__.type(size) is not __builtin__.type(1) and \
+			    __builtin__.type(size) is not __builtin__.type(1.0)):
+               raise ValueError, _("Disk size must be an int or a float.")

...which comes from a September 28, 2007 patch authored by Cole Robinson for virtinst
validation fixes, found here:
http://www.spinics.net/linux/fedora/et-mgmt-tools/msg01760.html ...alas, without knowing
all the code I am not sure what is going on.
It seems to suggest that somehow the diskimage file is not recognized as a built in data
type or something similar - but there seem to
be no commands available in virt-clone to set the datatype, adapt for the date type or
even tell a user what datatype they need.  Since I am a relative
Linux newbie I may very well be making a classic 'flat-forehead' error - but
what?

I tried to run virt-clone as a basic interactive tool - the man states that it can run
interactively with no command line switches.  Here is what happens:

#virt-clone

..and I get...

ERROR: A new disk image file for the clone guest is required and then it goes back to the
prompt.  Not helpful!

I very badly need to clone DomU's effectively during our development process - and
afterwards and I would be excruciatingly grateful for any help anyone can provide!

Regards,

Petrus

[Cole Robinson]

Petrus B. van Bork wrote:
>  Dear Fellow-List Members:
>  
>                                             I am running the latest, 
>  fully updated, F8 Xen kernel with F8, updated DomU on top.  I need to 
>  clone that DomU - indeed, a need to do rather a lot of cloning to 
>  fulfill our project's mission.  I tried to run virt-clone but it will 
>  not perform as per the man's examples and despite hours of searching on 
>  the 'net I cannot find any reason why not.
>  
>  Here is the example from the man:
>  
>  -EXAMPLES
>  -    Clone the guest called "demo" which has a single disk to copy
>  -
>  -      # virt-clone \
>  -           --original demo \
>  -           --name newdemo \
>  -           --file /var/lib/xen/images/newdemo.img
>  
>  What I have tried:
>  
>  Where:
>  
>  HanoverGuest = name of functioning DomU (shut off for cloning...)
>  KohaHanoverConf_Gold = name of new DomU
>  New File Image: KohaHanoverConf_Gold.dsk
>  
>  Here is the command sequence I issue:
>  
>  #virt-clone --original HanoverGuest --name KohaHanoverConf_Gold --file
> /var/lib/xen/images/KohaHanoverConf_Gold.dsk -d
>  
>  I get:
>  
>  Fri, 08 Feb 2008 14:57:31 DEBUG	start clone with HV Xen
>  Fri,   ditto		  DEBUG clone device list:
> ['/var/lib/xen/images/KohaHanoverConf_Gold.dsk']
>  Fri,   ditto		  DEBUG clone device size: [1048570000L]
>  Fri,   ditto		  DEBUG clone device type: [True]
>  ERROR:  Disk size must an int or a float.
>  What would you like to use as the disk (path)?
>  
>  ...I have tried many, many variants with no more luck and usually with the same error
> message.  I have tried to run it 
>  without creating a disk image myself, with one of 0 bytes size and, as can be seen, one
> of 10gig size.  No joy!
>  Furthermore, I cannot find any information on the net on what those debug messages mean
> so I have little to judge what is going on.
>  
>  Apparently the ERROR msg. itself,likely, is generated by:
>  
>  @@ -83,9 +77,13 @@ class VirtualDisk:
>               if size is None and not os.path.exists(self.path):
>                   raise ValueError, \
>                       _("A size must be provided for non-existent disks")
>  -            if size is not None and size <= 0:
>  +            if size is not None and \
>  +               (__builtin__.type(size) is not __builtin__.type(1) and \
>  +			    __builtin__.type(size) is not __builtin__.type(1.0)):
>  +               raise ValueError, _("Disk size must be an int or a float.")
>  
>  ...which comes from a September 28, 2007 patch authored by Cole Robinson for virtinst
> validation fixes, found here:
>  http://www.spinics.net/linux/fedora/et-mgmt-tools/msg01760.html ...alas, without knowing
> all the code I am not sure what is going on.
>  It seems to suggest that somehow the diskimage file is not recognized as a built in data
> type or something similar - but there seem to
>  be no commands available in virt-clone to set the datatype, adapt for the date type or
> even tell a user what datatype they need.  Since I am a relative
>  Linux newbie I may very well be making a classic 'flat-forehead' error - but
> what?
>  
>  I tried to run virt-clone as a basic interactive tool - the man states that it can run
> interactively with no command line switches.  Here is what happens:
>  
>  #virt-clone
>  
>  ..and I get...
>  
>  ERROR: A new disk image file for the clone guest is required and then it goes back to the
> prompt.  Not helpful!
>  
>  I very badly need to clone DomU's effectively during our development process - and
> afterwards and I would be excruciatingly grateful for any help anyone can provide!
>  
>  Regards,
>  
>  Petrus
>   
Hi Petrus,

This is fixed upstream:

http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=611782118e76

But this isn't in fedora yet. Follow the instructions at
http://virt-manager.org/scmrepo.html to check out the latest virtinst--devel
and you should be able to run virt-clone directly from the checkout.

- Cole

[Christopher Fournier]

I tried the latest dev stream, and continued to have the problem. The quick
fix is to simply touch the target file before launching 'virt-clone'

touch <dir_to_VMs>/newvm.img
virt-clone -o existing_vm -n new_vm -o <dir_to_VMs>/newvm.img

Cheers!
-- 
View this message in context:
http://www.nabble.com/virt-clone-Fedora-8-Xen3.1-...-ERROR%3A-Disk-size-m...
Sent from the Fedora Xen mailing list archive at Nabble.com.

[Asrai khn]

On Feb 12, 2008 8:24 PM, christf1 <christf1(a)nortel.com&gt; wrote:

>  I tried the latest dev stream, and continued to have the problem. The
>  quick
>  fix is to simply touch the target file before launching 'virt-clone'
>
>  touch <dir_to_VMs>/newvm.img
>  virt-clone -o existing_vm -n new_vm -o <dir_to_VMs>/newvm.img
>  
hi,

i wonders virt-clone will work when one is doing LVM for domUs fro example
here is mine virutal config file

kernel = "/boot/vmlinuz-2.6.21-2952.fc8xen"
ramdisk = "/boot/initrd-2.6.21-2952.fc8xen-domU.img"

memory = 200
name = "myvm3"
vif = [ 'ip=xxx.xxx.xx.xx' ]
disk = [ 'phy:vg/vm2.root,sda1,w', 'phy:vg/vm2.swap,sda2,w',
'phy:vg/vm2.var,sda3,w' ]
root = "/dev/sda1 ro"
on_reboot   = 'restart'
on_crash    = 'restart'

On other hosts we are using loop back files for domU FS.

thanks.

[Daniel P. Berrange]

On Tue, Feb 12, 2008 at 09:49:55PM +0500, Asrai khn wrote:
>  On Feb 12, 2008 8:24 PM, christf1 <christf1(a)nortel.com&gt; wrote:
>  
>  >
>  > I tried the latest dev stream, and continued to have the problem. The
>  > quick
>  > fix is to simply touch the target file before launching 'virt-clone'
>  >
>  > touch <dir_to_VMs>/newvm.img
>  > virt-clone -o existing_vm -n new_vm -o <dir_to_VMs>/newvm.img
>  >
>  
>  hi,
>  
>  i wonders virt-clone will work when one is doing LVM for domUs fro example
>  here is mine virutal config file 
It won't care what type of storage the original VM is using - it'll
simply read the data off the original disk whether its a file or
block device or LVM vol.

If you want to use LVM volumes in the destination VM, then you currently
need to manually create the LVM volume ahead of time - virt-clone itself
will not create new LVM volumes for you. This is in the future feature
list though, once libvirt storage management APIs are merged.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  [phone] -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|

[Asrai khn]

On Feb 12, 2008 10:35 PM, Daniel P. Berrange <berrange(a)redhat.com&gt; wrote:

>  It won't care what type of storage the original VM is using - it'll
>  simply read the data off the original disk whether its a file or
>  block device or LVM vol.
>
>  If you want to use LVM volumes in the destination VM, then you currently
>  need to manually create the LVM volume ahead of time - virt-clone itself
>  will not create new LVM volumes for you. This is in the future feature
>  list though, once libvirt storage management APIs are merged.
>
>  
thanks, one more question what will be the virt-clone command to clone
existing vm which FS is based on loop back files and using more then one
file for root. var, and swap eg here is the entry from /etc/xen/vm.cfg which
we are using

kernel = "/boot/vmlinuz-2.6.21-2952.fc8xen"
ramdisk = "/boot/initrd-2.6.21-2952.fc8xen-domU.img"

memory = 256
name = "vm1"
vif = [ 'ip=xx.xx.xxx.xxx' ]
disk = ['tap:aio:/var/uml/vm1/root,sda1,w',
'tap:aio:/var/uml/vm1/var,sda2,w', 'tap:aio:/var/uml/vm1/swap,sda3,w']
root = "/dev/sda1 ro"
on_reboot   = 'restart'
on_crash    = 'restart'


all our our virtual hosts we are using separate loop back files for root,
var and swap.

thanks.

[Daniel P. Berrange]

On Tue, Feb 12, 2008 at 10:47:40PM +0500, Asrai khn wrote:
>  On Feb 12, 2008 10:35 PM, Daniel P. Berrange
> <berrange(a)redhat.com&gt; wrote:
>  
>  >
>  > It won't care what type of storage the original VM is using - it'll
>  > simply read the data off the original disk whether its a file or
>  > block device or LVM vol.
>  >
>  > If you want to use LVM volumes in the destination VM, then you currently
>  > need to manually create the LVM volume ahead of time - virt-clone itself
>  > will not create new LVM volumes for you. This is in the future feature
>  > list though, once libvirt storage management APIs are merged.
>  >
>  >
>  thanks, one more question what will be the virt-clone command to clone
>  existing vm which FS is based on loop back files and using more then one
>  file for root. var, and swap eg here is the entry from /etc/xen/vm.cfg which
>  we are using 
Yes it is quite happy dealing with multiple disks, and doesn't care what
driver is being used (phy:, file:, tap:aio: - this only affects guest,
not the way you access files).  Just use the '-f' flag multiple times
if you have many disks.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  [phone] -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|

[Cole Robinson]

christf1 wrote:
>  I tried the latest dev stream, and continued to have the problem. The
> quick
>  fix is to simply touch the target file before launching 'virt-clone'
>  
>  touch <dir_to_VMs>/newvm.img
>  virt-clone -o existing_vm -n new_vm -o <dir_to_VMs>/newvm.img
>  
>  Cheers! 
I'm not seeing this:

hg clone http://hg.et.redhat.com/virt/applications/virtinst--devel
cd virtinst--devel
./virt-clone -o xen-pv -n clone-pv -f /idontexist.img

starts working, for an existing turned off guest named xen-pv on f8.
Is there anything you are doing differently? If so, can you detail it
and post the complete error message? 

Thanks,
Cole

[Christopher Fournier]

Interesting. I'm using a base installation of Fedora 8, 64 bit version,
and all packages are directly out of the distro. The error crops up as
soon as I launch the tool:

[root@localhost ~]# virt-clone -d -o vm1 -n vm2 -f /opt/VMs/vm2.img
Tue, 12 Feb 2008 12:25:30 DEBUG    start clone with HV qemu:///system
Tue, 12 Feb 2008 12:25:30 DEBUG    clone device list:
['/opt/VMs/rhel4u6-3.img']
Tue, 12 Feb 2008 12:25:30 DEBUG    clone device size: [0]
Tue, 12 Feb 2008 12:25:30 DEBUG    clone device type: [True]
Tue, 12 Feb 2008 12:25:30 DEBUG    Disk path not found: Assuming file
disk type.
ERROR:  Disk size must be an int or a float.
What would you like to use as the disk (path)?

As mentioned, the error also crops up using the latest dev snapshot.


On Tue, 2008-02-12 at 12:30 -0500, Cole Robinson wrote:
>  christf1 wrote:
>  > I tried the latest dev stream, and continued to have the problem. The quick
>  > fix is to simply touch the target file before launching 'virt-clone'
>  > 
>  > touch <dir_to_VMs>/newvm.img
>  > virt-clone -o existing_vm -n new_vm -o <dir_to_VMs>/newvm.img
>  > 
>  > Cheers!
>  
>  I'm not seeing this:
>  
>  hg clone http://hg.et.redhat.com/virt/applications/virtinst--devel
>  cd virtinst--devel
>  ./virt-clone -o xen-pv -n clone-pv -f /idontexist.img
>  
>  starts working, for an existing turned off guest named xen-pv on f8.
>  Is there anything you are doing differently? If so, can you detail it
>  and post the complete error message? 
>  
>  Thanks,
>  Cole 
-- 
Chris Fournier

Nortel
3500 Carling Avenue
Ottawa, Ontario, Canada
K2H 8E9
Phone: [phone]

[Daniel P. Berrange]

On Tue, Feb 12, 2008 at 07:24:34AM -0800, christf1 wrote:
>  
>  I tried the latest dev stream, and continued to have the problem. The quick
>  fix is to simply touch the target file before launching 'virt-clone'
>  
>  touch <dir_to_VMs>/newvm.img
>  virt-clone -o existing_vm -n new_vm -o <dir_to_VMs>/newvm.img 
Your command line is wrong - the last flag should be '-f'  not '-o' to
supply the filename

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  [phone] -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|

[Christopher Fournier]

Correct; I should've just cut and pasted, but apparently I looked the
other way when I typed that last option. 

Thanks for pointing that out. :)

On Tue, 2008-02-12 at 17:36 +0000, Daniel P. Berrange wrote:
>  On Tue, Feb 12, 2008 at 07:24:34AM -0800, christf1 wrote:
>  > 
>  > I tried the latest dev stream, and continued to have the problem. The quick
>  > fix is to simply touch the target file before launching 'virt-clone'
>  > 
>  > touch <dir_to_VMs>/newvm.img
>  > virt-clone -o existing_vm -n new_vm -o <dir_to_VMs>/newvm.img
>  
>  Your command line is wrong - the last flag should be '-f'  not '-o' to
>  supply the filename
>  
>  Dan. 
-- 
Chris Fournier